Jump to content
IGNORED

Sector Alpha Rom - Corrupted?


Ikrananka

Recommended Posts

It's been a known fact that all the rom dumps made over the years were corrupt, but not until Ikranaka started his investigation did it become known that there was an issue with the actual cartridge.

 

A big THANK YOU to Ikranaka, Steve Tucker, Nanochess and Pixelboy.

I would like to reiterate those thanks to everyone involved and in particular Steve Tucker and Nanochess who, without their technical expertise, this solution would not have been possible.

 

I haven't been able to look into this much today but I am certain that the rom posted above by Pixelboy contains some garbage at the end and that the actual rom size can be cut down to 20k (the garbage is just left over from the common dump of the cart that is on the internet). I will work on this tomorrow and post a clean 20k rom here. This will not affect the gameplay or graphics at all and is just an exercise in deleting unused garbage data from the file itself.

  • Like 1
Link to comment
Share on other sites

Well, I have finally had a chance to catch up on the posts in this topic and to spend a little time working on the cleaning up of the ROM file. Firstly, I would just like again to say a HUGE thank you to Steve Tucker and nanochess. I had absolutely no idea that there were all those graphic details missing from the planet landscape (despite them being shown on the screenshot on the back of the box and in the game manual) and had simply assumed that what the cart displayed on a CV was correct. I'll not make that mistake again!!! Lesson learned - always check against versions on other machines first.

So, absolutely fantastic to finally have the ROM for this game as it was intended to be by the programmer (before others in the production process messed it up).

Attached is the cleaned up ROM file as I promised a few posts back. This has been created as follows:

  • Created a new 32k ROM dump from a cart using an AtariMax cart dumper. This was created by dumping the cart three times and verifying that the first 16k were identical each time.
  • Copied 0x056e bytes from offset 0x4a92 in the SVI-328 ROM to offset 0x4800 in the Colecovision ROM (where buggy ROM starts) - thanks nanochess :)
  • Deleted the last 12k to yield a 20k ROM file.

The last step is necessary because:

  1. It is now known that the cart contains no more than 20k in PROMS and as such the game ROM cannot be any larger than this.
  2. Analysis of the dumped 32k CV ROM from 0x4d6e through to 0x57ff (i.e. starting at 0x56e offset from 4800 - so where the end of the SVI-328 ROM section has been added) shows that it is in fact a copy of an earlier section of the ROM file except with the ff values replaced with 8d. I have seen this behaviour in a number of other carts that I have dumped and the copied sections are always in error. Plus this erroneous section continues well past the known PROM 20k limit which ends at 0x4ff0.

Enjoy!!!!!

Sector Alpha (1983)(Spectravideo)f.zip

  • Like 5
Link to comment
Share on other sites

So, what's the deal with the Sector Alpha carts? Does a game cart play okay, or are they all (or most or some) corrupted? If they're corrupted, were they always like that, or did this happen over time?

 

So far all carts that have been tested have been corrupted. The corruption does not appear to affect gameplay but does mean that the graphics for the landscape on the planets surface are wrong. The carts display just a series of dots for the landscape whereas it should show lots of features and details as shown in the video and images that nanonchess posted earlier.

 

This is definitely not something that happened over time due to degraded cart components but is a corruption that was introduced in the original cart production process.

  • Like 2
Link to comment
Share on other sites

Well, my curiosity has gotten the better of me and so I have just ordered an adaptor for my EPROM programmer that will allow me to read the 2332 and 2364 PROMs in the Sector Alpha cart. This will at least allow us to know if the full last 4KB of data is contained in the 2332 PROM or not.

 

Likely a waste of time I know........nevertheless, I'll post back here once I've received the adaptor and dumped the PROMs.

  • Like 4
Link to comment
Share on other sites

  • 4 weeks later...

The adapter for my EPROM programmer arrived and I have desoldered the PROMs from the cart PCB. The results of reading each PROM are partly as expected and partly curious. Looking for some help from someone who understands these things.

 

I managed to read the two 2364 PROMs successfully and they exactly matched the first 16KB of the dump using the AtariMax MaxFlash dumper - as expected.

 

However, when reading the 2332 PROM I only get 2KB of valid data out of the 4KB dumped (the last 2KB is full of 0xFF values). This is what Steve Tucker experienced. What is really curious though is that I get a different 2KB to what the MaxFlash dumper gives. The 2KB I get is definitely what is supposed to be the final 2KB of data for the overall 20KB rom (this is the 2KB that defines the planet landscape graphics and has never been dumped from a Sector Alpha CV cart before). The MaxFlash dumper gives me the 2KB prior to that (this 2KB is critical to the game working and is the 2KB that the CV console sees when playing the game). So this got me thinking that the 2332 must have the full 4KB of data required for the game contained in it. The 2332 PROM has two Chip Select pins (CS1 and CS2) - could it be that the signal on these is key to which 2KB is output? Of note is that the cart PCB was designed for three 2364 PROMS and so the 2332 PROM is sitting in a 2364 slot with CS2 connected to GND via the soldered jumper wire as seen in the photo Steve Tucker provided. I have been varying connecting these pins to GND and VCC on the universal adapter with no success (I either get the same 2KB data/2KB 0xFF or 4KB of 0xFF values). I have also tried setting up the PROM on the adapter as a 2364 PROM but connecting CS2 to GND to try and replicate the way it is setup on the PCB - however again I get no output (I just get 8KB of 0xFF values).

 

I'm not an electrical engineer and so I have been working on pure guesswork and have got to the point where I am at a loss what to do next :(. I'm convinced that the full 4KB of game data is on the 2332 PROM (it must be there if the AtariMax dumper retrieves the first 2KB and my EPROM programmer manages to get the last 2KB from it) - but would love to know how to access the 2KB that the MaxFlash dumper retrieves but via the EPROM programmer + universal adapter. This would allow me to understand what went wrong when they manufactured these carts. It will also allow me to provide the definitive rom for the game in the next release of my rom package.

 

A critical point, and one that has made this latest exercise worthwhile, is that the 2KB I managed to get from the 2332 on my programmer, while matching most of the SVI-328 data that was added with nanonchess guidance, also includes other data beyond that. Therefore, the current Sector Alpha rom I have in the v1.1 rom package is definitely not the correct/complete ColecoVision version.

Link to comment
Share on other sites

The adapter for my EPROM programmer arrived and I have desoldered the PROMs from the cart PCB. The results of reading each PROM are partly as expected and partly curious. Looking for some help from someone who understands these things.

 

I managed to read the two 2364 PROMs successfully and they exactly matched the first 16KB of the dump using the AtariMax MaxFlash dumper - as expected.

 

However, when reading the 2332 PROM I only get 2KB of valid data out of the 4KB dumped (the last 2KB is full of 0xFF values). This is what Steve Tucker experienced. What is really curious though is that I get a different 2KB to what the MaxFlash dumper gives. The 2KB I get is definitely what is supposed to be the final 2KB of data for the overall 20KB rom (this is the 2KB that defines the planet landscape graphics and has never been dumped from a Sector Alpha CV cart before). The MaxFlash dumper gives me the 2KB prior to that (this 2KB is critical to the game working and is the 2KB that the CV console sees when playing the game). So this got me thinking that the 2332 must have the full 4KB of data required for the game contained in it. The 2332 PROM has two Chip Select pins (CS1 and CS2) - could it be that the signal on these is key to which 2KB is output? Of note is that the cart PCB was designed for three 2364 PROMS and so the 2332 PROM is sitting in a 2364 slot with CS2 connected to GND via the soldered jumper wire as seen in the photo Steve Tucker provided. I have been varying connecting these pins to GND and VCC on the universal adapter with no success (I either get the same 2KB data/2KB 0xFF or 4KB of 0xFF values). I have also tried setting up the PROM on the adapter as a 2364 PROM but connecting CS2 to GND to try and replicate the way it is setup on the PCB - however again I get no output (I just get 8KB of 0xFF values).

 

I'm not an electrical engineer and so I have been working on pure guesswork and have got to the point where I am at a loss what to do next :(. I'm convinced that the full 4KB of game data is on the 2332 PROM (it must be there if the AtariMax dumper retrieves the first 2KB and my EPROM programmer manages to get the last 2KB from it) - but would love to know how to access the 2KB that the MaxFlash dumper retrieves but via the EPROM programmer + universal adapter. This would allow me to understand what went wrong when they manufactured these carts. It will also allow me to provide the definitive rom for the game in the next release of my rom package.

 

A critical point, and one that has made this latest exercise worthwhile, is that the 2KB I managed to get from the 2332 on my programmer, while matching most of the SVI-328 data that was added with nanonchess guidance, also includes other data beyond that. Therefore, the current Sector Alpha rom I have in the v1.1 rom package is definitely not the correct/complete ColecoVision version.

 

I've found these pinouts for 2332 and 2732, there are some small differences, but probably very important:

 

http://ist.uwaterloo.ca/~schepers/roms.html

 

In particular A11 and CE2 have different places.

 

This should be enough to get the final dump.

 

I'm looking forward to see it, I'm very curious about the data and the differences versus my patch.

Link to comment
Share on other sites

I'm not an electrical engineer and so I have been working on pure guesswork and have got to the point where I am at a loss what to do next :(. I'm convinced that the full 4KB of game data is on the 2332 PROM (it must be there if the AtariMax dumper retrieves the first 2KB and my EPROM programmer manages to get the last 2KB from it) - but would love to know how to access the 2KB that the MaxFlash dumper retrieves but via the EPROM programmer + universal adapter.

 

I'm not a EE either, but a hypothesis I could work through given a data book for the 2332 and the actual wiring of the cartridge is as follows:

 

They only needed 2K more of space for the game (beyond the two 8K ROMS), but for some reason (cost?) they could not just add a 3rd 8K ROM for the extra. There is probably some wiring hack that would allow the 4K ROM to be accessed in the proper Z80 address space without any additional logic or new circuit board needed. A run of 4K mask ROMs would be cheaper than 8Ks. But assuming the hack worked, it would also mean that attempts to read past the 18K ROM (the upper 2K of the 4K ROM) in the actual CV would give garbage data. (Reading the actual 4K ROM in isolation should give the true data that is stored in it, and by convention, unused space in ROMs is either 00H or 0FFH.) The game would never do this, so no problem, only for in-machine cartridge copiers. However, they might have screwed up the wiring hack... or it may be that it never would have worked like they thought, but since the bug did not crash the game, they let it ship. The box art showing the correct graphics could have come from a development system with full 24K ROM (3 x 8K) etc.

 

An idea, anyways.

 

*Dr. D.*

Edited by Dr. D.
Link to comment
Share on other sites

 

I've found these pinouts for 2332 and 2732, there are some small differences, but probably very important:

 

http://ist.uwaterloo.ca/~schepers/roms.html

 

In particular A11 and CE2 have different places.

 

This should be enough to get the final dump.

 

I'm looking forward to see it, I'm very curious about the data and the differences versus my patch.

 

The best databook is located here - it is the actual UMC databook for the specific chips in question. The 2332 has two chip select lines while the 2364 only has one. My problem is that even after accounting for the difference in pinout I just cannot seem to directly read the 2KB of data that the MaxFlash dumper retrieves.

Link to comment
Share on other sites

 

I'm not a EE either, but a hypothesis I could work through given a data book for the 2332 and the actual wiring of the cartridge is as follows:

 

They only needed 2K more of space for the game (beyond the two 8K ROMS), but for some reason (cost?) they could not just add a 3rd 8K ROM for the extra. There is probably some wiring hack that would allow the 4K ROM to be accessed in the proper Z80 address space without any additional logic or new circuit board needed. A run of 4K mask ROMs would be cheaper than 8Ks. But assuming the hack worked, it would also mean that attempts to read past the 18K ROM (the upper 2K of the 4K ROM) in the actual CV would give garbage data. (Reading the actual 4K ROM in isolation should give the true data that is stored in it, and by convention, unused space in ROMs is either 00H or 0FFH.) The game would never do this, so no problem, only for in-machine cartridge copiers. However, they might have screwed up the wiring hack... or it may be that it never would have worked like they thought, but since the bug did not crash the game, they let it ship. The box art showing the correct graphics could have come from a development system with full 24K ROM (3 x 8K) etc.

 

An idea, anyways.

 

*Dr. D.*

 

The game is most definitely a 20KB game (see next para) - but there is no doubt that they chose to use a 2332 4KB PROM to save costs - this being all that was needed. The problem is that their cart PCB was not designed for the different pinout configuration of this chip. Their compromise was to hack the cart with a jumper that only allowed the lower 2KB to be accessible and shipped the game with inaccessible graphic data.

 

The first 2KB above 16KB is critical game code that if missing just makes the game non-functional. If the game is played with just this first 18KB then most of the graphics for the planet landscape are missing. This first 18KB is all that is accessible when playing a production cart in a real ColecoVision. The 2KB that I have dumped directly from the 2332 PROM is the final "missing" 2KB" and includes not only the missing landscape graphics data but other data as well (the effect of the "other" data is not yet known).

 

The box art just looks like an artist's rendition to me. The actual, and complete, planet landscape looks like this:

 

post-5757-0-60238600-1406669840_thumb.png

Link to comment
Share on other sites

Okay, just figured out (I think) that in theory only one of the Chip Select lines should be driven at one time to activate output. With them being programmable it could be that they need to be driven either high or low to select the chip - only experimenting with the chip in question can answer that question. I think I'll have another try tomorrow with the following configurations (including driving them both high and low just to see what happens):

 

  • CS1 to VCC and CS2 to GND
  • CS1 to GND and CS2 to VCC
  • CS1 to VCC and CS2 to VCC
  • CS1 to GND and CS2 to GND

Regardless, all the CS is supposed to do is to activate the chip to accept inputs on the address lines and to supply the data at that address on the output lines. So, I am even more confused as to why I could possibly read a different 2KB of data compared to the MaxFlash cart dumper. Or did SpectraVideo buy a dodgy batch of chips?

Link to comment
Share on other sites

I'm incredibly pleased to announce that I have managed to pull the complete 4KB of game data from the 2332 4KB mask ROM. Testing has concluded that this ROM has either a design or manufacturing error that makes each 2KB of data only accessible for a particular pinout configuration. The full 4KB is not accessible in one go as it should be. Therefore, the carts were released with the game only being able to access the first 2KB of data while the second 2KB of data was inaccessible.

 

What is more interesting is that the final 2KB of data is different to that in the "fixed" ROM released in v1.1 of my commercial games ROM package. It includes exactly the same graphic data for the landscape of the planet, but then includes a demo mode for the game. Specifically it adds a demo mode player AI to the game so that you actually see what looks to be someone playing the game when the demo mode kicks off (after a few seconds of the game select screen). The demo mode also lasts much longer with this missing code added.

 

So, after all of these years, the full and accurate 20KB ROM for Sector Alpha sees the light of day again (the last person to have seen it likely being the programmer). This will be released in my upcoming update to the commercial games ROM package (in a week or two). This will also include full documentation of the investigation and testing that went into this.

 

Many thanks to nanochess for identifying the function of the newly discovered demo mode code.

  • Like 6
Link to comment
Share on other sites

I'm wondering what components are on the PCB besides ROM chips and bypass capacitor(s)?

 

Also, did you activate one CS at a time to gain access to the data, leaving the other CS at Vcc?

 

The PCB is bare apart from the ROM chips - no bypass capacitors. It is designed for 3 x 2364 8KB mask ROMs with each of their CS lines routed to the appropriate enable line on the cart edge connector.

 

On the Sector Alpha 4KB 2332 mask ROM, CS1 is active low while CS2 appears to have been programmed to "don't care", i.e. if CS2 is set to GND or Vcc the outputs are still active (as long as CS1 is low).

Link to comment
Share on other sites

I now have a little more information. It would seem that although the labelled as being a '2332' it is in fact internally wired up as a 2732 (A11 and CS2 are swapped). Reading it as a standard 2732 gives the full 4KB of game data.

 

I'm now going to see if I can reverse hack the cart PCB to get the full game working with all the original components on a real CV.

  • Like 1
Link to comment
Share on other sites

I'm now going to see if I can reverse hack the cart PCB to get the full game working with all the original components on a real CV.

Success :) A simple hack of the original cart PCB and the full game works on a real CV. It seems crazy that they did a manual hack of the PCBs during manufacture but did the wrong hack and shipped the game broken.

 

I'll post details and a photo of the hack tomorrow. Unfortunately, it does require the cart to be opened and a little soldering.

  • Like 4
Link to comment
Share on other sites

Success :) A simple hack of the original cart PCB and the full game works on a real CV. It seems crazy that they did a manual hack of the PCBs during manufacture but did the wrong hack and shipped the game broken.

 

I'll post details and a photo of the hack tomorrow. Unfortunately, it does require the cart to be opened and a little soldering.

Nice job. :)

 

So does this mean that the hacked ROM made by nanochess to add the missing graphics should now be considered incomplete and obsolete?

  • Like 1
Link to comment
Share on other sites

So does this mean that the hacked ROM made by nanochess to add the missing graphics should now be considered incomplete and obsolete?

The only difference between the two is that when the demo starts (after a few seconds of waiting at the game select screen) it now includes a demo player AI and so looks likes someone is playing it in demo mode. The demo also lasts much longer before returning to the game select screen.

 

I'm going to put together a before and after video as well as the cart PCB hack photos. This will take me a little longer but plan is to post it by the end of this weekend.

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