Searching for Super Archiver ROM dumps

[HiassofT]

As the topic says, I'm in search for Super Archiver ROM dumps.

 

The only dump I currently know of is the one from Nir Dary: https://sites.google.com/site/ataripal/superarchiver

 

I added support for the Super Archiver to our upcoming 1050 upgrade, and so far it seems to work fine (including creation of weak sectors and RPM switching), but the diagnostic tool reports a ROM error. I'm not sure if this is due to an error in the dump that I use or some other issue (we are using a 65C02, but I _think_ that shouldn't matter):

 

I checked the diagnostic program and one strange thing (if I'm not mistaken) is that the checksum for ROM V1.6 should be $B9C7 but it reports s $BAC6 - close enough, but still a fail

 

So it would be nice to have other dumps to compare the results. It looks like there might be several different ROM versions (also V2.x), so having them and maybe knowing about the differences would be interesting, too.

 

Ah, well, and any hints what could be causing the diagnostics test to fail (or experiences with Nir's dump and diagnostics on a "real" homebrew super archiver) would be highly appreciated

 

so long & thanks in advance,

 

Hias

[HiassofT]

I hacked up a simple ROM dumper so it's easy to extract the ROM and the $F100-$F7FF RAM (which contains the decrypted ROM code) without having to use sophisticated hardware tools

 

If you own a Super Archiver, please run the program and post your ROM and RAM dump(s) here, or send them to me by email.

 

Please also run the diagnostic tool from the Super Archiver disk and post your ROM version number(s) and if the ROM test passes or fails.

 

so long & thanks in advance,

 

Hias

sadump-140816.zip

[sup8pdct]

I know i used to have an image of the rom and dissembled it as well to have a look. Think i can find any of it now

 

James

[HiassofT]

Thanks to Larry I was able to track down my problem!

 

It had nothing to do with the ROM dump, but I missed the "copy protection" when recreating the address decode logic and therefore the very last byte of the RAM (containing the decrypted ROM code) was different - and the ROM test (which also checks $F100-$F7FF from the RAM) reported a checksum error.

 

When you look at Nir's super archiver schematic you'll notice that the RAM/ROM selection is somewhat strange:

 

CE of both chips is set when A12 is high.

OE of the ROM is set when A11 is high.

OE of the RAM is set when A11 is low.

 

Everything fine so far - RAM is mapped to $F000-$F7FF, ROM to $F800-$FFFF (and mirrored addresses $1xxx etc).

 

But I missed a tiny part: /WE of the RAM is set whenever RW is low.

 

So writing to $Fxxx always enables the RAM - actually, when writing to $F800-$FFFF both the ROM and the RAM are selected (ROM in read mode, as it doesn't care about the RW line - which might be a bad idea to do as the data output to the CPU will clash with the data output by the ROM, and the RAM in write mode).

 

I also found the copy protection code in the decrypted ROM contents: two "ROR $FFFF" instructions. They seem to be called with C=1, $FFFF contains the value $FF, so the last RAM byte $F7FF is overwritten with $FF....

 

Tricky little beast :-)

 

so long,

 

Hias