2600 Rom Comparisions and Dumps

[Rom Hunter]

Will do.

 

Here it is:

Roms6.zip

 

BTW: am I right that the only truly glitched ROM until now is Cross Force [a]?

 

Edited October 16, 2008 by Rom Hunter

[Nukey Shay]

That sort of depends on how you define "glitch". No Escape! [a], for example, is obviously a bad dump...that illegal 3-cycle NOP opcode is a dead giveaway. Enduro-Digivision [a] is equally obvious (altered SEI opcode on powerup), even tho that glitch does not affect the game (no interrupts used). The same applies to most glitches discovered to be where an opcode differs in comparison by an upper-nybble change only and the argument stays the same.

[Nukey Shay]

Gopher (Unknown) PAL has timer values bumped at $F031 and $F53E in the program between versions (affecting the scanline count). Neither version has a correct count (316 vs. 318)...but neither one of them is a bad dump, either. Too specific to be coincidence.

 

Grand Prix (CCE) is another oddball. 5 differing bytes affecting the CCE logo only (thicker sides on the right side of letters). Neither one a bad dump. Weird that they keep making alternate versions of their logo!

 

Gravitar [a]...changed bytes one the hotspots. Bad.

 

Great Escape (PAL) [a] has an altered byte for the MSB of the NMI vector. The last used addresses in the rom is a 32-byte table starting at $FFD9...never reaching the NMI space. Bad dump.

 

H.E.R.O. [a1] and [a2] have differences confined to the hotspots. [a2] also has the incorrect ORIGIN block listed for the second bank in it's vectors (doesn't matter to the 2600). Both bad dumps.

 

Ikari Warriors [a] has differences listed for the MSB of the NMI vector (unused in F6 bankswitched games). Rather than reflect the ORIGIN block for each bank as most games do (in addition to the "original"), the unused vector points to block $7F in 3 of the banks. Bad dump.

 

International Soccer [a] I had already looked at previously. Missing byte in the interrupt's MSB (should be identical to reset vector). Bad dump.

 

Jawbreaker (Unknown) PAL has a slightly-different color scheme and changed timer values between the versions (the latter makes an erratic count in [a]). Neither one is a bad dump due to the specific addresses altered...but nevertheless, "original" is a stable game. Your call if you want to dump [a] for being unstable. It could be an earlier version

 

Joust (PAL) [a] has altered hotspot values. Bad dump.

 

Jr. Pac-Man has changes in RAM bytes (all value $FF in "original", $00 in [a]). Based on omega's method of just zeroing out all of these, you might just want to keep the [a] file and consider the "original" to be bad. Or, keep the "original" (due to it's name) and remove the [a] file. One of them definately is bad. Pick one.

[Rom Hunter]

Very clear, Nukey.

 

Ok, Gopher, Grand Prix and Jawbreaker stay in.

 

All others are REMOVED.

 

Next zip:

Roms7.zip

 

Edited October 16, 2008 by Rom Hunter

[Nukey Shay]

Jungle Hunt (PAL) [a1] and [a2] have altered values in hotspots only. Both Bad dumps.

 

Jungle Hunt (CCE) simply features an erased bitmap for the game logo in [a]. Neither one is a bad dump. Just CCE keeping us busy. [a] also does the hotspot change, but the specific erased bitmap is enough evidence that it's not a bad dump. Could be a hack, tho (opposed to an actual dump of a chip).

 

Kangaroo (PAL) [a] has the hotspot values changed. Bad dump.

 

Keystone Kappers (CCE) The [a] version disables the scrolling feature of the copyright at $F9A3...also zeros out all the bytes in the bitmap not used. The wider right half of the letters shows up here too. Neither one a bad dump.

 

King Kong (PAL) This game alters the overscan timer at $F3BA. That's the only difference, and it makes [a] run at the correct number of scanlines (312) vs. the original that only does 292. Neither one is a bad dump based on this evidence...but I suppose that it's unknown if the [a] version is a hack to correct a cart's incorrect scanline count. Anyone have an actual cart at 312 scanlines?

 

Kung-Fu Master (PAL) [a] features changes on hotspot addresses only. Bad dump.

 

Lord Of The Rings [a] I couldn't get to boot! Only 6 bytes differ...but one is in the bankswitching routine. Broken code suspected. The original works fine.

BTW I thought that only one prototype existed? Was this game dumped more than once? More likely, somebody was messing with the code to create the bad [a]lternate.

 

Lost Luggage differences are apparent just playing the roms. [a] features additional stuff (like the animation sequence at the beginning...a single baggage handler throwing suitcases in reserve). Neither one bad, original = earlier version that just sticks more to gameplay. More disassembly needed to search for all the additions...but I really can't stomach this game

 

Mario Bros. (PAL) [a] differs only on the hotspots. Bad dump.

 

MASH (CCE) [a]lternate version erases the bitmapped CCE logo. Neither one a bad dump...and that is the only difference between them.

[Tempest]

BTW I thought that only one prototype existed? Was this game dumped more than once? More likely, somebody was messing with the code to create the bad [a]lternate.

Nope there are two:

 

http://www.atariprotos.com/2600/software/lotr/lotr.htm

 

One is a slightly earlier version than the other. The differences between the two are very minor (probably only a day or two apart).

 

Tempest

[Rom Hunter]

Ok, everything corrected.

 

ROMs REMOVED:

 

Jungle Hunt (1983) (Atari - GCC, Mike Feinstein, John Allred) (CX2688, CX2688P) (PAL) [a1]

Jungle Hunt (1983) (Atari - GCC, Mike Feinstein, John Allred) (CX2688, CX2688P) (PAL) [a2]

 

Kangaroo (1983) (Atari - GCC, Kevin Osborn) (CX2689, CX2689P) (PAL) [a]

 

Kung-Fu Master (1987) (Activision, Dan Kitchen) (EAX-039-04B, EAX-039-04I) (PAL) [a]

 

Mario Bros. (1983) (Atari, Dan Hitchens) (CX2697, CX2697P) (PAL) [a]

 

The rest stays in.

 

Next zip:

Roms8.zip

 

Beware:

A Mysterious Thief has a CCE version (with [a]lternate) and a Vidco version (with [a]lternate).

 

My Golf has two [a]lternates

 

[Nukey Shay]

I dunno what the story is with Mega Force (PAL). Only a single byte is changed at $FFEF (from $00 in the original to $80 in the [a]lternate), and it's part of a larger 15-byte table starting at $FFEB. Judging from other values present in the table, it looks like [a] is a bad dump. But without studying the disassembly, it's difficult to say for sure.

Need to revisit this one down the line.

 

Megamania (Unknown) PAL "Original" version just bumps an NTSC version to 316 scanlines (the colors and the rest remain unchanged). The [a] version corrects both problems...312 scanlines with the correct PAL palette. Something odd is that the "energy" text bitmaps have been erased in this corrected version. CCE's m.o.?

Neither version is a bad dump...[a] is just an updated version.

 

The same goes to Misterious Thief (CCE) (sic)...the [a]lternate version has some adjustments done to it to give it a better NTSC scanline count (267 in the original vs. 261 in [a]) and a stable line count when jumping/using console switches. [a] is just an updated version IMO.

 

Moon Patrol (PAL) only has values different in the BS hotspots. $FF's in the original and $00's in the [a]lternate. You can get rid of one of them.

 

Moonsweeper (PAL) [a] ...different values in the hotspots. $FF's in the original and $00's in the [a]lternate. You can get rid of one of those, too.

 

Mountian King differs only in hotspots ($xFF8-A) and RAM (the 1st two pages in each bank for FA bankswitching). A few varying values in the original vs. all $FF's in the [a]lternate. Your pick on which one to scratch.

 

Mr.Postman-O Carterio (CCE) [a] has only a single byte difference...a value placed at $F800 (this gives blank spaces in the score a dotted underscore). Pretty certian that it's just a bad dump...but you never know with CCE! j/k

I'd get rid of it.

 

Ms. Pac-Man (PAL) [a] has seemingly-random values in the hotspots. Bad dump.

 

Thanks for the headsup on My Golf (PAL). There's only differing values in [a1]'s hotspots (so you can get rid of that one), but [a2] has many things moved around. This second alternate needs disassembly-comparison to discover it's changes...but it appears to be pretty clear that it's a valid [a]lternate of the original (later version?).

 

Mysterious Thief (ZiMag) follows the same pattern of change that the CCE versions do, except in reverse order. The [a]lternate looks like it's the earlier version here. Neither is a bad dump.

[Omegamatrix]

King Kong (PAL) This game alters the overscan timer at $F3BA. That's the only difference, and it makes [a] run at the correct number of scanlines (312) vs. the original that only does 292. Neither one is a bad dump based on this evidence...but I suppose that it's unknown if the [a] version is a hack to correct a cart's incorrect scanline count. Anyone have an actual cart at 312 scanlines?

I have the [a] version on my 208 in 1 multicart. It wasn't the first time it was dumped though... I can't say if the pirate company did the hack, or if Tigervision fixed it and then it was hacked.

[Nukey Shay]

I just wanted to know it it physically existed that way.

Thanks!

 

BTW I think that Rom is considering pre-1992 hacks as being valid alternates (a good share of actual cartridges made back then are hacks of other games).

[Omegamatrix]

I found many of the games on the 208 in 1 multicart to be minor hacks. Most had the values loaded into the timers changed, that's it. What is strange is a lot of them were just a few scanlines like 314 to 304, 312 to 310, etc... It really made me wonder if there were some syncing issues with older TV's, and that a little less then 312 scanlines might work better. Just a way out guess though. I have no other explation why someone would alter two different counters on a functioning game from PAL compatible to still PAL compatible. There were also NTSC to PAL hacks. At least those made sens

 

 

link to the 208 in 1 multicart thread:

http://www.atariage.com/forums/index.php?s...9916&hl=208

[Rom Hunter]

Ok, everything corrected.

 

Alternates of Moon Patrol, Moonsweeper, Mountain King, Ms. Pac-Man and My Golf [a1] REMOVED

 

Also, I decided to remove the Mr. Postman [a] from CCE.

 

Stella.pro also labels this one as ad dump.

 

All others stay in.

 

Next zip:

Roms9.zip

 

[Nukey Shay]

No Escape! [a] I had already done. It contains an illegal opcode, a 3-cycle NOP, virtually guaranteeing that it's a bad dump.

 

No Escape! (PAL) [a] also contains an illegal opcode. At $F95A, the original game has a branch instruction (BNE $1979). The opcode is changed in [a] to be a 2-byte, 2 cycle NOP (NOP #$1C). The argument does not differ. Definately a bad dump.

 

Obelix differs only on the hotspots. $FF in the original, and $00 in [a]. Get rid of one of them.

 

 

 

Official Frogger...this game has a whole lot of code added to [a] that's blank in the original. Neither is a bad dump. More about this in a minute...

 

Official Frogger (Preview)...also contains a lot of added code/moved routines between the original and [a] versions. Neither is a bad dump.

 

The file sizes are the same for these, so I thought that I'd check out differences between the preview and full game files. What I found was that the [a]lternate full version is more similar to the [a]lternate preview version than any other comparison. I don't know what to make of this. Possibly the 2 alternates made about the same point during development (i.e. later than both original files)?

 

 

 

Omega Race has differences confined to the RAM pages in the 3 banks (randomish values in both files). No surprise there. You can get rid of one of them.

 

Open Seseme (PAL) - the [a]lternate has some valid code changes. Side-by-side comparisons between the 2 disassemblies needs to be done to discover changes between them, but neither one is a bad dump.

 

Oscar's Trash Race - there's a whole lot of added stuff to the original (much of what was completely blank in [a]. The [a]lternate is probably an earlier (demo?) version...neither one a bad dump.

 

Othello and Othello (PAL) need side-by-side disassembly comparisons with their [a]lternates. A lot of code shifting around. I don't suspect any of the 4 files to be bad dumps.

[Tempest]

Oscar's Trash Race - there's a whole lot of added stuff to the original (much of what was completely blank in [a]. The [a]lternate is probably an earlier (demo?) version...neither one a bad dump.

Is it this demo? http://www.atariprotos.com/2600/software/oscar/12382.htm

 

Othello and Othello (PAL) need side-by-side disassembly comparisons with their [a]lternates. A lot of code shifting around. I don't suspect any of the 4 files to be bad dumps.

Remember that there are two different known released versions of Othello. One had some minor graphical improvements and some sound differences.

 

Tempest

[Nukey Shay]

Is it this demo? http://www.atariprotos.com/2600/software/oscar/12382.htm

Yep...the pic in the link is the same thing you see in the [a]lternate file.

 

 

Remember that there are two different known released versions of Othello. One had some minor graphical improvements and some sound differences.

I didn't know that both were released by Atari. Thanks!

[Rom Hunter]

I didn't know that both were released by Atari. Thanks!

Yes, that's right.

 

I forgot about that.

 

Both the PAL and NTSC releases have two official versions.

 

Ok, the following ROMs are REMOVED:

 

No Escape! (Escape from Argos) (1982) (Imagic, Michael Greene) (720055-1A, IA3312) [a]

 

No Escape! (Escape from Argos) (1982) (Imagic, Michael Greene) (720055-2A, IA3312P) (PAL) [a]

 

Obelix (1983) (Atari, Andrew Fuchs, Jeffrey Gusman, Dave Jolly, Suki Lee) (CX26117) (PAL) [a]

 

Omega Race (Booster Grip) (1983) (CBS Electronics) (4L 2737 0000) [a]

 

 

The rest stays in.

 

Next zip:

Roms10.zip

 

[Nukey Shay]

Pac-Man (CCE)...neither one a bad dump. The CCE bitmapped logo (wider in [a]) just shifts foward 8 bytes to the next print characters in line.

 

Phaser Patrol...a lot of stuff added to [a] (that was blank in the original). Does this version seem more difficult to anyone else?

Neither is bad.

 

Phoenix (PAL) differs only on the hotspots. The original file appears to have the corresponding hotspot changed to $FF in each bank. The other hotspot's value is identical to what appears in [a] (makes me suspect that the [a] dump is the accurate one). Doesn't really matter either way when ignoring hotspot values...I just think that it's good evidence to choose [a] to keep rather than the original.

 

Same story for Pigs In Space (PAL). Hotspot values are all zeros, except the ones that are called in the original file. I'd keep the alternate and get rid of the original.

 

Pitfall II - the original file contains superfluous -unused- code in the 2nd bank...

* = $F000
   SEI
   JMP START

In the [a]lternate, these 4 bytes are changed to value $FF. I don't believe that either of them are bad dumps (and it doesn't matter to the 2600 either way, because the code is never executed).

 

Planet Patrol (PAL) ...shifting code again between the versions. Neither one is a bad dump (needs side-by-side disassembly to discover changes).

 

Planet Patrol (CCE) Game title is removed from the bitmapped logo in [a] (the only change). Neither one a bad dump.

 

Pole Position (PAL) Hotspot differences only. Again, the referenced hotspot in each bank of the original appears to contain the altered value. I'd get rid of it and keep [a].

 

Pressure Cooker (PAL) Hotspot differences here too. The same as the above...keep [a].

 

Private Eye Original game changes the reset vector to the 3rd byte for the 2nd bank (3-byte bankswitch instruction to go TO this bank exists on those 3 bytes). The [a] version executes this superfluous instruction. Neither one is a bad dump.

[Rom Hunter]

The [a]lternates of Phoenix, Pigs in Space, Pole Position and Pressure Cooker are REMOVED.

 

The rest stays in.

 

Thanks!

 

Next zip:

Roms11.zip

 

Edited October 20, 2008 by Rom Hunter

[Omegamatrix]

You can keep one copy of RealSports Soccer - Football and one copy of RealSports Tennis (PAL). It doesn't matter which copy as they are all the same except for the hotspots. Not sure of Quick Step though, if $0FF8 is the same as a hotspot (though I know it is used in the bankswitching). I know Nukey did said $xFF8, but I see a lot of $0FF9 and $1FF8 differences in the 8K games, and don't really recall one coming up at $0FF8 before.

 

file 1: Quick Step! (PAL).bin
file 2: Quick Step! (PAL) [a].bin

  file 1  file 2
0FF8	00	  FF



file 1: RealSports Soccer - Football  (PAL).bin
file 2: RealSports Soccer - Football  (PAL) [a].bin

  file 1  file 2
0FF9	FF	  00
1FF8	FF	  00



file 1: RealSports Tennis (PAL).bin
file 2: RealSports Tennis (PAL) [a1].bin
file 3: RealSports Tennis (PAL) [a2].bin

  file 1  file 2  file 3
0FF9	FF	  DA	  4A
1FF8	FF	  41	  41

[+Mitch]

Since Phaser Patrol was mentioned I thought I'd ask if a good dump of the PAL version of Phaser Patrol was made. The one that's out there is bad.

 

Mitch

[Omegamatrix]

All versions of Pyramid War are valid. The "original" has a glitch as soon as you hit the reset button to play the game. A little bit of white crap appears where the logo was. I've circled it here:

 

 

 

Both alternatives correct this. Also the difference between [a1] and [a2] is scanlines. a different value is loaded into the timer which decreases the scanlines in [a1] from 312 to 289. This is kind of between PAL and NTSC, but definitely was an intentional hack by some pirate company.

 

 

LFAD9:
ASL
BPL LFADE
AND #$80
LFADE:
ROR
BMI LFAE3
LDA #$80	   $88 in the alternatives
LFAE3:
LSR
LSR
LSR
STA $CF		$10 (or $11 in the alternatives)
STA HMCLR	  strobe
LFAEA:
LDY $CF		$10 or $11
STA WSYNC	  strobe
STA HMOVE	  strobe
LDA LFFA5,Y	glitch occurs when Y = 9, ie address $FFA5 + 9 = address $FFAE, which has value $E3
STA GRP0	   glitch is corrected in the alternates as Y never reaches 9
LDA LFF98,Y
STA GRP1
LDA LFFB5,Y
STA GRP0
LDA LFEC8,Y
STA $D1
LDX LFFE4,Y
LDA LFE8D,Y
LDY $D1
STY GRP1
STX GRP0
STA GRP1
STA GRP0
DEC $CF		never reaches zero before loop is exited
ASL $D0		$D0 intially is $41, it shifts left 8 times before it is zero
BNE LFAEA	  LFAEA label is never used anywhere else... Loop is exited when $D0 = zero
LDA #0
LDX #3
STA GRP1
STA GRP0
STA HMOVE
STA GRP1
LDA #$4C	   $2C in PAL [a1], which decreases the scanlines
STA TIM64T
JSR LF265

;------------------------------------------------------------------------------------------------------------

LFFA5:
.byte $00; |		| $FFA5
.byte $00; |		| $FFA6
.byte $00; |		| $FFA7
.byte $00; |		| $FFA8
.byte $00; |		| $FFA9
.byte $94; |X  X X  | $FFAA
.byte $A7; |X X  XXX| $FFAB
.byte $E4; |XXX  X  | $FFAC
.byte $94; |X  X X  | $FFAD
.byte $E3; |XXX   XX| $FFAE   $FFA5 + $09 (decimal 9)
.byte $00; |		| $FFAF
.byte $00; |		| $FFB0
.byte $00; |		| $FFB1
.byte $00; |		| $FFB2
.byte $00; |		| $FFB3
.byte $00; |		| $FFB4
LFFB5:
.byte $00; |		| $FFB5   $FFA5 + $10 (decimal 16)
.byte $00; |		| $FFB6   $FFA5 + $11 (decimal 17)
.byte $84; |X	X  | $FFB7
.byte $84; |X	X  | $FFB8
.byte $EE; |XXX XXX | $FFB9
.byte $AA; |X X X X | $FFBA
.byte $EA; |XXX X X | $FFBB

Edited October 19, 2008 by Omegamatrix

[Nukey Shay]

Bad in what way? I'm not familiar enough with PAL variations.

 

 

You can keep one copy of RealSports Soccer - Football and one copy of RealSports Tennis (PAL). It doesn't matter which copy as they are all the same except for the hotspots. Not sure of Quick Step though, if $0FF8 is the same as a hotspot (though I know it is used in the bankswitching). I know Nukey did said $xFF8, but I see a lot of $0FF9 and $1FF8 differences in the 8K games, and don't really recall one coming up at $0FF8 before.

 

Usually when you see $xFF8 referenced in the first bank, it's due to a superfluous instruction. The reverse is also true...$xFF9 referenced in the second. Because where you leave from one bank puts you at the end of that address in the other bank, some games just fill up that unaccessed space with the same instruction (i.e. bankswitch to THIS bank that we're already in).

Another culprit is the boot code. It's preferable that you keep identical reset vectors in both banks...so it's not uncommon to see something like this in the first bank:

 

START:

BIT $FFF8

JMP {cold start address}

 

...and this in the 2nd bank...

START:

BIT $FFF8

JMP {cold start address}

 

Identical code between them. The BIT instruction in the first bank really has no effect at all (triggering that one calls the first bank, which we are already in)...while the JMP instruction in the second bank has no effect (the bank has already been left due to the BIT instruction just above it). The cold start init routine (JMP's destination) is actually only in the first bank.

 

It's just superfluous filler.

 

Another way is when the bankswitch argument itself is handled generically...where the target code that the program is after could be in either bank. There's a number of ways to approach this, but the easiest way is to use a register to handle it...

 

LDA $FFF8,Y

 

 

In short, it's common where an executed call to a hotspot will not have any effect to the program. A single generic call is more efficient (and less to keep track of during a program's development).

 

 

 

BTW I often use the format $xFF8 when describing ROM addresses, hotspots, etc...because it really doesn't matter to the console what the argument actually is (so long as the upper nybble of the MSB is an odd value - specific to all ROM).

 

 

 

 

Of course...if you are referring to DOS' file comparisons that list "addresses" of changes, $0FF8 (that's zero eff eff eight) will appear because DOS is only reporting the byte number in the file. So will $0FF9. It doesn't even look at where the code is ORG'ed to (specified by the reset vector, which DOS knows nothing about). So it's not so much of an address to DOS, it's an offset.

Edited October 18, 2008 by Nukey Shay

[Omegamatrix]

Interesting use of BIT. I believe that is the $2C opcode with a two byte argument, which you taught me Nukey. If I understand it correctly testing the address of the bankswitch will trigger it, but if you are in that bank already it will have a null effect. If the test is false it will jump over to the next instruction, which in this case is a JMP, lol. In the second bank the result is true for the BIT test so the bankswitch occurs via hardware and the JMP instruction is read in the first bank instead of the second? Perhaps not if cycles are passing during the switch. Depends on the program counter I guess, and if bankswitching moves it back a few cycles or not.

 

 

I love the use of LDA $FFF8,Y. I'm guessing that switch banks and look for the operand at the offset of Y? then it would continue in the other bank (or is it just bank one?) at the next address in the program counter?

[Omegamatrix]

God I was trying to hit the caps button and I tabbed over and hit enter and it posted, lol. Anyhow I also meant to say is I did understand what you meant by $xFF8, Nukey. The "x" is a don't care condition, as long as it is odd in the most significant byte (octet). You helped me with that too IIRC. So "x" can be values of 1,3,5,7,9,B,D,F and is also the value of the ORG for that bank. It should match the interupt vector in 4k game, but sometimes doesn't in a hack. Another quick way to identify the high octect is to look at the JSR and JMP instrucitons. ie if they are JSR $12E4 then the originate should be $1000. If it is JMP $F2E4 then the originate should be $F000, and so on. Really though as long as the high octect is odd, its good. The 2600 can't address more then xxxX XXXX XXXX XXXX 13 lines?

 

 

 

I'm still not certain if anything could be at $0FF8 in Quickstep though. Is it a "hotspot" then?

[Nukey Shay]

I'm still not certain if anything could be at $0FF8 in Quickstep though. Is it a "hotspot" then?

No, because it's not a bankswitched game. No hotspots to trigger. It could, however, hold a value that the program actually uses. The same is true for all non-bankswitched games all the way to the end of the file. This is why some 4k games work as-is with an unmodded Supercharger, while others do not.

 

A disassembly of Quick Step shows that a data table exists at $1FF1 (ORG is $1000). This table is read at only 1 point in the game...using Y as an index. So the program needs to be checked how far ahead the program actually reads.

 

When in doubt...disassemble:

 

It seems that the Y index is always a value between 0 and 4 (stored to ram $A9). Once it's incremented, it's immediately checked for a value of 5 (and reset to 2 if so).

 

;* = $1758
   INC	$A9	;5
   LDA	$A9	;3
   CMP	#$05   ;2
   BNE	L1764  ;2 ** branch if A is not 5
   LDA	#$02   ;2 reset A to 2
   STA	$A9	;3
L1764: LDY	#$00   ;2 reached by ** only
   STY	$95	;3
   TAY		   ;2 Y = 0 to 4
   CMP	#$03   ;2
   BCC	L1771  ;2 ***
   LDA	#$FF   ;2
   STA	$95	;3
L1771: LDA	L1AC1,Y;4 reached by *** only
   STA	$96	;3
   LDA	L1AC5,Y;4
   STA	$AA	;3
   LDA	L1FF1,Y;4 Y is still 0 to 4

 

So the last referenced addresses is a 5-byte table from $1FF1 to $1FF5 (anything beyond is not used by the code). Some garbage values follow, but value changes in $1FF6 to $1FFB do not matter to this game. Neither does $1FFE and $1FFF (because interrupts are not called).

 

Checking a running game in Stella (and hitting ~) confirms that $A9 is always less than 5.

 

 

And here I was making a "Supercharger-compatable" version of the NTSC game! Turns out, it already was.

 

Oops