|
Patched Robotron 2084 by Christian Gingras
#335098 - 12/12/14 05:50 PM
|
|
|
|
|
|
Re: Patched Robotron 2084 by Christian Gingras
[Re: McHale]
#335107 - 12/12/14 09:45 PM
|
|
|
|
|
|
Re: Patched Robotron 2084 by Christian Gingras
[Re: Robbbert]
#335120 - 12/13/14 06:34 PM
|
|
|
|
|
|
Re: Patched Robotron 2084 by Christian Gingras
[Re: krick]
#335122 - 12/13/14 06:52 PM
|
|
|
|
|
|
Re: Patched Robotron 2084 by Christian Gingras
[Re: Robbbert]
#335129 - 12/14/14 01:15 AM
|
|
|
|
|
|
Re: Patched Robotron 2084 by Christian Gingras
[Re: krick]
#335132 - 12/14/14 02:30 AM
|
|
|
|
|
|
Re: Patched Robotron 2084 by Christian Gingras
[Re: Robbbert]
#335152 - 12/15/14 07:35 AM
|
|
|
This might be useful...
Commented Pac-Man disassembly:
https://web.archive.org/web/200910031710.../PacmanASM.html
I was looking at Don Hodges page and comparing his Pinky fix to the posted Inky fix to see why they're not quite done the same way. It looks like for the Pinky fix, the call to the subroutine takes the same space as three instructions.
So this original code (three lines in the disassembly)...
2795 29 ADD HL, HL ; double Pac-man's direction vector
2796 29 ADD HL, HL ; quadruple Pac-man's direction vector
2797 19 ADD HL, DE ; add result to Pac-Man's position to give target
Is replaced by this one that calls the subroutine (one line in the disassembly)...
2795 CD F0 2F CALL #2FF0 ; add 4x dir. vector to Pac's position
However, in the Inky code, the fix can't be done quite the same way, because there's one less line (instruction) since pac-man's direction vector is only doubled (not quadrupled).
So to fit the call in, the code has to also replace the line that loads the pacman offset (from address 4D1C) so now the subroutine needs to do the load. Additionally, when the Inky subroutine returns, it can't just return to the line after where it left off (as the Pinky code does), so it needs to jump back to a specific address.
Also, I noticed that the posted Inky fix uses the same area for the subroutine that the Pinky fix does, so code for the one of the subroutines will need to be shifted to a different location.
So, it looks like it will work, it's just done a bit differently.
Incidentally, how the heck does one determine what the checksum fixes should be when a ROM is modified?
|
GroovyMAME support forum on BYOAC
|
|
|
Re: Patched Robotron 2084 by Christian Gingras
[Re: krick]
#335227 - 12/17/14 09:29 AM
|
|
|
This page mentions how the checksum bytes are calculated...
http://www.donhodges.com/how_high_can_you_get2.htm
Quote:
The checksum routines in this game first add up all the even bytes in a memory bank and check against #00, and then repeat this for the odd numbered bytes in the memory bank. We do some quick math and discover that the new program’s even bytes add up to #18B less checksum bytes than the program it replaces, and the new program’s odd bytes add up to #187 more checksum bytes than the program it replaces. To fool the program’s checksum we therefore add #8B to an unused even memory location and #79 to an unused odd memory location.
|
GroovyMAME support forum on BYOAC
|
|
|
|
|
|
|
Re: Patched Robotron 2084 by Christian Gingras
[Re: krick]
#338577 - 04/04/15 12:37 AM
|
|
|
|
|
|
Re: Patched Robotron 2084 by Christian Gingras
[Re: krick]
#339466 - 05/01/15 09:49 AM
|
|
|
> I tried patching the pacman.6h ROM from the pacman set as described here...
>
> http://donhodges.com/pacman_pinky_explanation.htm
>
> ... but the game just gives a black screen. I'm not sure what I'm doing wrong.
>
> Here's the two lines I modified in my hex editor. The left side is the original ROM,
> the right side is the modified ROM.
Sorry about that, I had the checksums backwards. I have since fixed my web page.
Don Hodges
|
|
|
Index 
Threaded 
Patched Robotron 2084 by Christian Gingras
Reply
[Re: 
