Atari Food Fight - Improved Free Play

[edwoodjnr]

Although Food Fight has a free play mode that can be set using the dip switch #2, once set you no longer see the fancy attract mode and the high score table is not displayed because setting the dip continually sets the number of coins inserted to 2.

While you can wire P2 start to coin 1 with a small wire soldered to pins 13 and 16 on the pcb connector to coin up when P2 is hit, this isn't an elegant solution.

With no prior assembly knowledge I decided to learn a little 68k assembler and fix this problem by hacking the roms to enable free play and display the fancy attract mode. It was an interesting project that gave me an insight of how the roms are switched, the counters used, the rom checks and recalculating the CRC so the rom check still works.

I have attached 4 zip files, one for each of the Food Fight revisions that you can use to patch your 6 original EPROMs. There are no roms included in these files only the patch files, a java rom patcher, a readme and a png to print out your own labels.

"FREE PLAY" is now displayed on the gameplay section of the attract mode and to start a game just press P1 or P2. The PCB dip switch 2 should be set to free play for this to work.

Cocktail
https://www.dropbox.com/s/e6o767cioag4kml/FF FP Cocktail.zip
https://dl.dropboxusercontent.com/u/17659718/FF FP Cocktail.zip
Rev 1
https://www.dropbox.com/s/qy8y4vrxv3epk4k/FF FP Rev 1.zip

Rev 2
https://www.dropbox.com/s/bo170i1iuorkl59/FF FP Rev 2.zip

Rev 3
https://www.dropbox.com/s/46bh5jopl5r8glr/FF FP Rev 3.zip

edwoodjnr2019-06-13 20:26:27

 

[Hurray Banana]

Nice

 

[Alpha1]

Wow dude!! AWESOME WORK!! cmonkey would be proud!!

 

[iamjimmi]

Very clever...

 

[edwoodjnr]

Thanks guys, it was really enjoyable figuring it all out

 

[backflipper]

Well done!
I was wondering if anyone might have done this.
thanks for sharing.

 

[philmurr]

That is very good, love the fact you've made labels for the replacements too.

Excellent work

 

[smarty]

There a serious amount of awesome work coming from 'Vac members recently. Great work

I'd love to hear a bit more about how you went about this in term of altering the roms if possible.

 

[cmonkey]

Excellent work. Even more so for the fact that you had no previous 68k assembly language knowledge before starting. Just out of interest, how long did it take you to learn enough 68k to be able to patch the roms?

 

[silverfox0786]

AWESWOME

food fight is a great game

wish i owned a cab

 

[LukeWells]

Impressive work for someone with no prior experience sir, how long did it take you?

 

[edwoodjnr]

It took about 3 weeks to figure it all out using the MarkeyJesters 68K online tutorial, the MAME debugger, the MAME Food Fight memory map then used the cheat system to quickly try things out. Once complete I had to wait a couple of weeks for the same original D2764-3 EPROMs to arrive (they didn't work) and then another week to wait for new M2764AF1 ROMs which worked fine. The simplified overview is as follows but there is a lot of work involved in reviewing the asm (using the DASM MAME command) and watching for changes in RAM at specific locations.

You need to preserve the existing code ROM locations and cannot simply add new instructions to make it do what you need. As there was little freespace in the ROMs to jump to another location to run new instructions before jumping back I needed to overlay the exising ROM code with the new word for word code. Also on Food Fight each hex word is split across 2 ROMs that took a while using trial and error to work out the hex for 'FREE PLAY' which is not in clear in the ROM.

I originally removed the CRC check by patching the code to do the opposite of what it did once adding up all the bytes. Later on once I had perfected the hack I put the CRC check back in and adjusted the calculated value by subtracting what it was expecting and storing the difference in 1 word at the beginning of the ROM.

The rest of the hack overlayed instructions where it tests for the P1 and P2 coin input and to zeroise the coin counter if a coin was actually input (to prevent it going to the static screen) and when the game started

 

[cmonkey]

Nice write up.

If I could just give you one word of advice though, especially if you're going to do other 68k code mods. You may or may not be aware that the first 256 long words (1024 bytes) of address space of the 68k CPU is reserved for the processor exception vectors. You've inserted your CRC fix-up bytes into the upper word of the bus error exception vector. In the extremely unlikely event that this game generated a bus error during execution the CPU would retrieve the vector from address $00000008 and jump to that location. Due to you putting the CRC bytes into addresses 8-9 this long word has now become an address of $3c99008c, which is outside the 24-bit addressable range of the 68k CPU. So it would attempt to jump to that address and throw an address error exception instead (which in turn would reset the game via a jump to $0000008c).

For this particular game it wouldn't be a problem as the only vectors that actually contain valid addresses are IRQ1-4, all other vectors (hence all other CPU exceptions) point to the first byte of code at $0000008c. But if you're going to get into game hacking then you may well come across a game that points bus error/address error/etc vectors into valid debug code, so you need to be aware of this. Taito's Liquid Kids is one game that springs to mind which has a boat load of debug info dumped to screen in the event of an exception (the debug code was never removed from the final build).

As you'll be well aware the CRC routine itself does an 8-bit sum of all bytes in the roms, and that sum includes the checksum bytes themselves that start at address $4e0. This makes it a little awkward as it means you're forced to alter the value of another byte somewhere in the rom to make the final sum agree to the checksum byte. Without doing a full analysis of the game it's hard to say whether there are any unused bytes in the first 2 roms which you could change, instead of altering the bus error vector bytes.

I'm not sullying what you've done at all so please don't take what I've said with any offence, I'm just giving you some advice from a seasoned game hacker (especially of 68k code) to someone who has just completed his first 68k hack.

 

[edwoodjnr]

Thanks Adrian for your feedback it is much appreciated.

I wasn't aware that the first 256 long words were reserved for exception vectors and I will see if I can find another spare word on the first 2 ROMs to fix this but I think there is no room left in the roms apart from the location I chose. The alternative fix is easlily done to remove the CRC check entirely which doesn't use the location used by the exception vectors.
edwoodjnr2016-03-29 20:42:21

 

[cmonkey]

Bypassing the checksum result is, as you've already said, trivial. But it's nice to have it in there in the event that you do have a genuine bit error in the rom elsewhere (which would otherwise be missed if you bypassed the checksum result.

A simple trick to 'repurpose' some currently used bytes is to convert long branches to word branches (freeing up two bytes) or word branches to byte branches (freeing up two bytes). This technique can be applied to both absolute branches and also branches to subroutines. You can also replace a JSR (6 byte instruction) with an equivalent BSR (2 or 4 byte instruction, depending on the distance of the branch offset from the current PC).

Take for example the JSR at address $20c

00020c: jsr 26c.l 4eb9 0000 026c

This is an example of a waste of 4 bytes of rom as it's using a long word destination address to branch to a subroutine which is reachable with a single byte offset. As such it can be replaced with

00020c: bsr 26c 615e

The net result is exactly the same but you've just reclaimed 4 precious bytes, 2 of which you can now use to put your fix-up CRC bytes in leaving the bus error exception vector untouched.

Try it in MAME with the following command in the debugger :-

maincpu.mw@20c=615e

With enough time and determination you can usually reclaim enough bytes to completely insert new subroutines or jump to your own code.

Food Fight was one of the very first 68k arcade games (if not THE first). The code looks like it was written in a combination of 68k assembly language and a higher level language (probably C). The tool chain they used would probably have been quite basic, compared to games that were written when the 68k had gained popularity in the arcades. The above is proof, modern day assemblers would optimise branches to remove such redundant code as highlighted above, something which the early assemblers obviously weren't very good at doing.

cmonkey2016-03-29 21:43:16

 

[cmonkey]

I was correct. It was written in a combination of C and assembly. I'd never seen this article before today :-

http://www.classicarcademuseum.org/game-of-the-month/food-fight.htm

Makes for a good read on the technical aspects of the game.

 

[edwoodjnr]

Thanks Adrian for your advice, I agree that having the CRC is better to be there and will upload the corrected patch files to each of the roms once I have reclaimed the space and recalculated the CRC.

 

[backflipper]

Yjis is brilliant, thanks you both.

 

[cmonkey]

Thanks Adrian for your advice, I agree that having the CRC is better to be there and will upload the corrected patch files to each of the roms once I have reclaimed the space and recalculated the CRC.

Always happy to offer advice to budding game hackers!

It's debatable whether it's worth changing your patch files now as, like I said in my earlier message, in it's current patched state the game will reset via an address error exception in the very unlikely event that it experiences a bus error, due to the bus error vector being invalid. The advice I gave you is more for the future, when you release your next big 68k game hack. Touching the exception vectors is, more often than not, discouraged.

Can't take it away from you though, you've done a truly amazing job here. Well done indeed.

 

[rcantor77]

I had missed this... cracking work.

I just need to get myself a Food Fight cab now...