Atari Food Fight - Improved Free Play

edwoodjnr

Active member
vacBacker
Feedback
2 (100%)
Credits
243CR
I made the changes as described by replacing the JSR with the BSR and inserted the calculated CRC difference value to the spare bytes on the rev 3 roms and it worked fine in MAME.

I will update the 4 patch files tomorrow after a bit more testing in MAME and original hardware.

Thanks again
 

edwoodjnr

Active member
vacBacker
Feedback
2 (100%)
Credits
243CR
All patch files have been updated, tested and added to my dropbox for download.

They are all working as before, including the new CRC value that is now stored in 2 reclaimed bytes.
 

edwoodjnr

Active member
vacBacker
Feedback
2 (100%)
Credits
243CR
I decided after 3 years that I would revisit this project as I didn't want an 'always on' free play option. I wanted a challenge and the PCB has a free play dip so why not use it.

Adding the code was more complicated than I thought it would be, the main challenge being trying to squeeze the 68k code into the little space available. When testing the patch I found the various attract screen stages function mostly the same but there are two in the sequence that are a little different that I needed to handle where code isnt executed if the free play dip is set.

I have updated the zip files in the original post so that setting the
dip #2 enables the patch and without it enabled the game PCB needs coins to be
inserted to begin a game.
 

Hurray Banana

Moderator
Staff member
vacBacker
Feedback
8 (100%)
Credits
2,717CR
Legend Gavin
smiley32.gif
 

philmurr

Active member
vacBacker
Feedback
46 (100%)
Credits
2,335CR
Nice update Gavin

Love the fact you weren’t happy with the original mod (which was great anyway) and made it perfect!

This was the mod that got me into doing my homebrew stuff, so thanks
smiley1.gif
 

smf

Active member
Credits
15CR
cmonkey said:
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.

https://www.classicarcademuseum.org/newpageb4e50452

Recently, ACAM had an opportunity to talk to Jonathan Hurd, the creator of Food Fight, to get the real story of the history of the game

...

The 68000 platform also allowed us to write a lot of the game in C rather than assembly language. The C compiler was a bit buggy and inefficient, so I wrote and rewrote many of the time and space-sensitive portions of the code in assembler to make them run faster. But having most of the game written in C allowed for great flexibility, so when someone suggested an idea it was easy to try it, see what it looked like, and make refinements.







cmonkey said:
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).

The 68000 doesn't care what you put in the top 8 bits of addresses. It would just try to fetch code from $99008c. This caused Apple a problem when they tried to ship a 68020 Mac

https://en.wikipedia.org/wiki/Mac_OS_memory_management#32-bit_clean

What happens next would depend on how the food fight board responds to that address, it could assert BERR which would cause a bus error (and as it's the bus error exception that it's trying to deal with would turn into a double bus fault and the 68000 would just shut down).

If it doesn't then incomplete address decoding could cause it to fetch data from somewhere else, or if the board just doesn't drive anything on the bus then the previous contents will stay their until it leaks away. Executing random data will end up with a random result, all bets are off.

If there is nothing on the board that ever asserts BERR, then it will probably never fetch the vector in the first place.

smf2019-06-17 11:54:59
 

edwoodjnr

Active member
vacBacker
Feedback
2 (100%)
Credits
243CR
It is now 4 years later and time for another update...

When the free play DIP switch is set on unmodified roms both cone button LEDs blink every other second. This is due to the free play switch being constantly hit with 2 credits that leaves you on a screen asking you to press player 1 or player 2 to start. To enable the full attract mode sequence in the previous version I had to stop this but this also prevented the LEDs from being lit.

This new version retains all the features of the previous version but now includes the blinking LEDs when the free play DIP is set.

You can download the patch files to update your own roms here:


or if you prefer the already patched files from here:

 
Top