Weird 1050 drive with Rev. E OS

[cx2k]

So I was going through some 1050 drives I just got and one of them is pretty funky. The drive overall is in bad shape. Case has some cracks, it seems "rusty" like corrosion in and around the mech. The motherboard is what caught my eye though. It has thick wires going from the mother board positions Q6, Q7 & Q8 to transistors that have been mounted on the heat sink/shielding. There is also a bit of trace work that appears to be done at the factory. And finally, it has a Rev E OS eprom.

 

Speaking to @Nezgar, he says Rev E hasn't been found yet so I will dump it when I get to work tomorrow. Anyone seen any of these other mods/wiring work?

 

John

 

 

[BillC]

To me this board appears to likely be a prototype, given the voltage regulator footprint placement, missing traces between the SIO ports, other miscellaneous patch wires.

[archeocomp]

It is very similar to this exemplar. Maybe it is not so rare.

http://blog.3b2.sk/igi/post/Rozne-verzie-different-versions-Atari-1050.aspx

 

[+DrVenkman]

8 hours ago, BillC said:

To me this board appears to likely be a prototype, given the voltage regulator footprint placement, missing traces between the SIO ports, other miscellaneous patch wires.

That part (wires between the SIO ports) is not so rare; I have a board like that though the drive was non-functional when I got it. I never tried very hard to repair it, and eventually repurposed the case to build my 1088XLD beta machine. But the board had a similar arrangement with the SIO ports wired up together like that rather than proper PCB traces.

[+Nezgar]

Looks like another prototype 1050 PCB pictured in an earlier thread from @DavidMil which also contained revision "H":

https://atariage.com/forums/topic/275166-one-last-eprom/?do=findComment&comment=3959877

 

The exciting thing about this to me is the revision "E" ROM that I've been on the lookout for a few years now! I previously wrote about this here after we found revision "H":

https://atariage.com/forums/topic/275166-one-last-eprom/?do=findComment&comment=4118950

 

Specifically: "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..."

 

I believe most of the changes found in the other known revisions H, J, K were minor SIO timing adjustments. Revision L added support for the 2797 WDC controller, and lastly the WDC mech firmware was a modified rev K with changes to stepper phases and timing (and ROM checksum disabled). Even better that this is revision "E" instead of "F" described in the Tech Tip, as we will now have the earliest known/documented revision, including the supposed "different error status".

 

Edit: Previous thread with details about the revision "H" ROM. This thread has lots of other information regarding disassembly and reverse engineering efforts of the various revisions as well:

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

[E474]

Hi,

 

   I have a similar 1050 PCB, but sadly all the socketed chips had been removed when I received it: 

 

[+Nezgar]

I've had a chance to give @cx2k's ROM dump a once-over. I've confirmed it indeed identifies itself as revision "E" at offset 0xFF9 and confirmed it runs under Altirra full drive emulation.

 

Rev "E" CRC32 is F9A7AFB2. File is attached.

 

Comparing against the rev H binary, there appears to be 32 bytes less total code in E compared to H. Starting at 0x1BC there appears to be an extra 9 bytes in E that show up earlier in H, and then more significantly after about 0x260...

 

F3E4-F3E5 are 2 NOP's like Rev H. (4 cycles) vs 5-6 in rev J-L. Details described by dhinson919:

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

 

Also according to dhinson919, only Rev K and L actually do a working ROM checksum test, so like H & J I suspect this one doesn't either, but need to confirm.

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

Checksum salt at $0004 is 0x63 in E vs 0xF6 in both H & J, so maybe there was intent for it to work in E...

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

 

Lastly is the matter of the "different error status than the 810 disk drive when certain types of protection schemes are used" according to the FSM Tech Tip Would be interesting to know what the actual change was, and which software it might have negatively affected.

 

Would love to hear some further expert analysis from the likes of @dhinson919 and @phaeron!

1050-revE F9A7AFB2.BIN

[phaeron]

ROM checksum is broken in revE.

 

There are no differences in the read sector code that I can tell, but there are two differences in the status command. The first is that rev H+ refetch and store type I status from the FDC after the status command completes. I don't think that's it, as it only affects a second status command and is less compatible than the 810, whose status command only returns cached status and doesn't touch the FDC.

 

The second and likely more pertinent difference is that the rev E status command uses $00-03 to stage the status frame. This is bad as it overwrites part of the sector buffer at $00-7F, which can be returned verbatim to the computer from a previous sector read if a subsequent read fails without reading any data from the FDC (e.g. record not found). In rev H+, it has been changed to use $A5-A9.

 

[cx2k]

Here's something odd. I tested the 1050 with Rev E drive tonight. I hadn't previously tested it because it was pretty beat looking and dirty. I formatted a disk with both DOS 2.0 and SmartDOS. I then booted a sector copier and when I copied the disk, all the sectors were full. This leads me to believe that the Rev E OS does something when formatting that the sectors don't register as empty. I don't know all the tech stuff and hopefully I'm not missing something stupidly obvious. Can anyone verify?

 

John

 

 

 

 

 

[Sugarland]

@cx2k If it's using the sector buffer to store the status frame as stated by @phaeron then yes every sector would show data in the $00-03 range. Have a peek at the sector data to confirm this corruption.

[+DjayBee]

Please post an ATR of the disk. 

[phaeron]

3 hours ago, Sugarland said:

@cx2k If it's using the sector buffer to store the status frame as stated by @phaeron then yes every sector would show data in the $00-03 range. Have a peek at the sector data to confirm this corruption.

No, the reuse of the sector buffer doesn't have anything to do with normal operation or whether sectors are marked as in-use in the volume bitmap. In normal operation, the sector buffer will be overwritten again by data from the disk on a read or data received from the computer on a write. The only time that this matters is when reading a sector that is non-existent or is corrupted such that sector data is never read by the FDC.

 

[sup8pdct]

4 hours ago, cx2k said:

Here's something odd. I tested the 1050 with Rev E drive tonight. I hadn't previously tested it because it was pretty beat looking and dirty. I formatted a disk with both DOS 2.0 and SmartDOS. I then booted a sector copier and when I copied the disk, all the sectors were full. This leads me to believe that the Rev E OS does something when formatting that the sectors don't register as empty. I don't know all the tech stuff and hopefully I'm not missing something stupidly obvious. Can anyone verify?

 

John

 

 

 

 

 

I have noticed that certain roms (depending on drive manufacturer) during format, fill the sector with a byte other then $00. I have also noticed that some sector copiers are aware of this and mark the sector as blank, others don't. I am almost certain what you are seeing is all the sectors are filled with a single byte ( must be a reason for it) and your sector copier is seeing them as filled. View disk in a sector editor and see what each one contains.

 

James

[ijor]

Most Atari drives fill all sectors with zero when formatting the disk. That's what the 810 originally does, and most other drive follow for compatibility reasons. The actual pattern written in the disk surface is $FF because the sector data is written inverted.

 

But technically, using $00 or $FF is not the best value to be written at format time. If you check a PC disk you will note that empty sectors are usually filled with $E5. This is because research have determined that the MFM pattern produced by writing $E5 is magnetically the most stressing pattern to the disk surface, certainly more than writing a plain $00 (or $FF). The idea is that when you format a disk, you want to test it with the "hardest" magnetic pattern. If it verifies OK when the sector is filled with $E5, then it should work with any other pattern. Or at least that is the theory.

 

1050 rom Rev E, at least the one Nezgar posted above, follows in some sense the concept, and fills sectors with $E5 when formatting the disk. But the strange thing is that, because the data is written inverted, the actual sector written on the disk surface is $1A, and not $E5. I guess this was a bug, let alone that the whole concept applies to MFM only, not to single density.

 

I also assume that eventually they realized the incompatibility with the 810 and later rom revisions fill sectors with $00, writing the $FF pattern to the disk surface.

Edited August 23, 2021 by ijor

[cx2k]

As @ijor mentioned, it does populate the sectors with $E5 although the directory sectors are blank. I've attached pics and the .atr if anyone wants to see it.

 

 

Rev E with Dos 2.atr

[+Nezgar]

On 8/21/2021 at 3:13 AM, phaeron said:

The second and likely more pertinent difference is that the rev E status command uses $00-03 to stage the status frame. This is bad as it overwrites part of the sector buffer at $00-7F, which can be returned verbatim to the computer from a previous sector read if a subsequent read fails without reading any data from the FDC (e.g. record not found).

I wonder if there was some (popular?) copy protected software at the time that might have failed due to this...

 

19 hours ago, sup8pdct said:

I have noticed that certain roms (depending on drive manufacturer) during format, fill the sector with a byte other then $00.

I know most (older) Percom ROM's had this behaviour, can you think of any other specific drive brands/types that format with other than $00? (Maybe ATR8000?)

 

1 hour ago, cx2k said:

As @ijor mentioned, it does populate the sectors with $E5 although the directory sectors are blank. I've attached pics and the .atr if anyone wants to see it.

Good investigative theories on @ijor's part! I have confirmed this myself as well... I have formatted a disk in both SD and ED, but prevented DOS from writing boot sectors, VTOC etc.

 

Then, using DiskRx, we can see here that every byte of every sector is $E5 (inverted to $1A on disk). Including the VTOC/Direcotry sectors like 362 that @cx2k pictured above, which are normally overwrtitten when the drive returns control to DOS after the physical format completes.

 

I formatted and checked both a single and enhanced density disk, the fill bytes are the same:

 

While patching firmware for my AT88-S1, I found that the v1.2 ROM formatted SD with a $1A fill byte (which would invert to $E5 on disk) and DD with fill bytes $9249 ($6DB6 on disk). This suggests that $E5 was the recommended fill byte for FM, but they still forgot to invert it, and didn't use a different one for enhanced/medium/dual density's MFM.

https://atariage.com/forums/topic/304384-percom-at-88-doubler-rom/page/2/?tab=comments#comment-4503979

 

I wonder if the firmware was initially written by Tandon, they would have more likely used a "standard" fill byte that all other OEM's were using, without previous knowledge of 810 operations. Could also have also just been an uninformed "new" programmer I guess. It's a significant enough and interesting quirk, vs the only officially documented reason of a "different error status than the 810"...  I wonder what was incrementally fixed in revision "F".

 

Attached are the two ATR's for anyone interested...

1050-revE-ED.atr 1050-revE-SD.atr

[sup8pdct]

7 hours ago, ijor said:

1050 rom Rev E, at least the one Nezgar posted above, follows in some sense the concept, and fills sectors with $E5 when formatting the disk. But the strange thing is that, because the data is written inverted, the actual sector written on the disk surface is $1A, and not $E5. I guess this was a bug, let alone that the whole concept applies to MFM only, not to single density.

 

 

The atari 810 uses a FDC 1771. This is an inverted data bus chip.

All FDC sector Data written and read isn't inverted in firmware to allow for this so all data written on sector is inverted.

Doesn't affect things normally except when reading the disks on another system.

The 1050 uses a 2793 (some have a 2797) which is a non inverted data bus chip. The 1050 firmware has to invert all sector data to maintain 810 compatibility.

So, not a bug. Done to maintain compatibility.

 

james

 

[+Nezgar]

11 minutes ago, sup8pdct said:

The 1050 firmware has to invert all sector data to maintain 810 compatibility.

So, not a bug. Done to maintain compatibility.

Hehe..... and to add to the fun - the ill-fated 815 wrote double density disks NOT inverted, yet all 3rd party implementations of true double density assumed inverting double density sectors in the spirit of the 810... so the few disks out there that are intended for the 815 can indeed be read on any other true double density drive (US Doubler, Happy, Percom etc) but you have to invert the data of every sector manually to recover a usable disk image.

 

Case in point: My suggestion of XORing every sector with FF was used to archive the original "Atari Accountant" disks without having an actual 815 drive: ?

https://www.atariwiki.org/wiki/Wiki.jsp?page=Read%2C write or convert from an Atari 815 Double Disk Drive

 

I guess since we now know that Charles Marslett wrote the PERCOM firmware after which all future double-density capable drives were modeled after, he must not have had an 815, or a disk formatted in an 815 to know that Atari didn't invert double density. Not a big deal though since so few 815's ever actually made it into the world, and even if it had higher production, the fact the 815 couldn't read single density would have killed interest in it quickly anyway...

[ijor]

4 hours ago, sup8pdct said:

The 1050 uses a 2793 (some have a 2797) which is a non inverted data bus chip. The 1050 firmware has to invert all sector data to maintain 810 compatibility.

So, not a bug. Done to maintain compatibility.

 

I think you don't understand the point. Or might be I didn't expressed myself correctly.

 

There is no compatibility issue here by inverting, or by not inverting, the data. We are talking about data written during format time only, not about how data is written normally with a write sector command. You could write $E5 to the disk surface, which could then read as $1A. Or you can do as this firmware does, write $1A to the disk surface that the computer reads as $E5. Either way it wouldn't be fully compatible with the 810 because the 810 "blanks" sectors at format time by writing $FF to the disk surface. So it is not that they inverted the $E5 for compatibility with the 810, because writing $1A to the disk surface doesn't make it more compatible with the 810 in anyway.

 

My reasoning that this could be a bug, is because if you want to follow the theory I described in my previous message, then you want to write the $E5 value to the disk surface. What matter here, for this purpose, is what you write to the disk surface, not what the computer reads. So if that was indeed the purpose of writing $E5, then by writing $1A to the disks surface instead, they committed a bug.

 

But I don't know, may be he idea of filling the sector with $E5 at format time was just to imitate what other platforms performed. Not sure that would make much sense, but who knows.

[+kheller2]

As a side comment, untreated to "E" but about those 1050's with the transistors mounted with wires, it makes me think the original heat sink was going to be reversed, and then someone noticed the floppy mech didn't fit.

[archeocomp]

Maybe it did fit reversed, but it was way to small (low profile) for all that heat, so they made it bigger and reversed.

Edited August 24, 2021 by archeocomp

[phaeron]

Did a full diff of rev.E against rev.H/J this evening and found a few more differences. The full list:

• Rev. E has additional code to avoid the final double half step and back on track 39.
• Rev. E clears the sector buffer after every command. This makes the status command's reuse of $00-03 moot and is way worse both from a compatibility and timing perspective.
• Rev. E checks AUX1/2 for a valid sector number even on commands that don't take sector numbers, e.g. Status $FFFF returns NAK.
• Rev. E does not check for sector 0. Do not recommend trying this on actual hardware, from the emulation trace it looks like it tries to seek to track 56!
• Rev. E lacks a RIOT timer check in the receive loop to time out when waiting too long for a start bit, unlike Rev. H+ which do time out.
• Rev. E doesn't set the side compare bit on read/write sector operations ($80/$A0). Kind of weird that they changed it to enable the side compare after Rev. E and then turned it back off again in Rev. L with the FDC compatibility change.
• Rev. E looks like it has an extra decrement of the retry counter on write operations.
• Rev. E is missing an extra check in the format routine that Rev. H+ has to test for Not Ready before Write Protect, but oddly the extra BMI seems to be a no-op. Later on in the same routine, a BIT instruction to test BSY was also changed to AND with again seemingly no effect.
• Rev. E fills formatted sectors with $1A on disk instead of $FF, as noted above.

• Rev. H+ adds code to the double-density write test to store FDC status and reset the stack, which presumably was to increase the reliability of stress tests.

• Rev. E has a BRK in the mainline path of the double-density write test, which would halt the test with a flashing light. Don't know this code well enough to determine the conditions.