Jump to content
IGNORED

2600 Rom Comparisions and Dumps


Omegamatrix

Recommended Posts

Yes, comparisons between [!] and [a] NTSC versions.

 

Super Breakout:

 

It looks like the significant change happens in "Double" and "Cavity" games. A routine that handles the additional on-screen balls is missing a comparison+branch in the [a] version (throwing the rest of the game off by a few bytes). This happens here:

LF687: CMP	#$25  ;2
   BCC	LF69C ;2
   CMP	#$33  ;2 missing in alternate
   BEQ	LF69C ;2 missing in alternate

 

It appears that this was added to the game (rather than subtracted from [a]). I would guess that [a] is an earlier version that did not have this contingency. Perhaps an expert could shed more light upon this?

Edited by Nukey Shay
Link to comment
Share on other sites

Let me get this straight, before I throw away the wrong ROMs.

 

These [a]lternate versions can be removed, right?

 

I didn't check Yar's Revenge and International Soccer yet.

 

 

But that is correct...if my suspicions are correct. I dunno if actual cartridges exist of these differences. In any case (except where noted), the altered bytes make no impact on gameplay.

Link to comment
Share on other sites

Yars' Revenge:

 

The shield changes color at higher levels. The color values for the shield are $32 (red), $06 (grey), $74 (blue), and $58 (purple/pink), loaded from $FFF3. The last value in [a] is $01 instead. Because bit7 makes no difference in the 2600's palette, this translates to BLACK! That would make for a pretty difficult game, because you would not be able to see the shield! There are 3 more bytes changed at $FFF7-$FFF9, but these are never read by either version (the index reading from the table is only allowed a range of 4 bytes).

 

;[!] version
LFFF3: .byte $32,$06,$74,$58,$00,$00,$00

;[a] version
;LFFF3: .byte $32,$06,$74,$01,$8B,$46,$F2

 

 

Bad dump? The manual says nothing about an invisible shield...and there's still no reason at all [a] should have 3 more garbage values.

Link to comment
Share on other sites

I think it's fair to say that it's a bad dump.

 

I've never heard or read anything about these "glitches" in the official released version.

 

But perhaps Omega can check out any differences between the Picture label and the Canadian text label?

 

8)

I dumped the Canadian text label and it is the everyday normal No Escape! which makes sense as the multi-language carts came later on. I wouldn't expect it to be a broken version.

 

 

@ Nukey

 

I also took a look at the PAL [a] of No Escape! and it doesn't look good:

 

L1941:
LDX	#1		   ; 2
STX	CTRLPF	   ; 3
DEX				 ; 2
STX	NUSIZ1	   ; 3
JSR	L1E0E		; 6
INX				 ; 2
JSR	L1E0E		; 6
LDX	#0		   ; 2
JSR	L1E77		; 6
LDX	#1		   ; 2
JSR	L1E77		; 6
DEC	$BD		  ; 5
;===============================
 IF PAL_ALTERNATE
.byte $80;.NOOP	 ; 2   This PAL[a] version seems broken... The offset for the branch is still the
.byte $1C;.NOOP	 ; 4   same, but the BNE (1101 0000) has changed to illegal opcode (1000 0000)
 ELSE
BNE	L1979		; 2   The PAL, NTSC, and NTSC[a] versions all branch the same
 ENDIF
;===============================
LDA	$F0		  ; 3
AND	#$02		 ; 2
BEQ	L1979		; 2
INC	$B8		  ; 5
LDX	$B8		  ; 3
LDA	#$9F		 ; 2
STA	$BF,X		; 4
LDA	#9		   ; 2
STA	$BD		  ; 3
CPX	#5		   ; 2
BNE	L1979		; 2
LDA	$F0		  ; 3
EOR	#$02		 ; 2
STA	$F0		  ; 3
L1979:
LDA	VBLANK	   ; 3
AND	#$40		 ; 2
BNE	L1985		; 2
LDA	RSYNC		; 3
AND	#$40		 ; 2
BEQ	L1996		; 2

 

What do you think?

Edited by Omegamatrix
Link to comment
Share on other sites

Hormpipe, why did you pick out exactly these titles?

 

I was just going through the 4k games trying to pick out one of each (original releases) - these alternates tripped me up, just wondered if anyone knew about any bugged versions or anything. Some are already labeled as Fixed.

Link to comment
Share on other sites

Well, I got 154 [a]lternate ROMs in my (already cleaned up) collection.

 

If we're seriously going to check out every [a]lternate ROM for differences, then there's quite some work to do.

 

The result will be the cleanest VCS ROM set in the world of course.

 

My intention is to release my V4 Collection by the end of december.

 

I would be glad to keep track of all the findings if some of you decide to examine out the [a]lternates.

 

Let me know if it's a go.

 

8)

Edited by Rom Hunter
Link to comment
Share on other sites

What do you think?

 

That's great! Another example where the opcode only differs (the argument $1C is still identical). Sure looks like a bad dump.

 

Does anybody have cartridges of these things?? I'm wondering where the "!" comes from on some of the [a]'s (according to GoodTools)...the exclaimation symbol is supposed to only be used for verified dumps.

 

If cartridges do exist, then they really belong in the set. 's and [o]'s never did.

Link to comment
Share on other sites

@ Rom:

It might speed up the process if I know what results you are looking for. If it's simple byte value errors (as shown above), it takes no time at all. Just do a DOS binary compare (fc /b file1 file2). Analyzing what exactly is affected by the change takes more time...ranging from very little (in the case of a differing value in a bitmap, or at the end of the rom where it usually makes no difference to the console)...to very long (in the case of differing opcodes in the program itself). The latter makes disassembly almost mandatory. It's a good thing that Stella provides breakpoint support...so they can be set on the locations specified by the compare.

 

BTW disassemblies already exist for some of them. Games like River Raid, where the [!] file has been fully commented by wizards like Thomas, should be a piece of cake to analyze the effect of a change. Regarding that game in particular, there's a plethora of alternate versions tho. Damn pirates. There could have been cases where a game was dumped badly back-in-the-day, and burned to a cart by a pirate company or individual. Such a case would be questionable whether or not they belong in the set.

Edited by Nukey Shay
Link to comment
Share on other sites

I'm wondering where the "!" comes from on some of the [a]'s (according to GoodTools)...the exclaimation symbol is supposed to only be used for verified dumps.

Tell me about it.

 

I stopped taking notice of those [!] ages ago.

 

 

Nukey,

 

I'm not sure what to look for.

 

I don't have the knowledge to see which ROM is actually good or bad if the differences are so small and I'm afraid to throw away any ROMs that were in fact released on cart in history.

 

8)

Link to comment
Share on other sites

That was what I was getting at. How do we find out whether a cartridge actually exists with the incorrect values? It's easy for me to waggle my finger and say "it looks like a bad dump"...but even bad dumps could have been burned to an eprom. Difficult to know where to draw the line on alternates.

 

IMO all of the pirates should have been eliminated from the set when GoodTools was first made. A good share of them are broken/glitchy anyway. But this is the internet...where bad files are archived basically forever :(

Link to comment
Share on other sites

I can try to help find out what the effects that the differing bytes cause (if any). Beyond that, it's your call. Good2600 will report that you are missing roms when you eliminate any of them.

 

IMO Tempest has the right idea. Kill off all of them and just keep the most valid entry (singular) for each game title. Eliminate game titles completely if they are alternate names of a game. That would give you a complete romset as far as functionality goes. Otherwise, you are pretty much stuck with everything (since any one of the alternates could exist on a pirate cart - besides ones that you personally know are not). I'm not in charge of "officially" updating [a]'s to 's...and it would be impossible to track down everyone responsible for dumping either of them (so it's impossible to know what chip they dumped...not to mention where the chips in question came from).

 

At least the majority of 2600 roms are 4k/2k, so you are talking about a small amount of HD space either way.

Link to comment
Share on other sites

Well, I could post the first ten (of 154) [a]lternate ROMs here for examination.

 

The ones that are as good as certain to be bad ROMs will be removed from my collection and will be put in a seperate map.

 

If any of them turn out to be identical to an existing cart dump, I can always put these back in.

 

What do you think?

 

8)

Edited by Rom Hunter
Link to comment
Share on other sites

Identical as far as bytes that don't matter to the program (i.e. unused or garbage areas)? That would eliminate them as being alternate versions in the true sense of the definition. I think that you'll find that differences in base ORG's, interrupt vectors, and bankswitch hotspot addresses will show up frequently. None of those make no difference to you (as the player) or the console (which rarely implements them...if at all).

 

There's still no way to correctly classify [a]'s where the altered bytes DO matter one way or another, but it's a start. If a quick 1:1 file compare shows massive differences (usually due to dropped or added instructions), it's safe to assume that it really is an alternate version.

Link to comment
Share on other sites

Well...

2 Pak Special Black - Challenge, Surfing [a] has the 2 bytes in the NMI vector ($xFFA-B) changed in the first and third banks...which doesn't matter either way (the NMI vector space is inaccessible in bankswitched carts). Could be a bad dump.

 

2 Pak Special Dark Blue - Wall Defender, Planet Patrol has garbage code existing on the bankswitch hotspots ($xFF6-9)...which doesn't matter either way. [a] has this space zeroed.

 

2 Pak Special Light Green - Hoppy, Alien Force[a] has the 2 bytes in the NMI vector changed for every bank except the first. Could be a bad dump.

 

2 Pak Special Red - Motocross, Boom Bang has garbage code existing on the bankswitch hotspots ($xFF6-9). [a] has this space zeroed.

 

2 Pak Special Yellow - Star Warrior, Frogger [a1] has the 2 bytes in the NMI vector changed for every bank. Could be a bad dump.

 

2 Pak Special Yellow - Star Warrior, Frogger [a2] does not have the garbage code present in the others.

 

Alpha Beam with Ernie [a] has values differing on the bankswitch hotspots. Could be a bad dump.

 

Artillery Duel-PAL [a] has values differing on the bankswitch hotspots. Could be a bad dump.

 

Artillery Duel-NTSC [a] has values differing on the bankswitch hotspots. Could be a bad dump.

 

Asterix [a] has values differing on the bankswitch hotspots. Could be a bad dump.

Edited by Nukey Shay
Link to comment
Share on other sites

The differing value in Action Man [a] doesn't matter. $xDF1 is never loaded by the program as far as I can tell. A 16-byte table exists just before it at $xDE1-F0 (which is indexed and cannot be a range of more than 16 bytes)...the rest of that page (zeroes except for the differing byte) appear to be unused.

Link to comment
Share on other sites

Note regarding the garbage code in some of the games above:

 

Perhaps this was an early form of game selection...a JMP existing on the hotspots (until they realized that this method is unstable)? In any case, the code is unused in all of them.

 

Verdict:

Garbage code differences = true alternate games (even tho the code is unused).

All others = bad dump 99.9% probable.

Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...
  • Recently Browsing   0 members

    • No registered users viewing this page.
×
×
  • Create New...