Tapper arcade game

@mrcity Just as I thought, Tapper, being from Bally Midway, is based on the 6809 processor.

http://seanriddle.com/faq.html

3 Likes

I think I saw a copy of that for the TI-99/4 on the donation shelves last night.

Cool. I was already able to use the Mame tile viewer and a hex editor to edit some of the tiles in the game, particularly the ones that say Budweiser in levels 1 & 2. I have modified them to show a number from 1 to 47 just so I can get a feel for how the color palette works there. All I have to say is: Thank goodness for the Mame tile viewer and for ROM file naming schemes that make sense.

Apparently Tapper uses a revision of the Midway “MCR” system architecture, probably the MCR II or MCR III. The background ROMs are divided into two files: one that defines a 2-bit color per pixel (tapbg1.bin) and another that defines a 2-bit color palette per pixel (tapbg0.bin). Thus, there are four palettes, and four colors to choose from per palette. YY-CHR is a program that gets close to being able to view and modify the files, but unfortunately it seems to add an offset to each tile so they’re split in half along the vertical.

There are a couple things that would be cool:

  1. Find out how to address more tiles. As you can imagine, only tiles with distinct data are actually differentiated from each other where the Budweiser logo goes in the game. Thus, I can’t just draw over the whole bounding rectangle around that logo because some of the tiles would repeat themselves and cause a weird-looking image. It’d be nice to find out where it specifies the tile addresses and add in some new ones so I don’t have to squish up the new logo super-tiny or have weird “holes” in it.

  2. Play custom music. No sweat if this doesn’t get done, but it’d certainly be cool nonetheless. This page has more info on how sound gets generated by Midway MCR systems.

Ok, so addressing more tiles was easier than I thought. :slight_smile: I was poking around the ROM files in a hex editor and happened to see the string “GET READY TO SERVE” in ASCII plain text. Then about 1K later, I saw a whole bunch of really repetitive-looking numbers. I wrote down on scrap paper which tile addresses appeared where on-screen for Level 1, and sure enough, the same pattern existed in the first 1.5K (first screen’s worth) of these numbers. Now it’s worth noting that the top tile of the Budweiser logo is tile 0x86, and of course it doesn’t exist in the bottom of the memory map; in fact, the tile addresses are offset by 0x5000. (One thing I haven’t checked yet is if this refers to the whole tile in the background ROMs, or just the color or the color palette).

If you’re following along with me in MAME, all the screens should be found in tappg1.bin and tappgg2.bin starting at address 0x2210 in tappg1.bin. However, the 16 bytes at 0x2210 isn’t 0x5007 like I’d expect for tile #7, but in fact 0x9607. I’m not sure where that 96 comes from or how it gets resolved.

Fortunately, they don’t seem to be doing any crazy kind of run-length encoding or other compression on any of the screens. Unfortunately though, the Tapper program takes a checksum on those bytes, and so if the area doesn’t add up to what it’s expected to, the program shows “ROM ERROR 2C”. This means whatever offset I add to a byte, I have to subtract from one or more bytes. Hopefully I can use the MAME debugger to find out where the checksum code lives so I can alter its value or edit the ROM so it skips that step altogether.

Most of the ROM checks from that era was simple checksumming instead of a CRC. It will not be difficult to determine what memory range is checked and alter another byte somewhere else in that range to compensate for your changes. If you appreciate irony, use one of the letters in the ROM error message…

Yes, I found that the checksum for the four program ROMs are each 6 bytes apart starting with Program Rom 1 at 0xCDAA in the memory space (i.e. PG2 is at 0xCDB0, etc.) These are in tappg3.bin starting at 0xDAA relative to this ROM only. I successfully used the MAME debugger, saw the value it expected, and put it in the ROM; then I stopped getting ROM ERROR 2C. However, that caused ROM ERROR 4C, which was challenging to get rid of.

The challenge I faced with ROM 4 was when the debugger told me I needed to increase the checksum by 1, I would do that, then it would still tell me I needed to increase the checksum by 1. So I figured the easiest way to get around that was to subtract 1 from somewhere else harmless in the ROM, such as all the 0xFF’s at the end.

Then, to really drive the nail home with a wrecking ball, I simply replaced everything from [0xCD89, 0xCD90) with 0x00 (nop) so it simply wouldn’t branch to show the error message. :stuck_out_tongue: And indeed, now I can continue developing without even worrying about the checksum. Maybe I’ll revert that stuff right before the exhibition or if I ever burn it to real EPROMs.