Ms Pac freeplay w/ attract mode?

Scucci

Well-known member
Joined
Feb 6, 2003
Messages
4,497
Reaction score
94
Location
Nashville, Tennessee
Ms Pac freeplay w/ attract mode. Please help check the code.

Subject is kind of self explanatory... but...

Does anyone know if anyone has made a rom hack that will allow you to put the game into freeplay, but still have the game go through it's attract mode?
 
Last edited:
Subject is kind of self explanatory... but...

Does anyone know if anyone has made a rom hack that will allow you to put the game into freeplay, but still have the game go through it's attract mode?

That's a feature of the "96 in 1" Multi Pac, the games also load without going through the boot up screen. I'm out at the moment, but we'll run more with the Exidy project.
 
Skipping self-test is a trivial mod...

MsPac is well enough documented that it'd be pretty trivial to attract mode to free play.

Right now, there's separate game modes for attract mode, coined up mode, game mode, intermission mode, etc...

It's just a matter of modifying the attract mode routine to accept credits without moving to coined-up mode (nop out a single routine), then have it jump to the end of the 'coined up' routine to check the start buttons and possibly start the game.

It's a good newbie assembly language project.
 
Skipping self-test is a trivial mod...

MsPac is well enough documented that it'd be pretty trivial to attract mode to free play.

Right now, there's separate game modes for attract mode, coined up mode, game mode, intermission mode, etc...

It's just a matter of modifying the attract mode routine to accept credits without moving to coined-up mode (nop out a single routine), then have it jump to the end of the 'coined up' routine to check the start buttons and possibly start the game.

It's a good newbie assembly language project.

Great... assembly. If it was a newbie visual basic project (to give you an idea of how low I am on the totem pole), then it'd be cake. I guess I should start reading up and see how it goes.
 
Okay, well... that was easy. Found most of the code snipets I needed floating around the web.

The freeplay was simple... it turned out it was already made (for Pac-Man)... stumbled across it. But it had the problem of making the first maze blue everytime... so... found another bit of code that fixed that issue... So... yay. Saddly, it takes 3 ERPOMs to work...

6J is replaced pretty much to just disable the checksum crap, and 6E for the attract mode stuff, and 6F for the extra space to fix the blue maze bug...

I'll start looking into balance'ng the checksums later, for now... my brain is friggin' fried... it's messy, but it works.


EDIT: That was a quick break... down to 2 chips. Just 6E and 6J so speedchips won't be an issue anymore. Now... another break, then I'll try to balance out some check sums to get it down to 1 chip...
 

Attachments

  • 0002.jpg
    0002.jpg
    7.8 KB · Views: 45
  • 0003.jpg
    0003.jpg
    18.1 KB · Views: 35
Last edited:
Well, I put the original 6J back into the mix and I have the checksum for 6E back to F400, but I'm still getting a ROM 0 error...

How exactly is the checksum figured out on these guys? Is there some special trick I'm missing? I edited the noops (00's) at the end of the file to get the checksum back to F400, but... well, still not working. I'd really like to get this thing down to 1 chip so I don't have to replace 6J also just for the checksum hack.
 
Well, I put the original 6J back into the mix and I have the checksum for 6E back to F400, but I'm still getting a ROM 0 error...

How exactly is the checksum figured out on these guys? Is there some special trick I'm missing? I edited the noops (00's) at the end of the file to get the checksum back to F400, but... well, still not working. I'd really like to get this thing down to 1 chip so I don't have to replace 6J also just for the checksum hack.

Wonder if it might be easier to disable the check than to calc the new checksum?
 
Well, I put the original 6J back into the mix and I have the checksum for 6E back to F400, but I'm still getting a ROM 0 error...

How exactly is the checksum figured out on these guys? Is there some special trick I'm missing? I edited the noops (00's) at the end of the file to get the checksum back to F400, but... well, still not working. I'd really like to get this thing down to 1 chip so I don't have to replace 6J also just for the checksum hack.

The checksum routine is at 0x3000 -- figure it out ;)
 
Well, I put the original 6J back into the mix and I have the checksum for 6E back to F400, but I'm still getting a ROM 0 error...

How exactly is the checksum figured out on these guys? Is there some special trick I'm missing? I edited the noops (00's) at the end of the file to get the checksum back to F400, but... well, still not working. I'd really like to get this thing down to 1 chip so I don't have to replace 6J also just for the checksum hack.

Are you debugging this in MAME? If so, just run the original roms generating a trace file, then run the hacked roms running a trace file, and compare the two trace files. Then breakpoint where they diverge; one value will contain the address of the correct checksum value, and the other the calculated value. Adjust spare bytes to get the correct match.
 
It doesn't matter if it's trivial or not, it's necessary if you're going to play with the code.

No, it's not... there's plenty of empty space where you can change bytes to fix the checksums. Note that all the games in 6-Pac still run self-test.

Self-test was just as much a part of playing games as anything else when I was a kid... we'd all kick the coin door to see the show :)
 
I love reading when smart people all start posting... except for the fact that I don't understand anything!!! :D
 
Nah... I just wrote a simple c program to auto-fix the checksums for me :)

Well, lemme borrow it. lol

Seriously though, if the checksum is good... why would the rom be failing selftest? Everything working in MAME perfectly with the checksum disabled. As long as the new checksum matches the old one (F400) then the game should just boot up normally shouldn't it?
 
Well, lemme borrow it. lol

Seriously though, if the checksum is good... why would the rom be failing selftest? Everything working in MAME perfectly with the checksum disabled. As long as the new checksum matches the old one (F400) then the game should just boot up normally shouldn't it?

What are you using to compute the checksums? Just set a watchpoint in the MAME debugger at the JNZ in the checksum routine, and see what the checksum routine is coming up with (should always be zero)
 
What are you using to compute the checksums? Just set a watchpoint in the MAME debugger at the JNZ in the checksum routine, and see what the checksum routine is coming up with (should always be zero)

I'm using the built in checksum tool in Hex WorkShop. I've never had any problems with it before. I have it set at 16-bit.

I have a breakpoint set in MAME at 301A jr nz,$3031. I'm seeing two different values, in the MAME debugger, between my hacked 6E and the original 6E. I have no idea what these values mean... I'll start reading up on the debugger and see if I can figure something out. In the mean time, please feel free to keep helping. lol
 
I'm assuming (since I don't actually know assembly) that BC is what I need to be 00?
I was originally at 94, after plugging in FF in all of the spare noops at the end of the ROM I've managed to get it down to 39... there has to be a better way to get that down besides plugging in FF, right?
 
Back
Top Bottom