Pole Position Free Play w/attract mode

[Paul Olson]

If anyone takes this on, I was the one that reported the shifter problem. The shifter worked correctly in test mode, but wouldn't shift while playing. Swapping back to the original roms solved the shifter issue.

If you need someone to test, just send me the images, and I will burn and test.

 

[scottmaggie]

Pole Position freeplay....

Bump on this. I'd love a set for my PPII Cockpit once this is good to go.

Also I don't have a ROM burner but would also happily beta test. If I can help in anyway just ask.

 

[ajcrm125]

I've been disassembling and documenting the the entire PP code to help me debug the PolePosition Clone project and the factory code actually contains some free play elements!

Here's some of the disassembly (strings are detected by a custom script I wrote):

;==============================================================================
; String structures
ORG 110B: string <$4CC7> "ACCEL " <2F>
ORG 1114: string <$4CD3> "BRAKE " <2F>
ORG 111D: string <$4D04> "STEERING " <2F>
ORG 1129: string <$4D13> "SHIFT " <2F>
ORG 1132: string <$4D47> "SOUND " <2F>
ORG 113B: string <$4D87> "COIN1 " <2F>
ORG 1144: string         "COIN" <2F>
ORG 1149: string         "CREDIT <2F>
ORG 1150: string <$4DC7> "COIN2 " <2F>
[COLOR="Red"]ORG 1159: string <$4D87> "FREE PLAY              " <2F>[/COLOR]
ORG 1173: string <$4DC7> "                       " <2F>
ORG 118D: string <$4E08> "TIME " <2F>
ORG 1195: string <$4E48> "GOAL " <2F>
ORG 119D: string <$4E84> "EXTENDED RANK " <2F>
ORG 11AE: string <$4EC4> "PRACTICE RANK " <2F>
ORG 11BF: string <$4C89> "RAM OK" <2F>
ORG 11C8: string <$4C95> "ROM OK" <2F>
ORG 11D1: string <$4C89> "RAM " <2F>
ORG 11D8: string <$4C95> "ROM " <2F>
ORG 11DF: string <$4F44> "HIGH SCORE INITIALIZED" <2F>
ORG 11F8: string <$4F04> "AUTO START" <2F>
ORG 1205: string <$4F04> "MANUAL START" <2F>

;==============================================================================
; Print "FREE PLAY" to screen
0C6E: E1            pop  hl
0C6F: 21 59 11      ld   hl,[COLOR="Red"]$1159[/COLOR]   ; Point to "Free Play" string struct
0C72: CD A8 0F      call $0FA8	    ; Print string

During test mode where it checks dip switch settings I can see a line that jumps to that routine that prints "FREE PLAY" to the screen. Not sure if this path never gets executed because Atari/Namco decided to change of the DIP switch decode or perhaps this feature was never finished?

Needless to say the PPClone will need freeplay. I'll be looking into this further so stay tuned...

 

[mattosborn]

I've been disassembling and documenting the the entire PP code to help me debug the PolePosition Clone project and the factory code actually contains some free play elements!

....

During test mode where it checks dip switch settings I can see a line that jumps to that routine that prints "FREE PLAY" to the screen. Not sure if this path never gets executed because Atari/Namco decided to change of the DIP switch decode or perhaps this feature was never finished?

Needless to say the PPClone will need freeplay. I'll be looking into this further so stay tuned...

Pole Position already has a DIP selectable Freeplay mode.... It's just that it sucks. What people are talking about here is Freeplay with Attract Mode.

 

[ajcrm125]

Ahhh ok that makes sense. I completely misunderstood this thread so when I spotted that in the code I though a stumbled onto something.

Oh well... back to work!

 

[mkillewald]

I did today

Chip 136014.103 and 136014.104 contain instructions and data split across them. To my surprise, GAME OVER was actually stored as raw text across the two chips (meaning there must be a routine that takes raw text and converts it to characters made up of a combination of graphic blocks).

In EPROM 103 at location $0392: 41 45 4F 45 ; A E O E
In EPROM 104 at location $0392: 47 4D 20 56 52 ; G M V R

Simply change these values to spaces (20):

103: $0392: 20 20 20 20 ; four spaces
104: $0392: 20 20 20 20 20 ; five spaces

And viola! No more "GAME OVER" in demo mode. Oh, and of course we need to fix up the checksums:
103: $1FFF: 7A
104: $1FFF: 44

Or people could have fun with the nine characters and put "FREE PLAY" or whatever they like; calculating the checksum would be an exercise for the reader.

I'm not sure if there are any real differences in the Ver1 and Ver2 ROMsets... but I finally got around to doing this on my PP1 (ver2) ROMs and I had to do the checksums differently. The checksums for both of those files was FF and to get them balanced I had to edit one of the NOOPs before that last section of nothings (FF)... as I couldn't get the FF's to balance out with just editing one of them.

The GAME OVER text is stored in the same areas as what is says above.

203: $1FA6: 9A
204: $1FA6: BC

thegleek, Bootay and myself just did this hack to remove GAME OVER on set of PP1 ver2 ROMs, and... it worked! Thanks to both of you for posting the original info and the followup with the ver2 checksums. We're ROM hacking noobs.

 

[HudsonArcade]

Pole Position already has a DIP selectable Freeplay mode.... It's just that it sucks. What people are talking about here is Freeplay with Attract Mode.

Pole position also has a start button input... that's grounded at the edge connector, so that when you're in free play, it continuously cycles through games.

 

[thegleek]

I'm in full understanding of how to take a rom image into hex editor and ascii hack it, but how did you come up with that checksum value and location? was it something to do with the java jar on your website? i'm confused.

 

[ajcrm125]

If you dissassemble the ROMs you'll spot a crc check subroutine that calculates the crc for the whole program ROM and compares it to a known value. So you can either muck with the unused data to get the checksum to match the expected checksum ... Or you can just change the expected checksum.

;==============================================================================
; ROM Validation Test
; Basically, the very last byte in each rom contains the sum of the all of the
; other bytes in the ROM.
1053: 21 00 00      ld   hl,$0000	; load HL with $0000
1056: D5            push de		; save DE
1057: 11 FE 1F      ld   de,$1FFE	; DE = $1FFE
105A: 01 00 20      ld   bc,$2000	; BC = $2000 (8k) 1st ROM size	
105D: CD 68 10      call $1068	        ; Verify 1st ROM checksum ($0000-$1FFF) 
1060: 01 00 10      ld   bc,$1000	; now set BC = $1000 (4k) 2nd ROM size
1063: CD 68 10      call $1068        	; Verify 2nd ROM checksum ($2000-$2FFF) 
1066: D1            pop  de		; both match... so we can return.
1067: C9            ret
;==============================================================================

;==============================================================================
; ROM Checksum calculator. 
; This routine adds all the bytes from HL to HL+BC and compares the sum to
; (DE). If they don't match.. we have a fail.Essentially this function takes (HL+BC-1) and compares it to (DE).
1068: AF            xor  a		; clear A
1069: 86            add  a,(hl)		; A = A + (HL) is pointing to
106A: 32 00 A1      ld   ($A100),a	; clear watchdog
106D: 23            inc  hl		; HL++
106E: 0D            dec  c		; 
106F: 20 F8         jr   nz,$1069	; 
1071: 10 F6         djnz $1069		; Keep going back to $1069 until BC == 0 	
1073: 4F            ld   c,a		; Take the last value from (HL-1) and toss it into C
1074: 1A            ld   a,(de)		; Grab value from (DE)
1075: B9            cp   c			; and compare them...
1076: 20 02         jr   nz,$107A	; if  what's in HL != what's in DE,  goto $107A
1078: 13            inc  de		; otherwise they match. and return
1079: C9            ret			;

107A: 7C            ld   a,h	        ; 
107B: 1F            rra                 ;
107C: 1F            rra                 ;
107D: 1F            rra                 ;
107E: 1F            rra                 ;
107F: E6 01         and  $01            ;

1081: CD 07 0F      call $0F07          ; Clear screen
1084: F5            push af             ;
1085: 21 D8 11      ld   hl,$11D8       ;
1088: CD A8 0F      call $0FA8          ; Print "ROM" string
108B: F1            pop  af             ;
108C: CD DC 0F      call $0FDC          ; Prints failing rom value
108F: F3            di                  ;
1090: AF            xor  a              ;
1091: 32 07 A0      ld   ($A007),a      ;
1094: C3 94 10      jp   $1094          ; ENDLESS LOOP! :-(

 

[DarrenF]

So you can either muck with the unused data to get the checksum to match the expected checksum ... Or you can just change the expected checksum.

OR there's always the shortcut approach. Hack the code to bypass the ROM checks entirely, or to 'pass' them regardless of the result of the checksum.

 

[mattosborn]

OR there's always the shortcut approach. Hack the code to bypass the ROM checks entirely, or to 'pass' them regardless of the result of the checksum.

I may bypass/nullify the checksum routine while I'm developing a mod, but I like to put it back in when I'm done (if it's not much of a hassle).

 

[ajcrm125]

I may bypass/nullify the checksum routine while I'm developing a mod, but I like to put it back in when I'm done (if it's not much of a hassle).

+1
And in reality it shouldn't be right? Bypass for debug and once you have your code nailed down, just compute the CRC and stick it in the last byte.

 

[DogP]

If you dissassemble the ROMs you'll spot a crc check subroutine that calculates the crc for the whole program ROM and compares it to a known value. So you can either muck with the unused data to get the checksum to match the expected checksum ... Or you can just change the expected checksum.

;==============================================================================
; ROM Validation Test
; Basically, the very last byte in each rom contains the sum of the all of the
; other bytes in the ROM.
1053: 21 00 00      ld   hl,$0000	; load HL with $0000
1056: D5            push de		; save DE
1057: 11 FE 1F      ld   de,$1FFE	; DE = $1FFE
105A: 01 00 20      ld   bc,$2000	; BC = $2000 (8k) 1st ROM size	
105D: CD 68 10      call $1068	        ; Verify 1st ROM checksum ($0000-$1FFF) 
1060: 01 00 10      ld   bc,$1000	; now set BC = $1000 (4k) 2nd ROM size
1063: CD 68 10      call $1068        	; Verify 2nd ROM checksum ($2000-$2FFF) 
1066: D1            pop  de		; both match... so we can return.
1067: C9            ret
;==============================================================================

;==============================================================================
; ROM Checksum calculator. 
; This routine adds all the bytes from HL to HL+BC and compares the sum to
; (DE). If they don't match.. we have a fail.Essentially this function takes (HL+BC-1) and compares it to (DE).
1068: AF            xor  a		; clear A
1069: 86            add  a,(hl)		; A = A + (HL) is pointing to
106A: 32 00 A1      ld   ($A100),a	; clear watchdog
106D: 23            inc  hl		; HL++
106E: 0D            dec  c		; 
106F: 20 F8         jr   nz,$1069	; 
1071: 10 F6         djnz $1069		; Keep going back to $1069 until BC == 0 	
1073: 4F            ld   c,a		; Take the last value from (HL-1) and toss it into C
1074: 1A            ld   a,(de)		; Grab value from (DE)
1075: B9            cp   c			; and compare them...
1076: 20 02         jr   nz,$107A	; if  what's in HL != what's in DE,  goto $107A
1078: 13            inc  de		; otherwise they match. and return
1079: C9            ret			;

107A: 7C            ld   a,h	        ; 
107B: 1F            rra                 ;
107C: 1F            rra                 ;
107D: 1F            rra                 ;
107E: 1F            rra                 ;
107F: E6 01         and  $01            ;

1081: CD 07 0F      call $0F07          ; Clear screen
1084: F5            push af             ;
1085: 21 D8 11      ld   hl,$11D8       ;
1088: CD A8 0F      call $0FA8          ; Print "ROM" string
108B: F1            pop  af             ;
108C: CD DC 0F      call $0FDC          ; Prints failing rom value
108F: F3            di                  ;
1090: AF            xor  a              ;
1091: 32 07 A0      ld   ($A007),a      ;
1094: C3 94 10      jp   $1094          ; ENDLESS LOOP! :-(

Don't you love it when you dump a ROM and find that the programmer was nice enough to leave their comments in.

DogP

 

[mattosborn]

+1
And in reality it shouldn't be right? Bypass for debug and once you have your code nailed down, just compute the CRC and stick it in the last byte.

Sure, in this particular case (PP) it's very simple. But some games are far less straightforward. Some may checksum a bunch of sub-regions instead of just one per ROM. And if you have to deal with encryption and/or tricky protection (anti-bootleg measures) then you might be wise to take the easy route and just make one simple change to a conditional statement (making the checksum result irrelevant).

 

[ajcrm125]

Don't you love it when you dump a ROM and find that the programmer was nice enough to leave their comments in.

DogP

Those are my comments.
You won't get any comments from a ROM dump. All that stuff gets lost during assembly and all you are left with is machine code.

 

[mattosborn]

Those are my comments.
You won't get any comments from a ROM dump. All that stuff gets lost during assembly and all you are left with is machine code.

No, no, no.... You just need to add the -IncludeDevComments switch to your disassembler! <--- note winky face

 

[ajcrm125]

No, no, no.... You just need to add the -IncludeDevComments switch to your disassembler! <--- note winky face

NOW you tell me. All those countless hours reverse engineering Pole Position code.. what a waste.

 

[DogP]

Don't you love it when you dump a ROM and find that the programmer was nice enough to leave their comments in. <--- note winky face

Those are my comments.
You won't get any comments from a ROM dump. All that stuff gets lost during assembly and all you are left with is machine code.

Yes, sorry... I forgot the note on the winky face... fixed.

DogP

 

[meestermole]

Hey there folks.

I'm interested in removing the GAME OVER from attract mode as well.
I have a ROM Burner, but limited knowledge in how to disassemble/reassemble the code back to the ROM images.

I've found a few resources on the web, like Jeff's Romhack, and Zophar's.

Can someone help out with some other resources to help me understand the routines, or the processes involved in manipulating ROMs?

Thanks!

 

[mattosborn]

Hey there folks.

I'm interested in removing the GAME OVER from attract mode as well.
I have a ROM Burner, but limited knowledge in how to disassemble/reassemble the code back to the ROM images.

I've found a few resources on the web, like Jeff's Romhack, and Zophar's.

Can someone help out with some other resources to help me understand the routines, or the processes involved in manipulating ROMs?

Thanks!

mjenison already posted in this thread exactly what you need to change to remove "GAME OVER" (it's quoted above in post #66).
Why exactly do people want to do this? Because of screen burn? Removing that will only be useful if you've installed a new monitor... otherwise you're going to be able to read "GAME OVER" anyway due to burn. A better hack would be to change the text color to black.