2600 Rom Comparisions and Dumps

[Tempest]

Nothing new on the ROTLA proto? I'm dying to hear what's hidden in it. I haven't had the time to play around with it, but I'm guessing that all the interesting stuff is going to be hidden in the code anyway.

 

Tempest

[Thomas Jentzsch]

Busy with Boulder Dash...

[Tempest]

Busy with Boulder Dash...

Well stop being busy and look at ROTLA!

 

Tempest

[SeaGtGruff]

Busy with Boulder Dash...

Wait-- wasn't that a scene in ROTLA?

 

Michael

[SeaGtGruff]

I didn't even know that a prototype of Raiders had been posted until tonight-- well, technically it was yesterday evening, since it's already this morning. Anyway, I'm disassembling it with DIS6502, and already have most of the code disassembled. Question: Is there a good disassembly of Raiders that I can compare it to, or will I need to disassemble the released version as well?

 

Michael

 

 

 

[Thomas Jentzsch]

Question: Is there a good disassembly of Raiders that I can compare it to, or will I need to disassemble the released version as well?

That's the best I can offer. Don't expect much.

rotla.zip

[Nukey Shay]

I had some additional vectors labelled (but not as many descriptions). Interest sort of fell away when there was nothing found to trigger the hidden key gfx. Combining both files should be a good starting place if you wanted to make a reverse-engineered code. You know the drill...label what you know, make small changes (in a debugger) and test to discover things you don't. Repeat hundreds of times

Raiders.zip

[Omegamatrix]

Here's what I did before I got too busy. It should be easier to manipulate the ram with this disassembly.

 

 

 

Raiders(re).zip

[SeaGtGruff]

Thanks, guys! This will make it easier to compare them. I'll post my disassembly of the prototype when I'm done. I may even post another disassembly of the released version, because I'm hoping to replace many of the code labels with meaningful routine names.

 

Michael

 

 

 

[SeaGtGruff]

I've decided I'm not going to touch (much) the assembly for Raiders until I finish disassembling the prototype-- which is more work than I thought it would be. The initial disassembly was easy, but then there's the routines that get called from RAM code using jump tables, not to mention figuring out what each RAM location is used for and what meaningful names to give the routines (as opposed to LF789 or whatever). And I'm formatting the listing according to my own stylistic preferences to make it easier to read, such as putting labels on lines by themselves and adding blank lines to separate instructions, plus adding cycle counts. (I didn't use distella, which adds cycle counts automatically, so I'm having to add them manually.) Anyway, once I finish the disassembly of the prototype, I'll create a similar disassembly for the released version.

 

[Mario]It's-a lotta fun![/Mario]

 

Michael

 

 

 

[+stephena]

I've decided I'm not going to touch (much) the assembly for Raiders until I finish disassembling the prototype-- which is more work than I thought it would be. The initial disassembly was easy, but then there's the routines that get called from RAM code using jump tables, not to mention figuring out what each RAM location is used for and what meaningful names to give the routines (as opposed to LF789 or whatever). And I'm formatting the listing according to my own stylistic preferences to make it easier to read, such as putting labels on lines by themselves and adding blank lines to separate instructions, plus adding cycle counts. (I didn't use distella, which adds cycle counts automatically, so I'm having to add them manually.) Anyway, once I finish the disassembly of the prototype, I'll create a similar disassembly for the released version.

 

[Mario]It's-a lotta fun![/Mario]

 

Michael

I don't know if anyone has realized this, but the debugger in Stella can generate a distella 'config' file that should help with creating a disassembly. You can view the data with 'listconfig', and load/save config files with 'loadconfig' and 'saveconfig'. The nice thing about this is that it's dynamic, so the longer you play a game, the more accurate the results become (as more code paths are revealed).

 

The config files generated by Stella are not directly usable in Distella, since they (a) use several newly defined config directives and (b) contain info for every bank (whereas Distella only operates on a single bank). However, the data should still be useful as a starting point, since it's being created by Distella behind the scenes.

[Nukey Shay]

Rip tip. However, that is the easy step (it usually only takes less than half an hour to do it by hand...unless the program is -really- convoluted using pseudo-jumps everywhere). The next step is much more difficult - decypering/commenting indirect vectors used for gfx and such. But it's true that using Stella's debugger can be a big help there, too.

[+stephena]

The next step is much more difficult - decypering/commenting indirect vectors used for gfx and such. But it's true that using Stella's debugger can be a big help there, too.

Yep, and that's why the dynamic approach is superior in that case. Stella marks something as GFX (or PGFX for playfield graphics) if it's ever been stored in the appropriate registers, regardless of how the code put it there (whether by direct or indirect means). Of course, as you say, there's still some work in resolving which lines of code did that exactly. I think this is an area where Stella can be improved, since in theory it knows about all this anyway. It is in fact the basis of the 'Source Address' functionality in the debugger.

[SeaGtGruff]

I don't know if anyone has realized this, but the debugger in Stella can generate a distella 'config' file that should help with creating a disassembly. You can view the data with 'listconfig', and load/save config files with 'loadconfig' and 'saveconfig'. The nice thing about this is that it's dynamic, so the longer you play a game, the more accurate the results become (as more code paths are revealed).

 

The config files generated by Stella are not directly usable in Distella, since they (a) use several newly defined config directives and (b) contain info for every bank (whereas Distella only operates on a single bank). However, the data should still be useful as a starting point, since it's being created by Distella behind the scenes.

Thanks for the tip, Stephen! By the way, I'm not using distella to generate the initial disassembly-- I'm using DIS6502, because it lets you load multiple banks at once (you don't even have to split the file first), and it lets you dynamically flag sections of memory as code or data, as well as dynamically add or change equate labels. So the fact that the "config" will contain information for both banks is actually a good thing!

 

Michael

[+stephena]

I don't know if anyone has realized this, but the debugger in Stella can generate a distella 'config' file that should help with creating a disassembly. You can view the data with 'listconfig', and load/save config files with 'loadconfig' and 'saveconfig'. The nice thing about this is that it's dynamic, so the longer you play a game, the more accurate the results become (as more code paths are revealed).

 

The config files generated by Stella are not directly usable in Distella, since they (a) use several newly defined config directives and (b) contain info for every bank (whereas Distella only operates on a single bank). However, the data should still be useful as a starting point, since it's being created by Distella behind the scenes.

Thanks for the tip, Stephen! By the way, I'm not using distella to generate the initial disassembly-- I'm using DIS6502, because it lets you load multiple banks at once (you don't even have to split the file first), and it lets you dynamically flag sections of memory as code or data, as well as dynamically add or change equate labels. So the fact that the "config" will contain information for both banks is actually a good thing!

 

Michael

I should also add that this is probably a relatively unknown and untested feature. It works perfectly for me with single-bank ROMs, messes up somewhat on some multi-bank ROMs, and is probably totally broken on the more esoteric types like 4A50, etc (where the definition of a 'bank' is ambiguous). But in the general cases where 1 bank is defined as 4KB, it seems to work very well.

[Omegamatrix]

I love how Stella marks GFX and separates it from data, and playfield GFX. I did notice it will miss marking a case like this:

 

 

LDA (scoreGfxOne),Y

TAX

STX GPR0 ; or GRP1

 

But this works fine:

 

LDA (scoreGfxOne),Y

STA GPR0 ; or GRP1

[+stephena]

I love how Stella marks GFX and separates it from data, and playfield GFX. I did notice it will miss marking a case like this:

 

 

LDA (scoreGfxOne),Y

TAX

STX GPR0 ; or GRP1

 

But this works fine:

 

LDA (scoreGfxOne),Y

STA GPR0 ; or GRP1

I'm pretty sure that's because it's keeping track of addresses for LDx, but not for TAx. Obviously this should be fixed. Providing a test ROM that illustrates this would be beneficial ...

[Nukey Shay]

Multi-sprite display routines also involve the stack pointer occasionally (LDA -> TAX -> TXS), so that only 2 cycles are needed when flipping it back to X later instead of using a 3-cycle read. IIRC Ebivision's Pesco used this method when drawing it's score.

 

On the subject of 3-cycle reads...it might be difficult for the debugger to automatically track if it's happening much earlier than the actual display routine (as many early Atari games did by moving sprite or playfield info to temp ram). Even Combat does this with it's "shape buffer".

[SeaGtGruff]

Multi-sprite display routines also involve the stack pointer occasionally (LDA -> TAX -> TXS), so that only 2 cycles are needed when flipping it back to X later instead of using a 3-cycle read. IIRC Ebivision's Pesco used this method when drawing it's score.

Hmm, that's a very useful trick, as long as you restore the stack pointer afterward. I'll definitely be keeping this trick in mind!

 

Michael

[+stephena]

Multi-sprite display routines also involve the stack pointer occasionally (LDA -> TAX -> TXS), so that only 2 cycles are needed when flipping it back to X later instead of using a 3-cycle read. IIRC Ebivision's Pesco used this method when drawing it's score.

 

On the subject of 3-cycle reads...it might be difficult for the debugger to automatically track if it's happening much earlier than the actual display routine (as many early Atari games did by moving sprite or playfield info to temp ram). Even Combat does this with it's "shape buffer".

Yes, this is on my (never ending) TODO list. The current version of address tracking is quite simplistic, and only considers one level of indirection (and not even all those cases, as you see by the TAX example above). It needs to be expanded to cover all 1-level cases, but also where other registers (and temp RAM) are used as intermediaries.

[+thegoldenband]

Cross-posting from the Scans For Rom thread, I picked up a couple things that might be relevant to this thread's mission:

 

#1 - a loose Pete Rose Baseball (2600), which is apparently PAL. The screen rolls, the grass is pink, and the label is a full-color picture with a green end label. Is this the HES version? It doesn't say "HES" anywhere on the game, only Absolute, but that's also what the cart label scan on Atarimania has.

 

#2 - the two SuperVision 8-in-1 multicarts pictured here, which at first glance don't appear to be in the Atarimania database. The contents of the one on the right are as follows, and are all PAL:

 

2 River Raid                  6 Superman
1 Kangaroo I (Quick Step)     5 Star Master

3 Pirate (Save Our Ship)      7 Z-Tack (Mission 3,000 A.D.)
4 Sky Diver (Parachute)       8 Wizard of Wor

I haven't completely checked the other cart yet, but the interesting thing is that some of the games are NTSC, including Gorf, Soccer (I believe this was International Soccer), Video Pinball, and Carnival. I think there was one more too, IIRC. All of them appeared to be the NTSC versions -- they didn't roll, and the colors looked right. I'll do a full inventory of that cart later tonight.

Edited August 3, 2011 by thegoldenband

[+thegoldenband]

OK, here's what's on the other cart:

 

2 Soccer (Championship Soccer)*      6 Flash Gordon
5 Missle 3000 (Mission 3,000 A.D.)   1 Five Eagle (Tac-Scan)

3 Carnival*                          7 Screaming (Earth Dies Screaming)*
8 Gorl (Gorf)*                       4 Super Pinball (Video Pinball)*

* = screen doesn't roll and colors appear normal

[Rom Hunter]

#1 - a loose Pete Rose Baseball (2600), which is apparently PAL. The screen rolls, the grass is pink, and the label is a full-color picture with a green end label. Is this the HES version? It doesn't say "HES" anywhere on the game, only Absolute, but that's also what the cart label scan on Atarimania has.

HES indeed.

 

[Rom Hunter]

#2 - the two SuperVision 8-in-1 multicarts pictured here, which at first glance don't appear to be in the Atarimania database.

They do now.

 

BTW: what are the SA serial numbers on the front labels?

 

[+thegoldenband]

BTW: what are the SA serial numbers on the front labels?

River Raid/Kangaroo I/etc.: SA 1638

 

Soccer/Missle 3000/etc.: SA 1656

 

Have these been dumped? Do these SuperVision multicarts normally have anything dump-worthy on them? Interesting that the one cart is 5/8 NTSC.

 

Also, did my Pete Rose likely originate in Europe, or Australia? (Was the same version sold in both regions?)

Edited August 3, 2011 by thegoldenband