One Last EPROM

[+Nezgar]

Neat! Sure, if you have the means to dump the ROM (an eprom burner set to read 27C32) go ahead and we can compare it.

[tjlazer]

Turns out I don't have a burner that can do these chips

[slaker]

Success!

 

burned the fixed ICD.BIN (aka UsDoubler_ok.bin on pigwa) and this ROM's seek times are about 2x faster than a standard 1050, the other USDoubler ROM I'm familiar with, or even the Happy 1050! Seeks perform very similarly to the WST stock ROM and SPEEDY.

 

I wouldn't recommend using UsDoubler_ok.bin to write to any disks you care about. I've disassembled it and Usdblr_err.rom and compared them. UsDoubler_ok.bin seeks twice as fast because it only waits 5ms between head steps (two steps per track) instead of the 10ms required by the Tandon TM50-1 mechanism specifications (20ms minimum track-to-track seek). Tandon apparently did make TM50-1s with optional 6ms stepper motors; perhaps you're lucky enough to have one, but the fast stepping may not work for everyone, possibly resulting in misaligned tracks. Another problem is that UsDoubler_ok.bin gets the test backward for enabling write precompensation, enabling it on tracks 0-19 instead of 20-39 as it should. It also lacks some timeout and retry code that is present in Usdblr_err.rom (presumably the "_err" part means "error checking"), so it's possible for the firmware to hang. Finally, UsDoubler_ok.bin uses a slower sector interleave layout for single density formatting than Usdblr_err.rom.

 

TL;DR: UsDoubler_ok.bin is not okay and should die in fire.

 

So it seems at least the 1st byte of this USDoubler ROM before the drive number assignment bytes is related to seek/stepper timings, and possibly those other 10 bytes as well. My previous tests with the first byte as 'FF' being a higher number than '1D' must have been setting the speed too fast.

 

The first four bytes encode the pulses sent via the 6532 RIOT to the stepper motor for each of its phases (four on Tandon mechs). You really don't want to mess with them.

[+Nezgar]

Thanks for the thorough analysis.

 

I believe original US Doubler code=usdblr_err.rom. Those findings support _ok contains non-ICD hacks.. can't imagine they'd be that sloppy.

 

I'm curious about the stepper timings used by speedy, turbo 1050, and the 1050 chip archiver emulator, as they all use faster/similar stepper timings, and I haven't had problems with those on a number of drives. Maybe out of spec, but found to be ok in the field most of the time...

 

Getting the write precomensation backwards is not good. Are you able to make the corrections for a new ROM?

Edited July 1, 2018 by Nezgar

[+Nezgar]

is there particular bytes for the stepper timings that can be modified in the _err image, while leaving everything else as is, without recompiling? And would it also need checksum bytes to be updated.

[+Nezgar]

Curiosity got the best of me... and well, I've never owned an original US Doubler... so I made good and got one from B&C.

 

The RAM pack is the expected black ICD logo'd epoxy brick, and the ROM is just a 2732 EPROM like the homebrews. Is the ROM, it's labelling, and the anti-static foam pretty much how the originals always were, or has B&C potentially created their own EPROMs to match up with an excess of original RAM packs?

 

I also dumped the ROM and can confirm its the expected CRC32 605B7153

[+Stephen]

Curiosity got the best of me... and well, I've never owned an original US Doubler... so I made good and got one from B&C.

 

The RAM pack is the expected black ICD logo'd epoxy brick, and the ROM is just a 2732 EPROM like the homebrews. Is the ROM, it's labelling, and the anti-static foam pretty much how the originals always were, or has B&C potentially created their own EPROMs to match up with an excess of original RAM packs?

 

I also dumped the ROM and can confirm its the expected CRC32 605B7153

I'm guessing it's a repro. It also looks like the manual is a photocopy of the original.

[Gunstar]

Definitely a repro, I still have the original US doubler book, with gray and purple cover.

[+kheller2]

Turns out I don't have a burner that can do these chips

 

Boo. It would be nice to have a copy of that ROM.

[+kheller2]

I have an original USD with EPROM.. thought I uploaded it once before. Will hafta dig it out. But I don't recall the sticker looking like that one you got from B&C.

[+Nezgar]

I have an original USD with EPROM.. thought I uploaded it once before. Will hafta dig it out. But I don't recall the sticker looking like that one you got from B&C.

 

Maybe yours is an original mask rom like tjlaser's in post #50 ? Would be nice just to be sure... tjlaser's looked like pretty late date codes (85/86)

[+kheller2]

This is the original EPROM I got back in the 80's.

 

[+Nezgar]

Rev. L ? interesting - Stock 1050 Rev L ROM added support for the WD2797 controller. Maybe ICD made an 'update' later on to also support that controller. Do you have a dump of it? I should test some USD ROM's with my 1050 that has a 2797...

[+Nezgar]

Well, if your EPROM hasn't suffered from bit loss, it's a new one to me. Comparing to dumps I've acquired of Rev J, K, L, and WST, your ROM is least different from Rev J, in four places:

File1=your 1050 ROM Chip.BIN
File2=1050-revJ.rom
 
Compare error at OFFSET 0
file1 = FF 11111111
file2 = FB 11111011
Compare error at OFFSET 3EA
file1 = EA 11101010
file2 = 46 01000110
Compare error at OFFSET 3EB
file1 = EA 11101010
file2 = B6 10110110
Compare error at OFFSET FF9
file1 = 48 01001000
file2 = 4A 01001010

EPROM's erase to FF's (1's), so I would think that if it is suffering from long term bit loss, we'd see random 0's change to 1's. This fits offset 0, but not the other three offsets.

Reviewing a post earlier in this thread again - DavidMil's 1050 EPROM he dumped from that pre-production looking 1050 PCB, the byte at offset FF9 just caught my eye... 48 would indicate Revision "H" ROM, which is 2 letters prior to the the earliest I currently know of - Rev J. It would make sense for a pre-production board to have one of the earliest ROM's. But it's only 4 bytes different than Rev J... Offset 0, we know is probably because of a problem in DavidMil's EPROM programmer always getting FF for the first byte, 3EA and 3EB are NOP's (of the checksum routine?? maybe not, WST ROM Checksum NOP's are near the end of the ROM), and FF9 is the revision... So maybe the only difference from "Rev H" to "Rev J" was whatever those 2 NOP'd bytes do.

 

DavidMil, are you able to try dumping this again by alternate means to read the correct 1st byte? It would be nice to get a clean dump to validate. Then we have 1 more officially known 1050 ROM version! (up to 5 from 4)

 

1st byte is probably the same as Rev J/K/L (FB) , but we should confirm. If byte 0 is not FB, the stepper motor phase encoding is different than J/K/L. Can anyone comment on what the NOP's in this code may be skipping? In Rev J these bytes are: $46 $B6 = LSR $B6.

 

Edit: We're getting closer to the Rev. "E" or "F" ROM's mentioned in Tech Tip 21 in AtariMania's 1050 FSM: http://www.atarimania.com/documents/atari-1050-field-service-manual.pdf#page=40 "The first 1700 units released to the field have a revision "E" or "F" EPROM installed. This revision of the firmware returns a different error status than the 810 disk drive when certain types of protection schemes are used..."