US Doubler ROM

[TGB1718]

Does anyone know if/where I can get a ROM dump of US Doubler, I want it/them is to check the contents against one I have.

I assume there may be several versions, but hopefully one will match mine.

 

The reason... I have been building an EPROM Programmer using a Pi Zero W to eventually burn some EPROM Cartridges, but have

been getting strange results mainly due to the EPROMS I have, (BBC Mico Sideways RAM/ROM module I found in my box of bits).

 

Then I came across this, I must have made a backup when I installed US Dbl in my 1050 back in the 80's, so I made an adaptor

as I built my programmer to Read/Write 2764/27128 and 27256 EPROMS.

 

It seems to have read it ok, but a verify with a known good dump would confirm that I can so far read ok.

 

 

 

This is a partial Hex Dump

 

 

Edit. I also have the original TANDON Rev.L ROM from my drive, just in case someone knows if they are available somewhere

Edited November 3, 2019 by TGB1718
Extra info

[xrbrevin]

ive found an abundance:

http://ftp.pigwa.net/stuff/collections/atari_forever/Extension/ICD US Doubler/

http://ftp.pigwa.net/stuff/collections/atari_forever/Extension/US-DOUBLER/

http://ftp.pigwa.net/stuff/collections/atari_forever/ROM/Rom - Hardware/USDOUBLE/

http://ftp.pigwa.net/stuff/collections/atari_forever/ROM/

http://ftp.pigwa.net/stuff/collections/RK-DVD/Atari 800 Images und Files/Cartridges And Roms/Peripheral Roms/

 

i think Nezgar analysed various ones a while back and he uploaded one with fast stepping

[TGB1718]

many thanks, will download them and see whats there 

[Mclaneinc]

If you get no joy then ask again, there's shed loads of dumps...

[+Nezgar]

Verify US doubler ROM's against my summary in this post, I know of three variations:

 

If you dig deep enough in these forums, there's another hacked US Doubler variant that disables some of the poweron hardware verification checks from when the MegaSpeedy was being developed... Don't use that either

 

The standard drives 1-4 can be changed by modifying the bytes that read '3241' in bytes 5th to 8th bytes of a US doubler ROM without having to recalculate the checksums. It will however make it not match the CRC32's in that post. The ICD advertized US doubler variant for drives #5-8 is the same with merely those 4 bytes modified to "7685". With SpartaDOS X, you can actually make use of up to 15 US doubler drives with the ROM's customized this way...

[TGB1718]

Thanks for all the help, so far I seem to have 3 versions that differ, not found one that matches mine, I will read that thread you posted Nezgar

cheers

[+Nezgar]

7 hours ago, TGB1718 said:

so far I seem to have 3 versions that differ, not found one that matches mine

The file should be exactly 4096 bytes. Since you mentioned your programmer was built to Read/Write 2764/27128 and 27256 EPROMS, you might get a larger file, most likely with the 4K repeated multiple times to make an 8K, 16K, or a 32K file. Check in your hex editor if this seems to be the case, and you can strip off everything after the first 4K, and then check the CRC32 again.

 

Otherwise, maybe you can just post the file here to look at directly.

[TGB1718]

Thanks for the advise, the file is exactly 4096 bytes, forgot to mention as I built the programmer, I also

modified the code to allow for the smaller ROM, basically when you run the software it asks what type

of ROM you are using.

Here is the dump I'm getting.

ROMData.bin

[Alfred]

Did anyone ever figure out/fix the bug with USD roms wherein it would kill the disk after a dozen or so read/writes that were random ? Usually when updating directories while running say Hardback, after copying three or four subdirectories it would trash the disk while seeking around in the subdirectories.

Edited November 4, 2019 by Alfred

[+Nezgar]

On 11/4/2019 at 6:20 AM, TGB1718 said:

Here is the dump I'm getting.

CRC32 = DA77F8C0 - indeed doesn't match one I know of, so let's see what's different...

 

Interestingly, it does actually initialize and function under Altirra's full drive emulation. it has the usual slower tandon stepping rate, and will boot MyDOS on an ED disk. However, it generates error 160 or error 163 reading sector 1 when trying to get a disk directory... DOS 2.5 seems OK, but doesn't regularly read sector 1, so not sure about that...

 

I compared again with the known ICD code (CRC32 = 605B7153) and it does not error out reading sector 1 with the same ATR...

 

Comparing these two images in HxD, we see the following differences:

 

Offset 1A = 02 in TGB1718's dump, 13 known ICD dump (possibly ROM checksum?)

 

Further differences, Offset 0139-014B, 041F, 043D, 044D, 0450, 0454, 0469 onwards until looks shifted -16 or -17 bytes in TGB1718's dump. After offset 0941, it again matches to the end...

 

Offset differences like that, and still functioning implies this dump is actually good, and has been recompiled.... Either this is a new patched variant, or may be an earlier "lost" ICD code version I previously speculated may exist and not support 2797 controllers. I'll have to burn this to an EPROM and test this theory.

 

In the mean time, maybe someone like @phaeron can spot any obvious differences in this code. ?

 

On 11/4/2019 at 3:36 PM, Alfred said:

Did anyone ever figure out/fix the bug with USD roms wherein it would kill the disk after a dozen or so read/writes that were random ? Usually when updating directories while running say Hardback, after copying three or four subdirectories it would trash the disk while seeking around in the subdirectories.

Wut? I've never heard of this before.

 

Were you by chance using SpartaDOS X when this issue occurred? BITD I recall SDX would often corrupt my hard drive partition directories and bitmap tables after a lot of copy/file/directory operations, maybe similar, requiring CLEANUP.COM to make everything better... but rarely had a problem when dropping back to Sparta 3.x causing any issues for routine BBS operations.

Edited November 6, 2019 by Nezgar
Added link to previous speculation of an earlier ICD US Doubler ROM

[Alfred]

3 hours ago, Nezgar said:

Wut? I've never heard of this before.

 

Were you by chance using SpartaDOS X when this issue occurred? BITD I recall SDX would often corrupt my hard drive partition directories and bitmap tables after a lot of copy/file/directory operations, maybe similar, requiring CLEANUP.COM to make everything better... but rarely had a problem when dropping back to Sparta 3.x causing any issues for routine BBS operations.

 

No, this was long before SDX or even 3.2D. Only happens in double density mode, and only when doing the seeking back and forth and updating of directory entries. Something wrong with the timing or something, it could work for a long time but eventually it will write a bad sector and the disk is toast. It made Hardback and FlashBack useless for backing up to floppy disk and was the impetus behind me writing my own backup program.

 

 

 

[phaeron]

6 hours ago, Nezgar said:

Comparing these two images in HxD, we see the following differences:

 

Offset 1A = 02 in TGB1718's dump, 13 known ICD dump (possibly ROM checksum?)

 

Further differences, Offset 0139-014B, 041F, 043D, 044D, 0450, 0454, 0469 onwards until looks shifted -16 or -17 bytes in TGB1718's dump. After offset 0941, it again matches to the end...

Most of these differences are due to shifted JMP/JSR targets, but this dump appears to be missing code in the density detection routine to set bit 7 of the first status byte when switching to ED. It will read the disk, but report it as single density instead of enhanced density in the Get Status command. Read PERCOM Block is probably not affected.

[TGB1718]

13 hours ago, Nezgar said:

CRC32 = DA77F8C0 - indeed doesn't match one I know of, so whats different...

 

Interestingly, it does actually initialize and function under Altirra's full drive emulation. it has the usual slower tandon stepping rate, and will boot MyDOS on an ED disk. However, it generates error 160 or error 163 reading sector 1 when trying to get a disk directory... DOS 2.5 seems OK, but doesn't regularly read sector 1, so not sure about that...

 

I compared again with the known ICD code (CRC32 = 605B7153) and it does not error out reading sector 1 with the same ATR...

 

Comparing these two images in HxD, we see the following differences:

 

Offset 1A = 02 in TGB1718's dump, 13 known ICD dump (possibly ROM checksum?)

 

Further differences, Offset 0139-014B, 041F, 043D, 044D, 0450, 0454, 0469 onwards until looks shifted -16 or -17 bytes in TGB1718's dump. After offset 0941, it again matches to the end...

 

Offset differences like that, and still functioning implies this dump is actually good, and has been recompiled.... Either this is a new patched variant, or may be an earlier "lost" ICD code version I previously speculated may exist and not support 2797 controllers. I'll have to burn this to an EPROM and test this theory.

 

In the mean time, maybe someone like @phaeron can spot any obvious differences in this code. ?

 

Wut? I've never heard of this before.

 

Were you by chance using SpartaDOS X when this issue occurred? BITD I recall SDX would often corrupt my hard drive partition directories and bitmap tables after a lot of copy/file/directory operations, maybe similar, requiring CLEANUP.COM to make everything better... but rarely had a problem when dropping back to Sparta 3.x causing any issues for routine BBS operations.

You may be right, if I remember I got this very early on, very soon after the 1050 was released, I think the next step is to remove

the ROM from my working USD 1050 and dump the ROM and see if it's the same, it should be, but back then I was doing all sorts

of hardware/software hacks, so who knows, (been round the goldfish bowl too many times since then)

[+Nezgar]

On 11/4/2019 at 11:24 PM, phaeron said:

Most of these differences are due to shifted JMP/JSR targets, but this dump appears to be missing code in the density detection routine to set bit 7 of the first status byte when switching to ED. It will read the disk, but report it as single density instead of enhanced density in the Get Status command. Read PERCOM Block is probably not affected.

Can you tell if the FDC controller commands are different compared to the known official ICD (c) 1985 CRC32 605B7153 ? The read and write commands were changed from Atari's stock 1050 ROM Revision K to L to support the 2797 controller, so I suspected an earlier US Doubler ROM would have not supported the 2797 either.

 

Reference: https://atariage.com/forums/topic/156462-1050-roms/?do=findComment&comment=3581549

 

On 11/5/2019 at 7:04 AM, TGB1718 said:

You may be right, if I remember I got this very early on, very soon after the 1050 was released, I think the next step is to remove

the ROM from my working USD 1050 and dump the ROM and see if it's the same, it should be, but back then I was doing all sorts

of hardware/software hacks, so who knows, (been round the goldfish bowl too many times since then)

ROM dumps tell all! I encourage you to do it. At least it you would know for sure what's running in your drive, and you never know if you'll find another variant.

[phaeron]

16 hours ago, Nezgar said:

Can you tell if the FDC controller commands are different compared to the known official ICD (c) 1985 CRC32 605B7153 ? The read and write commands were changed from Atari's stock 1050 ROM Revision K to L to support the 2797 controller, so I suspected an earlier US Doubler ROM would have not supported the 2797 either.

 

Reference: https://atariage.com/forums/topic/156462-1050-roms/?do=findComment&comment=3581549

It looks like the commands are also 2797-compatible in this version, as it is using $A8 and $88.

[+Nezgar]

4 hours ago, phaeron said:

It looks like the commands are also 2797-compatible in this version, as it is using $A8 and $88.

Thanks again @phaeron, very interesting. Maybe someday an actual ICD labelled chip with this code will turn up to suggest more clues.

 

This still sure seems to be an early release or leaked development version though...

[TGB1718]

I just removed the ROM from my drive and dumped the contents, it's an exact match for the one I posted here, so as

I thought, I made a backup of the original