Jump to content
IGNORED

2600 Rom Comparisions and Dumps


Omegamatrix

Recommended Posts

Thanks to Omegamatrix's help, I've updated several bad or missing NTSC ROMs in the database. I've also added two missing Zeller's entries (Scuba Diver and Sea Hawk), although I don't have cartridge scans for them. Also updated many of the Zeller's screenshots, which were incorrect (many of the Zeller's binaries were modified to remove the original company's name, for instance). Here's a list of the entries I updated:

 

Sir Lancelot		  Bad Dump
Congo Bongo		   Bad Dump
Great Escape		  Wrong
King Kong			 Wrong (PAL version)
Espial				Wrong (PAL version)
Miner 2049er Vol. II  Wrong (PAL version)

ZELLERS:
Busy Police		   Wrong
Challenge			 Wrong
Circus				Wrong
Earth Attack		  Wrong
Farmer Dan			Wrong
Freeway			   Wrong
Inca Gold			 Wrong, and wrong screenshots too
Laser Volley		  Wrong
Ocean City Defender   Wrong
Scuba Diver		   No Dump, and needs to be moved into the Zellers section
Sea Hawk			  No Dump, and needs to be moved into the Zellers section
Space Adventure	   Wrong
Time Warp			 Wrong
Turmoil			   Wrong

I'm sure there are plenty of other entries that are incorrect or missing in some aspect. I'd like to fix any issues with the NTSC side of the database--this includes entries missing outright and incorrect or missing ROMs. Please use the Tracker to add new issues, as this makes it easy to keep track of changes:

 

http://www.atariage.com/forums/index.php?a...p;showproject=6

 

Thanks!

 

..Al

Link to comment
Share on other sites

  • 3 weeks later...

I have three different versions of Atari Space Invaders (PAL) and I managed to dump them running the software posted by batari in this thread on my VCS. The 3 variations differs for speed and color palette:

 

1) text label version:

The rom is the same named "Space Invaders (Unknown) (PAL)" in rom's collection. This version is slower than the other two.

post-10599-1221869745_thumb.pngpost-10599-1221869828_thumb.jpg

 

2) picture label 1

This is the "darker" version (see this thread). Player 1 and the mothership use really dark colors and are difficult to see on the TV screen. This is faster than the previous version. The cart has a "41 2 R" code stamped on the end label which should indicate the production date (41th week of 1982).

post-10599-1221869757_thumb.pngpost-10599-1221869839_thumb.jpg

 

3) picture label 2

This version shows brigther colors while keeping the speed of the darker version. "12 3 R" code on end label. This is the PAL space invaders rom on rom's collection.

post-10599-1221869772_thumb.pngpost-10599-1221869853_thumb.jpg

 

These variations all use the same B&W palette (selected using the TV TYPE switch), therefore they will look the same on a Secam console.

space_invaders_PAL.zip

Link to comment
Share on other sites

It appears to be fairly obvious (without disassembly) what the story is. The initial PAL release (file 1) didn't have timing adjusted for 50hz, and there were issues with the colors as well. The revision (file 2) corrects the timing, but the colors were too dark. File 3 replaces it.

 

Clonespy reflects this hypothesis.

Link to comment
Share on other sites

I've integrated version 2 & version 3 so far. Version three has a branch after the BIT instruction at $FB44 which looks more right to me then version's two lack of branch. The extra two bytes are balanced by taking two bytes out of the string of $00 before $FC page. Then the only difference is a small table which I'm presuming is colors (haven't checked.

 

SpIn_PAL_v2_v3.zip

Edited by Omegamatrix
Link to comment
Share on other sites

The table is the colors chosen. They are in this order:

Shield, UFO, Player 1, Player 2, Invaders, Missiles, Sky color, Ground color.

 

The branching instruction swaps joystick control (so co-op game selections that involve alternately switching control from one stick to another will not work correctly with ver.2). All other versions share the original unaltered code for this routine.

Link to comment
Share on other sites

Version 1 to version 2 sees a lot of changes in the code. I can't do anymore tonight and probably won't over the next week (not enough time with school). Nukey to be clear you are saying version 2 is disfunctional, and version 3 is good? Version three shares the unaltered code with all the other versions except 2?

Link to comment
Share on other sites

BTW the game option affected is the two-player partnership game with alternating firing and control of the cannon (game selections 81-96, mentioned on page 11 of the manual). The way it's supposed to work is that the left player has total control of the cannon for odd shots (starting with the first one), the right player has total control for even shots. In ver.2, the branch to use the left stick is missing...so the right player always moves the cannon (the players still alternate shots, tho).

Link to comment
Share on other sites

BTW:

 

All three different PAL versions can be seen in non-US Space Invaders commercials on this page:

http://atarimania.com/detail_soft.php?VERS...8353&MENU=2

 

- Video 14 (version 2)

- Video 16 (version 3)

- Video 27 (version 1)

 

Never noticed this before.

 

8)

Edited by Rom Hunter
Link to comment
Share on other sites

Regarding this aspect, yes. Of the three PAL versions you posted, ver.1 shares the most identical code & data with the NTSC version. The missing branch in ver.2 is the only difference between all of them for the input routine.

 

 

Clonespy results (si0=NTSC):

 

 

It all makes sense then and corresponds with the date stamps that Alex_79 posted.

 

Version1 (original)

- belongs to the text label, first conversion by Atari

- seems rushed as the speed is not corrected

 

Version2 (alternate 1)

- picture label, date stamped 41 2 R (41st week of 1982)

- corrected speed, changed some colors

- took out swapping controllers branch and caused a glitch

 

Version3 (alternate 2)

- picture label date stamped 12 3 R (12th week of 1983)

- corrected glitch from version 2

- changed some colors again

 

 

 

I'm not going to disassemble the first version now as the pattern of change seems obvious. I'm really glad Alex posted those scans and date stamps. Really helps to know what rom belongs to what cart. :)

Edited by Omegamatrix
Link to comment
Share on other sites

I'm not going to disassemble the first version now as the pattern of change seems obvious.
Actually, there's something interesting in the first PAL version. Just above the shield display, 3 NOP instructions were added as placeholders at $F109. I wonder if a JSR was planned on being inserted there to handle something that the original game didn't (like partially-erased shields)?

 

Anyway, quite a number of routines have been moved around between ver.1 and 2...so trying to link them into your 2+3 disassembly would be messy.

Link to comment
Share on other sites

Anyway, quite a number of routines have been moved around between ver.1 and 2...so trying to link them into your 2+3 disassembly would be messy.

You're right. I gave up as it was becoming too incoherent. It should be easier to integrate the NTSC and PAL version 1, but I don't have time and it looks like you've done a comparision already. ;)

 

I'm not even sure how to make an assembly with lots of shifting of routines. Maybe something like SEG.U SOME_ROUTINE?

 

; the address at this point is $F0FF
 SEG.U   SOME_ROUTINE
 IF PAL
 ORG   $FC00
 ELSE
 ORG   $F100	; NTSC version
 ENDIF
 .byte   data here
 .byte   data here
 .byte   data here
 SEG	code

I'm not sure if that would work. Would DASM automatically fill the the space from $F0FF to $FBFF with bytes of $FF for the PAL version (and make the rom larger then 4k)? Would you have to something with ORG and RORG?

 

Partially erased shields would have been cool. Are there any flashing shields when they take too much damage?

Link to comment
Share on other sites

Overthinking the problem. It's far easier to define macros for identical routines that shift in memory between versions...then just call them between lines of code that is more consistant. It's still messy, but far more readable.

 

 

Are there any flashing shields when they take too much damage?
I dunno what you mean by this. There's no version of SI that checks on the current condition of a shield. It's just mapped in RAM, and deteriorates as the ball sprite (missile) collides. The arcade game includes collisions with the invaders themselves.

 

 

Erasing the shields is just a theory that has no supporting evidence (other than placeholder NOPs where the aspect could be added). It could be relatively easy to pull off tho...because the loop that displays them can begin at any offset (the Y index register is hard-coded to begin at zero). The only problem in the existing kernal is that there would be a few scanlines' difference between the bottom of the invaders and the displayed portion of the shields...so it wouldn't look much like they are erasing them as in the arcade game.

Link to comment
Share on other sites

  • 3 weeks later...

Poking around at some 4k alternate versions.

 

* There are two versions of Apollo's Lost Luggage.

The [a] version is Lost Luggage with Intro - this is the Blue Label as described on AtariMania. http://www.atarimania.com/detail_soft.php?...VERSION_ID=8133

The standard Lost Luggage is the Original - fewer points, fire button restart, no intro. I guess this came first. I don't know much about Apollo label variations.

 

* Mr. Postman - O Cartiero (1983) (CCE) (C-801) [a] - has extra lines in front of your score, as though the height counter was one too large.

Mr. Postman - O Cartiero (1983) (CCE) (C-801) does not have this problem and looks right

 

* No Escape [a] - has some problems when trying to fire towards the right, and often the left as well. What was the source for this broken image?

No Escape works fine.

 

* Spinning Fireball - has copyright notice

Spinning Fireball [a] - copyright notice has been removed. And there is another change too, but I can't tell what it does.

 

 

 

Can anyone help me figure out what the differences are in the original vs alternate releases of...

Bridge

Championship Soccer

Crackpots

Enduro

Gas Hog [this one has different colors!]

Halloween

International Soccer

Racquetball

River Raid

Super Breakout

Yar's Revenge

Link to comment
Share on other sites

The original bridge has a bad branch by mistake (It jumps in between an instruction and the operand). The alternate corrects this mistake and has a different value at $FEFF. I haven't investigated this yet. Presumably the alternate is the fixed version as jumping between the instruction and operand could cause the game to crash.

 

 

I remember Homer dumped the new Gas Hog a while back. It has the correct colors and a stable scan line count.

Link to comment
Share on other sites

* No Escape [a] - has some problems when trying to fire towards the right, and often the left as well. What was the source for this broken image?

No Escape works fine.

 

If nobody has a cartridge program that matches [a], it's a bad dump. Otherwise, it would be the earliest 2600 program that contains an illegal instruction.

 

No Escape @ $1800: STX WSYNC

No Escape [a] @ $1800: NOP VSYNC (a 3 cycle NOP).

 

Interestingly...this "error" fixes the added scanline when Pegasus appears at the end of the game (bumping to 263 scanlines). The effect in [a] just delays coloring the ground area (look on the left...the first line will be off-color).

 

 

The shooting problem happens later. A branching instruction opcode is changed to a store. The argument ($04), however, does NOT differ...adding weight to the "bad dump" theory.

 

No Escape @ $1C00: BCS $1C06

No Escape [a] @ $1C00: STX NUSIZ0

 

The only other byte that differs is part of an animation frame, and has no effect on the function of the game.

No Escape @ $1001: .byte %00100100

No Escape [a] @ $1001: .byte %00100000

 

You'll see this missing pixel on the first enemy. One leg will have a gap before the foot.

Edited by Nukey Shay
Link to comment
Share on other sites

Championship Soccer, Crackpots and Enduro:

 

The only difference is the very last byte in the rom (the MSB of the interrupt vector). Since interrupts are not used in these games, this makes no difference. Could be bad dumps in any case.

Edited by Nukey Shay
Link to comment
Share on other sites

Racquetball:

5 values are changed.

($72F2) cmp	#$0F   ;2 $07 in alternate

L772A: .byte $14; |   X X  | $772A $10 in alternate
   .byte $10; |   X	| $772B $0F in alternate
L772C: .byte $03; |	  XX| $772C $07 in alternate
   .byte $07; |	 XXX| $772D $08 in alternate

 

[a] might have been an earlier version, because serves have a tendancy to go straight up. [!] provides better angles.

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...