Jump to content
IGNORED

Sector Alpha Rom - Corrupted?


Ikrananka

Recommended Posts

I just tested a rom dump of Sector Alpha that I recently created using the AtariMax Dumper - however there is a problem. Playing the actual cart on real hardware shows the terrain (lower half of the landscape) as having a black or blue background covered in either blue or pink dots. However, playing the dumped rom on either blueMSX or using an Atarimax SD cart on real hardware, the lower landscape is shown as just solid light red. This is a real problem to play because the light red target graphics cannot be seen on the light red background.

 

post-5757-0-25178800-1398090508_thumb.png

 

Any thoughts on why this may be? Possible solutions?

 

I also have now completed a dump using a much older cart dumper from AtariMax and this yielded a different rom file. This partially solves the problem in that the background main colour matches correctly but is missing the dotted pattern that should be covering it.

 

post-5757-0-15071600-1398090645_thumb.png

 

Comparing the above two roms has shown that there is a 2K region that is different (starting at 4800). In the former case this 2K is filled with FF while in the latter it is filled with 8d. This leads me to believe that the problem may lie in the cart dumper software and how it interprets what it thinks is blank space and with what it then fills that blank space with.

 

Do the Spectravideo carts contain standard DIP PROMS? If so, then I would be willing to sacrifice a cart, open it up, desolder the PROM(s) and dump the individual PROM(s) using an EPROM reader. But only IF others thought that this would eliminate the problem.

 

Appreciate any help.

Link to comment
Share on other sites

I think I may have solved the problem. The value filling the 2K space is definitely a pointer to a tile. The screenshots above show that the dotted landscape starts to be drawn but then stops after 4 tiles (just to the right of the bottom of the pink mountain). Inspecting the rom file showed that there were four bytes with 7E in them just prior to the problem 2K region. So, filling the 2K region with 7E should force the dotted landscape tile to continue to be repeated beyond the initial four, and indeed it does:

 

post-5757-0-30780200-1398091447_thumb.png

 

However, this is a hack and not a pure rom dump and so I am therefore considering opening up the cart and desoldering the proms - does anyone know if Spectravideo used DIP PROMS in their carts?

Link to comment
Share on other sites

  • 2 weeks later...

However, this is a hack and not a pure rom dump and so I am therefore considering opening up the cart and desoldering the proms - does anyone know if Spectravideo used DIP PROMS in their carts?

I would venture to guess that no one ever opened up a Sector Alpha cart to find out. I have a loose Sector Alpha cart which I'm ready to sacrifice. Do you want me to pierce the label and unscrew it?

Link to comment
Share on other sites

I would venture to guess that no one ever opened up a Sector Alpha cart to find out. I have a loose Sector Alpha cart which I'm ready to sacrifice. Do you want me to pierce the label and unscrew it?

 

I am investigating this with Steve Tucker and a cart is on it's way to Steve for testing (just purchased from atari2600.com) and will then be sent on to me. The objective being for Steve to determine if this is a problem that can be resolved by adjustments to the firmware of his cart dumper. The plan is that if Steve cannot resolve this then I will sacrifice the cart to see if it has DIP PROMS that I can then dump directly.

Link to comment
Share on other sites

I think I may have solved the problem. The value filling the 2K space is definitely a pointer to a tile. The screenshots above show that the dotted landscape starts to be drawn but then stops after 4 tiles (just to the right of the bottom of the pink mountain). Inspecting the rom file showed that there were four bytes with 7E in them just prior to the problem 2K region. So, filling the 2K region with 7E should force the dotted landscape tile to continue to be repeated beyond the initial four, and indeed it does:

 

attachicon.gifSector4_0002.png

 

However, this is a hack and not a pure rom dump and so I am therefore considering opening up the cart and desoldering the proms - does anyone know if Spectravideo used DIP PROMS in their carts?

Could you share the hack rom, please? I guess the rom that I have doesn't work. Seems like I remember someone fixing it in the past. I could be wrong.

Thanks

Link to comment
Share on other sites

Could you share the hack rom, please? I guess the rom that I have doesn't work. Seems like I remember someone fixing it in the past. I could be wrong.

Thanks

 

I'd rather not share the hacked rom just now. Let me finish my investigations and I promise that I will issue a solution to this in the near future.

Link to comment
Share on other sites

I'd rather not share the hacked rom just now. Let me finish my investigations and I promise that I will issue a solution to this in the near future.

Sounds good. Thanks. As long as your at it, one thing that bugs me about this game is the controls. Left or right is fine but up and down are opposite of what I think they should be. This was the same issue as Star Wars controls. I believe it was Youki that inverted the controls for that game. It would be nice to have controls like that.

Chuck

Link to comment
Share on other sites

  • 1 month later...

Well Steve did a great job and managed to have a good look at this problem and responded as follows:

 

"The cartridge contains two 8kB mask PROMs that behave as expected. This is the first 16kB of the dump. It also contains a 4kB mask PROM (2332) that contains 2kB of normally readable memory,

but when the high address pin is set, it behaves as if the chip is deselected and the output drivers do not drive the bus.

 

I verified this by attaching a very weak pull-up resistor to the various data outputs on the cart. The two 8kB mask PROMs behaved normally, but the 4kB one displayed modified data in the screen area, the same areas you get changes in when you modify the 0x7E value in the rom dump.

 

I did not remove the PROMs from the PCB, the board is not in great condition, but I expect what you get in the empty area would depend on the design of the eprom programmer used to dump it. If it had no pull-up or pull-down current sources on the i/o pins during read-out, that area would likely seem to contain 0x7E as that's the last byte driven by the output buffers before they shut off.

 

The question is, was this by design or an error. I don't know enough about how these old mask PROMs were factory programmed to say if its someone at the factory trying to shave a penny off the production cost, or if it was just by accident. One thing is sure, even though there are 20kB worth of devices, there is only 18kB of real data to be had in the cart."

I suspect that the behaviour of the mask PROM was by design but doubt we'll ever know. One thing I do believe is that amongst all of the commercially released CV games this is a unique case.

 

I would love to get some comments from those with an understanding of these things (it's way beyond my skill set). What is the best approach to obtaining a game rom file that works both in multicarts and emulators? So far, I have a rom that seems to work correctly in emulation as described in my second post (I'll test in a muticart this weekend). But is this hack approach the correct thing to do?

post-5757-0-01254500-1403889893_thumb.jpg

post-5757-0-63849400-1403889903_thumb.jpg

Link to comment
Share on other sites

Well, I've a quick recipe for this: ;)

 

1. Get a common dump of Sector Alpha for Colecovision and name it sacv.rom

2. Get a dump of Sector Alpha for SVI-328 and name it sasv.bin (hint: "Welcome to the Spectravideo SVI 318 and 328 Roms Section.")

3. Apply the following program to it and enjoy it! :D

/*
** Patch buggy Spectravideo Sector Alpha Colecovision with good data from SVI-328 version
** nanochess Jun/27/2014
*/

#include <stdio.h>

char buffer[0x056e];

/*
** Main program
*/
int main(void)
{
  FILE *in;
  FILE *reference;

  in = fopen("sacv.rom", "rb+");
  fseek(in, 0x4800, SEEK_SET);
  reference = fopen("sasv.bin", "rb");
  fseek(reference, 0x4a92, SEEK_SET);
  fread(buffer, 1, 0x056e, reference);
  fwrite(buffer, 1, 0x056e, in);
  fclose(reference);
  fclose(in);
}

Wow! now it looks beautiful :grin:

 

Edit: If you're using a hex editor, simply move 0x056e bytes from offset 0x4a92 in SVI-328 ROM to offset 0x4800 in Colecovision ROM (where buggy ROM starts)

  • Like 6
Link to comment
Share on other sites

So I guess you managed to solve an ancient mystery, nanochess! Now we know for a fact that Spectravideo used faulty electronics (or maybe faulty programming equipment) to manufacture the ColecoVision cartridges of Sector Alpha, and no one at the company stopped these defective carts from going out the door!

Link to comment
Share on other sites

So I guess you managed to solve an ancient mystery, nanochess! Now we know for a fact that Spectravideo used faulty electronics (or maybe faulty programming equipment) to manufacture the ColecoVision cartridges of Sector Alpha, and no one at the company stopped these defective carts from going out the door!

And there's alot of Spectravideo carts that don't even work at all!

Link to comment
Share on other sites

So I guess you managed to solve an ancient mystery, nanochess! Now we know for a fact that Spectravideo used faulty electronics (or maybe faulty programming equipment) to manufacture the ColecoVision cartridges of Sector Alpha, and no one at the company stopped these defective carts from going out the door!

 

Most probable thing is that the 4K Mask ROM UM2332 requires some additional logic to be decoded, but it was too late when it came out so they only patched the PCB as can be seen in Ikrananka pictures (post #10 memory at rightmost)

 

The other two memories are 8K Mask ROM UM2364.

Link to comment
Share on other sites

Well, the patch works like a charm, and now I really feel like I'm playing this game as it was intended to be played. I just hope I correctly patched the ROM I posted above... :skull:

 

Thank you so much, nanochess! :D :thumbsup:

 

Your patched ROM is right! :)

 

You're welcome :D

Link to comment
Share on other sites

So it's not just the dump that's corrupted, it's all the cartridges as well? How did this go unnoticed for so long?

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.

  • Like 3
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...