Category Archives: tools

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

Dumping gear: TL866CS

MiniPro TL866CS Universal IC Programmer
MiniPro TL866CS Universal IC Programmer

One key element in emulation is ROM dumping. This is the process by which we are able to extract the contents of a memory chip such as an EPROM or the internal memory of a microcontroller.

When I started to learn emulation, I did not have access to proper ROM dumping equipment, so I resorted to building my own ROM dump circuitry around the Arduino. The result was a tangle of wires in a breadboard. It worked OK yielding valid results, but it was a slow procedure requiring manual post-processing of the data and it had to be reassembled from scratch everytime I needed to dump something. I would not trust a bunch of messy wires left aside for a week in a breadboard. I would prefer to spend something around 15 minutes to half an hour reassembling the circuit to be sure it was  in good condition to be used.

The process of designing my own ROM dumper and building it from scratch (several times) was, for sure, aligned with the DIY mindset and helped me grasp the technology. But I needed something more reliable so that I could move on to other larger emulation challenges. So I went after a pre-assembled, commercial unit and I found a nice review of the Minipro TL866CS at the EEVBlog.

I was aware that it would only work with the crappy proprietary host application provided by the chinese manufacturer, but I was willing to delve into USB sniffer-based reverse engineering in order to write my own tools to use it, so I ordered one of these, anyway.

While I was waiting for the package to arrive from China, though, I discovered that the Ukrainians were faster and a hacker had already reverse engineered the protocol and released a free software program to operate the TL866CS. Yay!!! 🙂

So, this has been a very handy tool to me, since then. It is able to both dump and also write to an enourmous variety of memory chips (including the internal memory of several models of microcontroller chips). The fact that it operates over USB is very handy for modern computers. The older dumping/programming devices used to rely on interfaces such as serial and/or parallel ports, or other proprietary interfaces which are not easily accessible anymore nowadays.

Minipro's handy USB interface.
Minipro’s handy USB interface.

And as the TL866CS is small and lightweigh, I always carry it (and a USB cable) on my backpack, so I’m ready to dump whatever cool device I may stumble upon in a casual day 🙂

The ZIF (Zero Insertion Force) socket on top of the TL866CS allows me to work with chips in DIP packaging. There were some situations in which I had to dump chips with other packaging types, such as the 8051 microcontroller used in the Ultratec Minicom IV, which is a PLCC44 chip. For that, I have bought the PLCC44 to DIP40 adapter shown below:

PLCC44 to DIP40 adapter.
PLCC44 to DIP40 adapter.

There are other adapters available for other packages such as PLCC32, TSOP, etc. But some of these are pretty much expensive, so I only plan to buy them whenever I really need them.

I am extremely happy with this programmer/dumper. There is only one pending issue with it, in my opinion. It is great that it operates with free software (“free as in freedom”) under GNU/Linux, on the command line. It would be nice to have a graphical user interface, but not really essential. The tricky problem that really still remains to be solved is the fact that all of the “intelligence” of the device is actually inside its firmware and not in the host application.

The algorithms for supporting the dumping and programming of the several thousands of chips supported are implemented in the internal firmware, running on a PIC microcontroller. And in some cases we may need to deal with chips that are not yet officially supported by the TL866CS proprietary firmware. I think it would be great to have a free software implementation of firmware for the TL866CS, so that we could add support for other chips. Also, by having free firmware, the TL866CS could potentially be used for other purposes as well. One idea would be to use it as a testing bench for verifying if a chip is properly working.