Jump to content

Photo

2600 Rom Comparisions and Dumps


1225 replies to this topic

#1101 Tempest ONLINE  

Tempest

    Your Imperious Leader

  • 22,895 posts
  • Location:The Ethereal Plane of Atrii

Posted Tue Jul 26, 2011 9:26 AM

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

#1102 Thomas Jentzsch OFFLINE  

Thomas Jentzsch

    Thrust, Jammed, SWOOPS!, Boulder Dash

  • 18,829 posts
  • Always left from right here!
  • Location:Düsseldorf, Germany

Posted Tue Jul 26, 2011 10:21 AM

Busy with Boulder Dash... :)

#1103 Tempest ONLINE  

Tempest

    Your Imperious Leader

  • 22,895 posts
  • Location:The Ethereal Plane of Atrii

Posted Tue Jul 26, 2011 10:38 AM

Busy with Boulder Dash... :)

Well stop being busy and look at ROTLA! :D

Tempest

#1104 SeaGtGruff OFFLINE  

SeaGtGruff

    Quadrunner

  • 5,455 posts
  • Location:Georgia, USA

Posted Tue Jul 26, 2011 6:18 PM

Busy with Boulder Dash... :)

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

Michael

#1105 SeaGtGruff OFFLINE  

SeaGtGruff

    Quadrunner

  • 5,455 posts
  • Location:Georgia, USA

Posted Wed Jul 27, 2011 12:09 AM

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? :ponder:

Michael




#1106 Thomas Jentzsch OFFLINE  

Thomas Jentzsch

    Thrust, Jammed, SWOOPS!, Boulder Dash

  • 18,829 posts
  • Always left from right here!
  • Location:Düsseldorf, Germany

Posted Wed Jul 27, 2011 12:26 AM

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? :ponder:

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

Attached Files



#1107 Nukey Shay OFFLINE  

Nukey Shay

    Sheik Yerbouti

  • 21,061 posts
  • Location:The land of Gorch

Posted Wed Jul 27, 2011 6:58 AM

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 :)

Attached Files



#1108 Omegamatrix OFFLINE  

Omegamatrix

    Quadrunner

  • Topic Starter
  • 5,516 posts
  • Location:Canada

Posted Wed Jul 27, 2011 9:30 AM

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



Attached File  Raiders(re).zip   27.24KB   64 downloads

#1109 SeaGtGruff OFFLINE  

SeaGtGruff

    Quadrunner

  • 5,455 posts
  • Location:Georgia, USA

Posted Wed Jul 27, 2011 1:33 PM

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




#1110 SeaGtGruff OFFLINE  

SeaGtGruff

    Quadrunner

  • 5,455 posts
  • Location:Georgia, USA

Posted Thu Jul 28, 2011 1:09 AM

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




#1111 stephena OFFLINE  

stephena

    River Patroller

  • 2,524 posts
  • Stella maintainer
  • Location:Newfoundland, Canada

Posted Thu Jul 28, 2011 7:58 AM

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.

#1112 Nukey Shay OFFLINE  

Nukey Shay

    Sheik Yerbouti

  • 21,061 posts
  • Location:The land of Gorch

Posted Thu Jul 28, 2011 8:14 AM

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.

#1113 stephena OFFLINE  

stephena

    River Patroller

  • 2,524 posts
  • Stella maintainer
  • Location:Newfoundland, Canada

Posted Thu Jul 28, 2011 8:22 AM

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.

#1114 SeaGtGruff OFFLINE  

SeaGtGruff

    Quadrunner

  • 5,455 posts
  • Location:Georgia, USA

Posted Thu Jul 28, 2011 8:30 AM

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! :thumbsup:

Michael

#1115 stephena OFFLINE  

stephena

    River Patroller

  • 2,524 posts
  • Stella maintainer
  • Location:Newfoundland, Canada

Posted Thu Jul 28, 2011 8:51 AM


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! :thumbsup:

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.

#1116 Omegamatrix OFFLINE  

Omegamatrix

    Quadrunner

  • Topic Starter
  • 5,516 posts
  • Location:Canada

Posted Thu Jul 28, 2011 2:46 PM

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

#1117 stephena OFFLINE  

stephena

    River Patroller

  • 2,524 posts
  • Stella maintainer
  • Location:Newfoundland, Canada

Posted Thu Jul 28, 2011 6:52 PM

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

#1118 Nukey Shay OFFLINE  

Nukey Shay

    Sheik Yerbouti

  • 21,061 posts
  • Location:The land of Gorch

Posted Thu Jul 28, 2011 7:23 PM

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

#1119 SeaGtGruff OFFLINE  

SeaGtGruff

    Quadrunner

  • 5,455 posts
  • Location:Georgia, USA

Posted Fri Jul 29, 2011 3:34 AM

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! :thumbsup:

Michael

#1120 stephena OFFLINE  

stephena

    River Patroller

  • 2,524 posts
  • Stella maintainer
  • Location:Newfoundland, Canada

Posted Fri Jul 29, 2011 8:03 AM

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.

#1121 thegoldenband OFFLINE  

thegoldenband

    River Patroller

  • 3,965 posts
  • Location:Long Island, NY

Posted Tue Aug 2, 2011 8:28 PM

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 by thegoldenband, Tue Aug 2, 2011 8:29 PM.


#1122 thegoldenband OFFLINE  

thegoldenband

    River Patroller

  • 3,965 posts
  • Location:Long Island, NY

Posted Tue Aug 2, 2011 9:31 PM

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


#1123 Rom Hunter OFFLINE  

Rom Hunter

    VCS Games Archivist

  • 8,151 posts
  • Obtainer of Rare Antiquities

Posted Wed Aug 3, 2011 4:13 AM

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

8)

#1124 Rom Hunter OFFLINE  

Rom Hunter

    VCS Games Archivist

  • 8,151 posts
  • Obtainer of Rare Antiquities

Posted Wed Aug 3, 2011 6:13 AM

#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?

8)

#1125 thegoldenband OFFLINE  

thegoldenband

    River Patroller

  • 3,965 posts
  • Location:Long Island, NY

Posted Wed Aug 3, 2011 11:30 AM

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 by thegoldenband, Wed Aug 3, 2011 11:32 AM.





0 user(s) are browsing this forum

0 members, 0 guests, 0 anonymous users