Arcade Machine Conversion to the CoCo Overview

Hello, in a recent post I got a comment from username Perezernestoj who asked if I could convert Super Pac Man as my next game for the CoCo after I complete Defender.  I explained how much work this is and that you would only do it if that particular game meant enough to you to go through all the effort.  Well Perezernestoj said he might give doing the conversion himself a try.  It just occurred to me that I should put together some notes to aid not only myself but others that are thinking or might want to convert an old favourite Arcade game to the CoCo themselves.

In this short post I’m going over at a very high level what is involved in converting an old classic Arcade game to the CoCo and my approach to it.  These are some things I’ve learned so far…

• Gather all info you can about the game from the internet, including technical/repair/owner manuals and read/watch interviews with the original game authors and make notes if they talk about your hardware.
• If you are super lucky you can find a commented disassembly of the game online.  Some games use the same hardware as other games.  If you can find a commented disassembly of a game that uses the same hardware keep that info close it will help decoding a lot of your game, especially the sound and controller routines.  If you aren’t lucky enough to find a disassembly you will need to create your own disassembly of the game.  Maybe the hardware info you found will help you to figure out what ROMS hold data such as text messages and sprite info.  The more info you have about the layout of code and data sections the better your disassembly will be.  Looking through manuals and MAME source code for your game may help figure out what is machine code and what is other data.
• It is also useful to break up your big disassembly into small parts to refer to.  For example if you find the data sections have a bunch of text messages you might want them in their own .asm file so you can refer to it quickly as you go through the code.  If you only have one big disassembly file to scan through it will mean a lot of jumping around from one section to the other and it can really slow you down.

My method of decoding a game:

• As you decode and convert routines from the disassembled source code, from the original to CoCo format always keep the original code with the address in RAM info to the right so you can refer to it later (this comes in handy so much!)

Here is an example of what I mean from my Pac Man transcode.  The left is the 6809 (CoCo) assembly version and on the right is the Z80 (Pac Man)  disassmelby with the original address of the code and to the right of that I put in my own comments as  I go:

; Routine to determine number of pellets to eat
PelletCount:
        LDA     PelletsEaten                        ;08DE 3A0E4E      LD      A,(PelletsEaten)  ; number eaten
        CMPA    #$F4                                ;08E1 FEF4        CP      0F4h ; '('        ; compare to 244
        BNE     loc_8EB                             ;08E3 2006        JR      NZ,loc_8EB        ; jump if not done
        LDX     #CurrentTaskNumber                  ;08E5 21044E      LD      HL,4E04h          ; set level complete
        LDA     #$0C
        STA     ,X                                  ;08E8 360C        LD      (HL),0Ch

•  From the hardware info you should be able to find out the address that the game starts at.  Sometimes called the RESET vector.  Start decoding where the game normally enters it’s startup routine.  Not at the first line of code (unless it is the startup routine) the startup routine is most likely going to be code that tests the ROM/RAM and other hardware.  This will usually show some messages on the screen this will force you to figure out how the game writes text to the screen.
• Once you know how text on the screen is written you can go through the entire code and find where it jumps to the “SHOW TEXT” routine and markdown what text is shown on screen at that point in the code.  This gives you a good idea what the code in that section is actually doing before you even decode it.
• If you can figure out how sounds are created in the game then you can do similar things to the above.  Find the routines that jump to “Play Sound” and mark that section as playing a specific sound like firing or starting a level.
• Buttons are good info too, if you can find the code where the buttons are read then you can figure out what sections of code are used for firing and moving the player and handle coin insert and player start.  When you find where the player controls are you can figure out how it draws sprites on the screen and also where in the code it draws the enemy ships.
• The ROM/RAM tests will fail, because our bytes won’t match the original processors code, so I just fake that the tests passed in the code and move along.  Once you have the main initializing code converted to a CoCo version where it shows something on the screen you should test your version on a CoCo or MAME this will make sure you understand how the graphics hardware works for the original game and it is very motivating to see your conversion is actually looking like the original game.  If you can get any initializing sounds working that the original game makes when starting up then that will also help to keep you motivated…  You can also work out audio later once the game is converted to a CoCo version.
• Games will initialize themselves to a specific way from SRAM settings or hardware DIP switches before the game starts and the IRQ is turned on.  These are things like what score does the player get a free man and how many men does the player get per coin, how difficult the game mode will be, etc.  Then it will start up the IRQ.
• Figure out how the IRQ works for the game, once this is figured out you have the heart of the game.  Everything is usually triggered based on the IRQ so you can decode different sections of code in the IRQ.  At the IRQ starting point, your game is about to start, probably in the attract mode until it detects a coin insert or player start button being pressed.
• If you have converted the code to the CoCo version upto the IRQ then you will need to setup an IRQ on the CoCo to be triggered the same way the arcade machine does.  So far I’ve found most are triggered by the VSYNC IRQ.  So setup a Vsync IRQ on the CoCo and in your conversion emulate the routines in the IRQ one at a time.  Start by removing the jumps to routines you haven’t decoded and get a version of your code that can be assembled so you can test your progress on a CoCo or MAME as you progress through the different routines in the IRQ.

To help decoding have the original arcade game running in MAME in debug mode where you can setup breakpoints and watchpoints and step through the original game code and see exactly what it is doing at any point in the program.  It also shows the memory and registers…  I have a previous blog that explains how to program for the CoCo and use MAME in debug mode that will probably be helpful at this point.  That blog post is here.

One other thing I should mention is that a lot of old games use other processors then the 6809.  Many use the Zilog Z80 CPU and I have written a converter when I worked on Space Invaders and Pac Man to help get started that converts Z80/8080 assembly code to 6809 assembly code.  I talk about this in my older blog posts here and here.

Good luck with your own Arcade conversions…

Glen