Category Archives: arcade

Pixotosco: homebrew on Gunsmoke PCB

Back in 2013, for approximately 6 months I organized weekly meetings at the local hackerspace (Garoa Hacker Clube) called Retro-coding Workshops – in Brazilian Portuguese, “Oficinas de Retroprogramação”. It all started when I decided to dedicate some ammount of time each week to study reverse engineering of digital electronics devices. And I decided to do it at the hackerspace instead of at my home, because if anyone got interested in learning this kind of stuff, it would be a good opportunity of sharing the knowledge. And if no-one showed up, I would be dealing with the subject anyway. One or two people actually got interested and started to show up weekly for the workshop and we got a good vibe and the workshops lasted several months!

RetroCoding Workshops - Oficinas de Retroprogramação

Naturally, MAME (and back then MESS) was a recurring topic on those workshops, both as a tool and also as an educational asset. The source code of these emulators are effectively unofficial documentation of the inner workings of the emulated devices (both arcade games and also all sorts of other electronic equipment) and this enables a programmer to learn how to develop software targeting those specific boards.

As I wanted to learn more about digital electronics design and emulation techniques, I decided to buy an arcade board which already had good emulation in MAME. So I ordered on MercadoLivre (a website that’s similar to eBay) a 1985 CAPCOM GunSmoke arcade board.

By reading the GunSmoke driver source code while simultaneously inspecting the PCB circuits with a multimeter’s continuity test mode I was able to understand both the TTL logic circuitry as well as the emulation framework employed by MAME. And with that I also grasped how one was supposed to code a game targeting that specific board.

In order to demonstrate that I had understood at least the basics of how it worked I decided to implement a proof-of-concept. I wrote a tiny (and incomplete) “snake” clone but using a pixelated alligator as the game character.

Drawing char-tiles on GIMP

Pixotosco is a character created by the Brazilian grafitti artist Tony de Marco, who’s also a close friend and a mamber of the hackerspace. One can find Pixotosco in many walls of São Paulo, Brazil. It’s sort of an alligator with a very long and pixelated body. It’s made of rectangular shapes that reminds us of pixels, but it’s actually curvy with its body swinging along the walls.

I recorded a video of the proof of concept and published it on YouTube. Bear in mind that this is really just a proof-of-concept and probably will never really become a full game.

There’s no collision detection, so the alligator can safely cross its own tail. It can even walk past screen borders! When moving to the top, it shows up in the bottom, which reflects the video memory layout and reminds of the fact that the monitor is in a 90 degrees orientation with the scanlines (and video memory addressing) along vertical lines.

Another glitch can be seen when the alligator moves to the right, effectively trying to draw chars outside of the char-tile RAM region. The next region of video RAM is dedicated to per-char palette selection. The side effect is that we see the alligator tail changing color, but also some garbage showing up in some places. The reason for that is because the clean screen routine does not really clean the garbage, but only selects a fully transparent palette for all chars on the screen. Perhaps I should have implemented it differently. But then I would not have had the opportunity of explain this here… 😉

GunSmoke boards

Main source code is written in C and cross-compiled targeting the Zilog Z80 CPU (a classic from the 80s). The bootloader had to be entirely written in Z80 assembly language, but it is a rather short and simple piece of code that only serves the purpose of setting up a minimal C runtime for the rest of the code. All graphics assets were drawn on GIMP and automatically converted to the specific char-tile data format used by the video circuitry of this PCB. The image data conversion is actually performed by a helper tool that I implemented in C. There’s also the need to generate palette-ROM binaries with the colors we want the images to be displayed with. The several binary files that are output by the build system (with a nice Makefile) are loaded into MAME where I can test it and validate if it’s looking and playing good.

Once I got it working on the emulator, I used my universal programmer and burned the data into actual EPROM chips and placed them in the original arcade board. In the mean time I bought myself an arcade cabinet and was able to play my proof-of-concept in the original GunSmoke board. It was a pretty exciting moment!

garoa arcade room

All of the source code is published on this github repo.

Happy Hacking,

Felipe “Juca” Sanches

Recovering a dead CPS2 board – Street Fighter Zero 2 (Brazil)

My weekend at the hackerspace was fun indeed. I spent the whole Saturday (March 5th, 2016) afternoon and night (up to Sunday 4am) trying to resuscitate a dead CAPCOM CPS2 arcade board. The game used to be Street Fighter Zero 2 (Brazil). But as the suicide battery was dead, it means the board lost the crypto key that it typically stores in an internal static RAM backed by the battery. So, without the correct key, the CPU can’t run the encrypted ROM code any more.

Luckily, years ago people figured out that the crypto-CPUs from CPS2 boards behave as a normal CPU capable of running unencrypted code when the battery is dead. So all we need to do to restore this arcade board is to replace the ROMs in it with a set of decrypted ones. Some people such as the CPS2 ROM Decryption Effort have put the effort to manually decrypt the ROMs of several CPS2 games. It is a time consuming task, so not all games are already decrypted. That’s the case for the game I had in my CPS2 board.

But there’s a similar game, a variant of it called Street Fighter Zero 2 Alpha (Brazil), which is already decrypted. And it uses the same graphics and sound assets (which were already originally unencrypted memory chips), so there’s no need for me to change all those chips, but only a few code EPROMs (6 in total). So I did it and after some struggling, which included instaling a “CPS2 suicide test” ROM developed by Razoola, I finally got the board to boot. Everything works nicely except the video. I can see the intro of the game, the music and sound effects are perfect, but the graphics are partially corrupted.

The current state is that 50% of the screen (every odd vertical strip of tiles) displays good graphics while the other 50% is corrupted. I could not yet figure out what’s wrong, but I could verify that the graphics assets ROM contents are perfect, so it must be some issue with the addressing circuitry to select those ROM chips. I think the culprit may be the BGS-B3D PAL16L8 chip in the B-Board.

I was too tired to continue, so I packed things and went home. I’ll have to resume the investigation another day. But it sure was fun and I almost got it working perfectly.

[[ This is a quick posting. I may tweak it in the future and add photos or other aspects of the ongoing effort. So be sure to revisit it from time to time 😀 ]]

A pleasant visit to the University

Today I visited the engineering school of the University of São Paulo, where I studied 10 years ago. The reason for my visit was to get in contact with professors and laboratory technicians who may have access to 3D scanning equipment.

Recently I have been experimenting with 3D modeling of arcade cabinets while building a prototype for a 3D artwork system for MAME. There’s some technical discussion and brainstorming about that in this issue on GitHub, as well as python source code and OpenSCAD 3D modeling scripts in this other git repository.

gforce2sd_observer

Even though Galaxy force 2 Super Deluxe still does not provide motor control signals (because the motor-cpu firmware still needs to be reverse engineered and emulated), one can try the 3D artwork system by running the Power Drift driver together with the gforce2 3D model. It is a hack, indeed, but it is just meant to serve as a proof of concept of the system and its proposed XML schema for describing scenes.

This is also related to the Wacky Gator driver that I bootstrapped and that Sandro Ronco made work perfectly, as described here by David Haywood’s recent blogpost. And Wacky Gator can already be played with the 3D artwork system prototype 😀

wackygtr_alligators_cam

But the alligators in the game are represented as simple blocky green shapes. So, the natural extension of this idea would be to add 3D scanned objects to the scene. And that’s why I was at University of São Paulo today.

But while there, I ended up talking to the technicians of the digital electronics laboratory. And then it reminded me of the prototyping panel that we used to deal with in some of our lab classes. I asked about it and they brought one of those boards for me to take a look.

These educational boards contained lots of interesting things built around an 8051 CPU. They even had a tiny LCD panel (which surely must be the famous Hitachi HD44780, right? :-D). So I dumped the firmware of the board and snapped a picture of it. I may soon write a skeleton driver for it in MAME.

Jpeg
Educational board: PCS2497 Escola Politécnica USP — These 8051-based boards are used in digital electronics classes at the university laboratory.

After our conversation, Daniel, the technician, tried to introduce me to a few of the computer engineering professors because he was getting a lot of interest in doing something with emulators in the laboratory classes. And I am also interested in giving a talk there soon about MAME, reverse engineering, technical education and emulation, of course. But the professors were not at their offices, so we agreed to meet again in the near future to talk more about this stuff.

joao-jose-neto
Professor João José Neto, one of the designers of Patinho Feio, the first Brazilian computer.

So, I though I had already collected Jackpot for the day and I was considering to go back home. But I remembered professor João José Neto (one of the minds behind the “Patinho Feio”, the first computer designed and manufactured in Brazil, in the early 70s) might be at his office, so I though it could be worth to get there and say hello.

And indeed he was there and received me with a big welcoming smile. We spent half an hour talking about old computers, and how things gradually get lost because most people don’t care. So I tried to convince him to help me figure out where the remaining old-machines designed by him and his colleagues decades ago might be nowadays, so that we could try to restore them and also to emulate them, for the sake of historical preservation.

When I was leaving the room, after a warm conversation, I mentioned we would gladly digitize old technical materials as well. So, he went back into his office and then back to the front door and deposited in my hands a copy of a technical documentation of the Patinho Feio Assembler. I was shocked. I asked it and he confirmed: it was the single copy of the document he was aware of and it was dated July 1977. And he wanted me to take it away with me for proper digitizing.

pagina_0_capa

I got really happy and honoured with the gesture. But at the same time, I felt fearful of making some silly mistake. So I came back directly to my home planning to digitize it as quickly as possible so that we have a digital backup of this material. My plan is to publish it on the Internet Archive as soon as I get it all scanned. It’s a 1cm thick block of pages, all in classic type-writer style. (it does not seem to be the original, but just a copy of it) It will take some time until I get this all done, but I feel that I have the duty to do it correctly. And I am proud of having this opportunity.

Next obvious step would be to implement the CPU emulation module for the Patinho Feio in MAME, but I won’t even try that before getting the whole thing scanned and published.

 

Happy Hacking!

Felipe “Juca” Sanches