Where are the maze 'permissions' held in Jr. Pac-Man?

[PacManPlus]

Does anyone happen to know what address the maze 'permissions' start in Jr Pac-Man? I was able to find where the display mazes are, but I am having trouble with the area that tells how the sprites follow the maze...

 

TIA

[PacManPlus]

ok - I'm guessing it's done a different way than it was in Ms Pac-Man. I searched for what I thought would be the permission bytes for the first maze in Jr but came up empty. now I'm really confused...

 

*edit*: This is why I'm asking:

[uosipa llamxew]

NEAT!

 

Wish I could provide some help... instead I'll just bump this thread up... then the right person to help might see it. :-)

[ATARI TROLL]

I am not exactly sure where they are at. Do have a playable .bin??? I was messing with MS. PACMAN and found something interesting. Using a HEX editor and messing with the mazes (LMFAO) I made her jump all over the screen. I was doing a trial and error thing. I trashed the rom and am starting over....LOL. You don't have any pointers do you for color change on mazes??

 

 

[Nukey Shay]

I don't know where the internal map is for the game...but since each direction only requires 1 bit to be enabled, each byte in the map would only use 4 bits (leaving 4 left over). It could very well be that these nybbles that define where a sprite can move to are mixed with other data...and even worse, since Jr. uses multiple mazes with multiple maps, this data could possibly be located at (indirect),y addesses.

 

Step 1 would be locating the player's controller routine. It will be testing if a desired direction is possible by using some type of bit test from these tables...likely using an AND #$F0 or AND #$0F to strip away the bits that have nothing to do with the map (i.e. get rid of the mixed data).

 

And changing the color would be easier to find...just locate an instruction that saves data to the color register...and look above that instruction to see where that value is coming from. If the instruction that is doing the saving is located on a label...you'd search for areas of the program that jump to this label.

 

When hacking games by using assembly files, it's important that you don't shift memory locations around. In other words, if you delete an instruction, you need to fill this "hole" that you just created (or when the program is assembled, the rest of the program will move downward in memory to fill it...if there were indirect jump points in the game that were not yet labelled, the game may crash when it tries to do the jump (because it would land at the wrong address).

Example:

Suppose the game decrements ram location $B0 to subtract a player's reserve life by using the following instruction...

F080: DEC $B0

F082: (program continues...)

You can't simply erase that line from the disassembly...because then whatever was at address F082 onward will now exist starting from F080.

A solution to removing instructions is to use NOP instructions to cover the spots that instruction took...

F080: NOP

F081: NOP

F082: (program continues...)

 

 

 

Similarly, when you hack the game to include additional instructions, you need to locate or create an area of memory that is unused by the original program...and change the original routine to perform a jump to this address (where it can perform your added instruction PLUS the instuctions that it was already supposed to do), and then jump back to the routine. When dealing with bankswitched carts, this "reclaimed" area of memory must also exist in the same 1k, 2k, or 4k bank of memory that the hacked routine exists (depending on the bankswitching method used).

[ATARI TROLL]

Thanks Nukey. I am going to read some up on the 2600 101 that Andrew Davie, Jentsch, Yourself and others post in from time to time. I am finding the trial and error thing to be quite humerous . CPUWIZ is correct on the RAM size. My target is still 8kb. The challenge is fun when your not using HOM or HOM2. Kinda goes along the same lines of how you wash your car (LMFAO -bad analogy here). You can take it to be detailed and they will miss something. If you wash and wax your vehicle by hand, you find every nit noid thing wrong and try to fix it. That is why I am going to take my time with Blinky's Revenge (Title is not set in stone either).

 

Cheers

[Nukey Shay]

As more of the disassembly is labelled, you are able to shift more memory around. For instance, when you see indirect addressing being used (i.e. LDA ($nn),Y), those values saved to the ram address $nn (and the ram address following) are either "hard-coded" (as in LDA #$F0...STA $nn) or from a table (as in LDA LF080,X...STA $nn). The way that you find them is by searching the disassembly for every instance that those ram addresses are changed. Once a disassembly is completely reverse-engineered and labelled, you no longer need to worry about shifting memory around or filling "holes"...Dasm will be able to adjust all of those hard-coded or table values for you. Until then, you need to keep everything from moving around when Dasm compiles.

And be sure to make very small changes, and make a backup each time you change the file. That way, you can better correct things that have been altered...and find the source of bugs more easily.

Making very small changes to target ram addresses (as an experiment) can also assist in discovering what those ram locations pertain to...and makes the assembly file much more readable. Which is clearer...LDA $nn or LDA PlayerX

Hacking in this manner, you might want to name the working file as something that will show up at the top of the emulator's list (like 1test.bin). That way, it will be first when you run the emulator to try it. In addition, it saves on keystrokes to make a batch file to compile the assembly...like this:

 

dasm mspac1.asm -f3 -omspac1.bin

dasm mspac2.asm -f3 -omspac2.bin

copy /b mspac1.bin+mspac2.bin 1msHACK.bin

move 1msHACK.bin c:atariroms

 

This sample batch file compiles both parts of the 8k game, joins them together (the "1" is added to the name so that the game will appear at the top of the emulator's file menu), and moves the finished binary to the emulator's rom directory. Much speedier to just type X to do all of that for you