Zaxxon - alternative rom with wF8 bankswitch format

[RevEng]

As discussed in the "Smurf Rescue - alternative rom with wF8 bankswitch format" thread, Coleco seems to have changed the bankswitch format the game used at some point for Smurfs. It also appears to be true for their Zaxxon cart too...

 

Zaxxon - wF8 bankswitching.bin

 

Special thanks to @JetmanUK and @raz0red for their collaboration in getting the rom dumped!

 

There are 601 bytes that differ between the common Zaxxon dump and this one. I believe a lot of that is just due to shifting of rom due to minor changes and re-assembly, but nobody has done a real analysis yet, so it's possible there are game play differences.

[Dionoid]

It’s amazing to learn that a new bankswitching format is found this long after the ‘2600 hay days.

I wonder for what reason Coleco changed this. Cost savings?

Edited May 28 by Dionoid

[Thomas Jentzsch]

And I wondered if all of Coleco's F8 games have such variants:

• Berenstain Bears (2658)
• Donkey Kong Jr. (2653)           
• Front Line (2665)  
• Looping (2654)
• Mr. Do! (2656)   
• Roc 'N Rope (2667)             
• Smurfs: Rescue in Gargamel's Castle (2465)
• Smurfs Save the Day (2511) (see below) 
• Tarzan (2662)
• Time Pilot (2663)
• Turbo (2445)
• Zaxxon (2454)

I checked Smurfs Save the Day and it either got hacked (after dumping) to F8 or has remains of WF8 code:

Berenstain Bears also has such code:

Zaxxon (PAL) looks similar too:

And this is from sizes.txt from @kevtris:

Quote

*addendum5*
Finally figured out what was wrong with Smurfs Save the Day.  The places
in the code that switch banks was right on top of each other.  (the 
STA $1FFx instructions were at the same addresses in diffrent banks)
As a result, there were only STA $1FF8 instructions rather than both
STA $1FF8 and STA $1FF9 instructions.  Fixing these resulted in a working
ROM image!!!!!!  Now all I need is Berinstein Bears to round out the
Coleco Collection.

Maybe @kevtris does remember? 

 

In general, the Coleco F8 bankswitching code looks odd. There are lot of padding NOPs around. Maybe the code was prepared for multiple bankswitching options? Maybe many of the dumps we know were hacked to F8? Interesting for sure...

 

Edited May 31 by Thomas Jentzsch

[JetSetIlly]

51 minutes ago, Thomas Jentzsch said:

In general, the Coleco F8 bankswitching code looks odd. There are lot of padding NOPs around. Maybe the code was prepared for multiple bankswitching options? Maybe many of the dumps we know were hacked to F8? Interesting for sure...

That's an interesting thought.

 

Question: Did anybody have success loading Smurfs or Zaxxon on the 2600+ before wF8 support was added to the dumper? Is there a legitimate F8 dump of Smurfs and Zaxxon that has been made recently?

[RevEng]

25 minutes ago, JetSetIlly said:

Question: Did anybody have success loading Smurfs or Zaxxon on the 2600+ before wF8 support was added to the dumper? Is there a legitimate F8 dump of Smurfs and Zaxxon that has been made recently?

Yes, there were always mixed reports for Smurfs and Zaxxon, so there has to be some real F8 carts for these.

[RevEng]

3 hours ago, Thomas Jentzsch said:

And I wondered if all of Coleco's F8 games have such variants:

• Donkey Kong Jr.            
• Front Line   
• Mr. Do!    
• Roc 'N Rope              
• Smurfs Save the Day (see below) 
• Time Pilot   

Yeah, I wondered that same thing. We might just be seeing WF8 variants for the most common titles likely to be owned by the sort of people who would buy the 2600+ and post on AA.

 

On your rom archeology... in the Smurf thread, Dennis pointed out a left-over byte that strongly suggests that WF8 was patched on top of F8. But Coleco may have had some reason to do the conversion the other way in other titles, and certainly from your comments it sounds like some dumps may have originally been WF8 and then converted to F8.

 

I agree the Coleco bankswitching code is weird. In the Smurf Rescue common dump, you have bankswitch hits for both banks, which looks weird. You can actually swap the bank order in that common rom, and it works just fine, which I believe is the reasoning behind that oddity. I think the runs of NOPs in the rom are there as a take-off and landing runway for very slow bankswitch logic. (possibly in their dev system)

 

8 hours ago, Dionoid said:

It’s amazing to learn that a new bankswitching format is found this long after the ‘2600 hay days.

I wonder for what reason Coleco changed this. Cost savings?

It's pretty wild. It also makes me wonder what other non-banking related game changes we're missing in other titles.

 

You're probably aware of the debug 2600+ firmware that reports the md5 sum of the game. Once the 2600+ work is mostly done, it would be good if we could get the community in on a search for 2600 and 7800 carts with unique md5 sums. The one wrinkle with that is returned data from hotspot reads isn't reliable with many bankswitch formats, but we can work around that.

[Thomas Jentzsch]

19 minutes ago, RevEng said:

I agree the Coleco bankswitching code is weird. In the Smurf Rescue common dump, you have bankswitch hits for both banks, which looks weird. You can actually swap the bank order in that common rom, and it works just fine, which I believe is the reasoning behind that oddity. 

Really? That's cool (I have to test). But why would anyone do that?

19 minutes ago, RevEng said:

I think the runs of NOPs in the rom are there as a take-off and landing runway for very slow bankswitch logic. (possibly in their dev system)

Makes sense. Though at other places there are less NOPs. Which fits to your slow switching development system theory.

19 minutes ago, RevEng said:

It's pretty wild. It also makes me wonder what other non-banking related game changes we're missing in other titles.

I am 100% sure there are. FC was another one which I identified not too long ago.

 

How many dumps have been verified? In the early days, the emulators were only to handle a few schemes. So it seems logical to patch the ROMs then.

19 minutes ago, RevEng said:

You're probably aware of the debug 2600+ firmware that reports the md5 sum of the game. Once the 2600+ work is mostly done, it would be good if we could get the community in on a search for 2600 and 7800 carts with unique md5 sums. The one wrinkle with that is return data from hotspot reads aren't reliable with many bankswitch formats, but we can work around that.

The problem is, that the bankswitching hotspots may (or may not) return random values. So the same cart may return totally different md5 sums. This is something which needs more research.

[RevEng]

15 minutes ago, Thomas Jentzsch said:

Really? That's cool (I have to test). But why would anyone do that?

Yep. It's a bit of an odd feature, so we can only speculate... maybe the dev wasn't confident the final cart hardware would match up with 1ff8=bank0,1ff9=bank1?

 

15 minutes ago, Thomas Jentzsch said:

The problem is, that the bankswitching hotspots may (or may not) return random values. So the same cart may return totally different md5 sums. This is something which needs more research.

Yep, agreed. We might just skip over the hotspots, or intentionally overwrite them all with FF for the md5 generation. (for both the common rom md5 and the 2600+ cart-dumped md5.)

[Thomas Jentzsch]

4 minutes ago, RevEng said:

Yep, agreed. We might just skip over the hotspots, or intentionally overwrite them all with FF for the md5 generation. (for both the common rom md5 and the 2600+ cart-dumped md5.)

If you do not know the scheme, then you can only skip all known hotspots. Which are quite a LOT.

[RevEng]

Just now, Thomas Jentzsch said:

If you do not know the scheme, then you can only skip all known hotspots. Which are quite a LOT.

If the scheme isn't known, then it will fail to dump correctly on the 2600+, and we'll never get to the md5sum report anyway. So we're already forced to only investigate carts the 2600+ can run.

 

If a scheme doesn't work, it will hopefully be brought to our attention, and Chris and I will investigate and work on adding it. Same as we did for WF8.

[Thomas Jentzsch]

3 minutes ago, RevEng said:

If the scheme isn't known, then it will fail to dump correctly on the 2600+, and we'll never get to the md5sum report anyway. So we're already forced to only investigate carts the 2600+ can run.

Wouldn't you get the 1st 4K then?

3 minutes ago, RevEng said:

If a scheme doesn't work, it will hopefully be brought to our attention, and Chris and I will investigate and work on adding it. Same as we did for WF8.

Chris == @raz0red, right?

[RevEng]

10 minutes ago, Thomas Jentzsch said:

Wouldn't you get the 1st 4K then?

It depends. The md5 is getting reported by stella, and stella will "fatal error" and not display it if the reset vector isn't in the rom area.

 

Also, it's not necessarily the first 4K - it's 4K from whatever the default bank is and/or whatever bank the cart probing may have accidentally triggered.

 

10 minutes ago, Thomas Jentzsch said:

Chris == @raz0red, right?

Correct

[Thomas Jentzsch]

4 minutes ago, RevEng said:

It depends. The md5 is getting reported by stella, and stella will "fatal error" and not display it if the reset vector isn't in the rom area.

Ah, yes.

 

BTW: Is the dumper still testing the schemes one by one? Have you thought about testing multiple schemes at once? And are you still dumping the whole bank? Instead random addresses could be used to check if the banks have changed.

 

That might speed up the dumping process.

[RevEng]

35 minutes ago, Thomas Jentzsch said:

BTW: Is the dumper still testing the schemes one by one? Have you thought about testing multiple schemes at once? And are you still dumping the whole bank? Instead random addresses could be used to check if the banks have changed.

 

That might speed up the dumping process.

I really shouldn't speak to the dumper mcu implementation details publicly, beyond what's already been discussed or discovered publicly. It's entirely Plaion's code and algorithms.

 

What has been discussed publicly is the fact that the dumper mcu operates at 115200 baud. The time for transferring one byte serially at that speed is more than two orders of magnitude greater than the time to read one byte from a cart at 2600 speeds, so the cart reads themselves are a drop in the performance bucket.

[Thomas Jentzsch]

21 minutes ago, RevEng said:

I really shouldn't speak to the dumper mcu implementation details publicly, beyond what's already been discussed or discovered publicly. It's entirely Plaion's code and algorithms.

I thought you might have more influence.

21 minutes ago, RevEng said:

so the cart reads themselves are a drop in the performance bucket.

That's why I suggested to minimize the data dumped during detection.

[Dutchman2000]

Rumor has it that the Tarzan prototype also has a special bank switch scheme.....

[RevEng]

1 minute ago, Thomas Jentzsch said:

That's why I suggested to minimize the data dumped during detection.

As the guys who have hooked up dumper serial connections to the dumper have shown, only the final rom is transferred to the arm over that serial line, along with some minimal header and footer bytes. There isn't a back-and-forth or redo over serial.

[Thomas Jentzsch]

Just now, RevEng said:

As the guys who have hooked up dumper serial connections to the dumper have shown, only the final rom is transferred to the arm over that serial line, along with some minimal header and footer bytes. There isn't a back-and-forth or redo over serial.

I meant the schema detection, not the final dump.

 

For detecting that a bank has changed after testing e.g. a hotspot, you do not have to compare whole banks. Just fingerprints of the banks. Especially because the cart speed is the limit here.

 

And you could test multiple schemes using different hotspots at once. If the fingerprint does not change, all tested schemes can be eliminated at once. Else, repeat with binary search. If you test schemes one by one, this becomes slower with each new scheme supported. Also 2K/4K games are only detected then after all schemes have been tested and eliminated. So these are dumped really slow compared to their size.

 

On top, one could also try to find pattern in the dumped data, like Stella does (with access to the full ROM). But that's probably overkill and overly complex. 

[Thomas Jentzsch]

16 minutes ago, Dutchman2000 said:

Rumor has it that the Tarzan prototype also has a special bank switch scheme.....

No comment. Or did you see a new scheme in Stella's repository?  

[RevEng]

Thomas, I can't really get into a public discussion of how things are architected now vs before.

Right now the serial transfer is the majority of the bucket. I think most owners would want dev effort going toward compatibility vs a redesign for minor cart load speed improvements.

[Thomas Jentzsch]

Understood. I'll leave things up to you. They are in good hands. 

[kevtris]

22 hours ago, Thomas Jentzsch said:

Maybe @kevtris does remember? 

 

In general, the Coleco F8 bankswitching code looks odd. There are lot of padding NOPs around. Maybe the code was prepared for multiple bankswitching options? Maybe many of the dumps we know were hacked to F8? Interesting for sure...

unfortunately I don't remember a whole lot, but I do remember tracing the pcb out.  it used 4 TTL chips and an EPROM from what I recall.  Checked around and I can't find the PCB right off the bat so I might've given it to a friend (I put it back into the cart shell, it didn't work when I got it since a trace got eaten away somehow so I fixed it).

 

the NOP padding could be a "landing zone" so that a slow bankswitch wouldn't crash it, switching halfway through the next instruction or similar.  They could've just been overly cautious of speed limits on the bankswitching hardware too. 

[Thomas Jentzsch]

4 hours ago, kevtris said:

unfortunately I don't remember a whole lot, but I do remember tracing the pcb out.  it used 4 TTL chips and an EPROM from what I recall.  Checked around and I can't find the PCB right off the bat so I might've given it to a friend (I put it back into the cart shell, it didn't work when I got it since a trace got eaten away somehow so I fixed it).

@kevtris Thanks for the reply. Even if you do not remember this specific case, have you back then ever (or maybe even frequently) modified ROMs to make them work with the then existing hardware or emulators? Or do you know that this happened? If these ROMs are still floating around, we should try to sort them out.

[kevtris]

8 hours ago, Thomas Jentzsch said:

@kevtris Thanks for the reply. Even if you do not remember this specific case, have you back then ever (or maybe even frequently) modified ROMs to make them work with the then existing hardware or emulators? Or do you know that this happened? If these ROMs are still floating around, we should try to sort them out.

I never hacked any ROMs to make them work, except the FA ones, I added an extra empty bank with a single bankswitch to make them 16K but that was only for my own "bankzilla" use and I never released those.  I don't think I released a hacked smurfs image but who knows, it was 25+ years ago now.

[CPUWIZ]

I probably have a Coleco EPROM board laying around somewhere and this is something I mentioned before, what I believe to be the case is that the TTL chips are doing banking under other conditions than just F8 and they probably avoid touching those hotspots.