Exotic disk drives

[Sikor]

http://atariki.krap.pl/index.php/Akcesoria_i_rozszerzenia#Stacje_dysk.C3.B3w_i_rozszerzenia_do_nich

Polish, use google translate

[+bf2k+]

On 8/27/2019 at 5:47 PM, toddtmw said:

A friend had the dual Amdek 3" drive. That was pretty impressive BITD. Those seem to be pretty rare. I've only ever seen one on eBay.

I had one... it was really hard to find the 3" disks.  I used it on my early BBS.

[JR>]

On 8/27/2019 at 2:47 PM, toddtmw said:

A friend had the dual Amdek 3" drive. That was pretty impressive BITD. Those seem to be pretty rare. I've only ever seen one on eBay.

I've got one of these. Unfortunately it was partially re-cased in clear acrylic and converted to 3.5 inch SSDD mechs.  I need to pull that out and play with it one of these days.  Maybe at least upgrade it to DSDD mechs. Pretty sure the controller supports them.

[+Nezgar]

13 minutes ago, JR> said:

I've got one of these. Unfortunately it was partially re-cased in clear acrylic and converted to 3.5 inch SSDD mechs.  I need to pull that out and play with it one of these days.  Maybe at least upgrade it to DSDD mechs. Pretty sure the controller supports them.

Oooh... maybe you would be willing to dump the ROM's? This would be most interesting to get the likes of Phaeron to disassemble it and potentially add emulation support into Altirra... Maybe it's yet another drive that shares ROM code heritage with PERCOM drives...

[JR>]

Now why did I know you were going to ask that? ?

 

I located the controller board and snapped a couple picks of it.  Popped the EPROM and dumped it.  Dump looked good!  Then for some reason the Thumb drive was no longer being recognized on my old (no network) WIN 98 computer that houses the burner.  While troubleshooting that, the power switch on the old PC started acting up and it no longer powers up!  SIGH!  Too hot in the garage to mess with it further right now.  So in the mean time here are the pick of the controller board. Both photos were originally in the same orientation with the SIO connectors at the bottom.  I have no idea why both of them got randomly rotated when uploaded?

 

 

[+Nezgar]

34 minutes ago, JR> said:

I located the controller board and snapped a couple picks of it.  Popped the EPROM and dumped it.  Dump looked good!

Awesome @JR>! The EPROM is a 4KB 2732, do you recall when viewing the dump if only 2KB of it had data? (ie. 2nd half blank, or maybe repeated)

 

What we have here definitely looks like another PERCOM variant. Like the AT88-S1PD, Astra 1001 and also likely "The One" & 2001, it has a 6809 CPU and 6850 serial controller.

 

The Astra 1001 had a newer WD2795A Controller, this one has a 1797 controller. Ther percom "Doubler" board had a 1795, very similar - have to look up the difference.

 

So... This Amdex 3" drive used 80 tracks just like a 3.5" 720K disk?

 

34 minutes ago, JR> said:

Both photos were originally in the same orientation with the SIO connectors at the bottom.  I have no idea why both of them got randomly rotated when uploaded?

Digital cameras (and phones) only store rotation data as an attribute in the EXIF metadata of the jpeg for speed and/or limitations of embedded hardware. Some software, I guess these forums, don't pay attention to that attribute and just read with the rotation as it was from the camera.  You can usually solve this by re-saving it in an editing program.

[Kyle22]

19 hours ago, Sikor said:

http://atariki.krap.pl/index.php/Akcesoria_i_rozszerzenia#Stacje_dysk.C3.B3w_i_rozszerzenia_do_nich

Polish, use google translate

The XFD602 sure looks nice. Supports Synchromesh and Ultraspeed protocol.

:)

Are these available?

 

[JR>]

53 minutes ago, Nezgar said:

So... This Amdex 3" drive used 80 tracks just like a 3.5" 720K disk?

 

Digital cameras (and phones) only store rotation data as an attribute in the EXIF metadata of the jpeg for speed and/or limitations of embedded hardware. Some software, I guess these forums, don't pay attention to that attribute and just read with the rotation as it was from the camera.  You can usually solve this by re-saving it in an editing program.

Thanks for the tip on the pictures.  It's still not orienting them right after cropping and saving, so I just rotated them until they get re-rotated in to the correct orientation.

 

I think they were just standard 80 track drives....with the advantage that they could be flipped to use the other side.  I've got the manual around here somewhere too.  Hopefully I can locate that and scan it.  From what I remember you can control 4 drives in just about any combination of formats from SSSD 5.25 to DSDD 80 track.

 

As for the EPROM dump, all 4K was populated and I could see some recognizable text at the end, but it could well be 2K repeated, I hadn't looked at it that closely yet.

 

Edited September 8, 2019 by JR>
Added info about the ROM dump

[JR>]

2 hours ago, Nezgar said:

 

So... This Amdex 3" drive used 80 tracks just like a 3.5" 720K disk?

 

I guess the drives were just SSDD 40 track, but the controller was capable of 80 tracks. Perhaps 80 track 3" mechs were avialable too?

Good article here: https://www.atarimagazines.com/compute/issue46/040_1_REVIEWS_AMDC_3-Inch_Disk_Drives_For_Atari.php

[_The Doctor__]

xfd drives look like my cumulus corporation drives

[JR>]

Finally got to the ROM dump for the AMDEK 3 inch drive.  Appears to use the entire 4K.  VER. 1.1 from 10/27/83 according to text in the dump.

AMDEK.ROM

[+Nezgar]

Thanks @JR>! Interesting that it is 4K... the other PERCOM variants I've seen thus far are all 2K, or dumped as the same 2K repeated twice.. this one appears to be 4K of unique data...  I hope the extra code means it might have some extra functionality.. (Like the 1050 dual density support as mentioned in the manual)

 

Taking a quick look, first at 0x080D we see "AMDC  VER 1.1    1/30/84"

 

But then, what the... at 0x0E96 we see: "RBM 10/27/83  HI MOM!!!!" ?

 

Wonder if we can deduce who's initials those are...

 

Psst @phaeron ?

[phaeron]

Initial disassembly attached. It is not a Percom variant, it is a different 6809-based firmware and it is actually 4K.

 

Had to guess some things without a schematic or diagnostic disk to test against. There appears to be a watchdog timer wired to NMI in the AMDC similar to the Percom drive, but I had to guess its timeout and function. I also couldn't tell the function of $6000 bit 6, the read strobe at $0800, the frequency of the high-speed ACIA clock, or what is connected to 6809 IRQ. Have the firmware mostly working in emulation but need to do some cleanup.

 

The AMDC firmware is larger and has more features than the Percom/Astra firmwares, but the extra functionality is not that well written with either bugs or low-value commands that duplicated what Write PERCOM Block could already do. With the 6809 and 4K of firmware space, quite a bit of more standard and better functionality could have been added. The most mysterious thing is that quite a bit of the interesting functionality is locked behind a 9th switch ($1000 bit 4) which is presumably the internal jumper in the pictures above. This includes a number of diagnostic test modes and enhanced density support, which are selected via the density switches. The enhanced density support seems pretty incomplete as it only works if test mode is enabled, the density switches are set to a mix of SD and DD that does not trigger one of the diagnostic modes, and even then for some reason it sets the sector limit to 1024 sectors instead of 1040.

 

Double-sided operation is supported but is also somewhat broken. The firmware decodes side 2 forward instead of backwards like the ATR8000 -- it is incompatible with the XF551, which allocates side 2 backwards, and the Percom/Astra, which has an off-by-one bug for side 2. The worst problem is that the firmware resets the drive parameters to single sided whenever density detection occurs, which happens whenever sector 1 is read. This makes double-sided operation annoying with MyDOS and impossible with SpartaDOS X. The XF551 avoids this problem by defaulting to double-sided instead when detecting double density.

 

There are also high-speed read/write/sector commands. It looks like these were meant to be compatible with the Happy high-speed commands since they use the same lowercase r/w/p command bytes and protocol, where the command frame is always low speed and high-speed is engaged after the command ACK. The high-speed code uses an alternate ACIA clock in the hardware that is probably fixed for 38.4Kbaud operation. It doesn't seem to work, however, as the firmware immediately reverts the ACIA clock and clock divisor to low-speed immediately after queuing the last byte but before it or the previous byte has finished shifting. In fact, unlike POKEY, the ACIA doesn't even have a way to check for transmit complete. This causes the last two bytes from read sector to get trashed in emulation and I can't see how this would be different on the actual hardware.

 

There's no track buffering or high-speed interleave -- double-density uses the same 15:1 interleave as the XF551 for low speed -- but the firmware does support custom interleave patterns. Bizarrely, it uses the same $66 command ID as the US Doubler to set it, but takes a 26 byte buffer instead of a sector size buffer and requires a separate format command. This confuses the SpartaDOS X Formatter quite a bit and results in a nice raspberry when it tries to use the USD command.

 

Direct code execution is possible since there are read/write/execute memory commands. They are not enabled unless the test jumper is set. The drive has 1K of static memory and only uses half of it, so a decent bit of code can be run. The author of the firmware was definitely testing against some copy protected disks as the firmware has code to emulate the 810's FDC status code for deleted sectors.

 

Perhaps the final oddity of this drive firmware is yet another gratuitously different format timeout value of $78 returned by the Get Status command. As we've seen with AspeQt, it is possible to break formatting of other drives in the SIO chain by specifying too small values here, though $78 is probably still high enough.

 

amdek.s

[+Nezgar]

On 9/16/2019 at 2:14 AM, phaeron said:

Initial disassembly attached. It is not a Percom variant, it is a different 6809-based firmware and it is actually 4K.

Great read, thanks again for your expert analysis of the code! I'm impressed that this firmware is unique, and that it has so many features, but sad to see so many of them were half baked. It would be nice to start with a firmware such as this for a basis for fixing for better compatibility, and completing the functionality for the apparently "considered" features like UltraSpeed SIO. Seems so backwards now for things like density detection to be so manual. US Doubler & Happy figured it out automatically pretty reliably.

 

On 9/16/2019 at 2:14 AM, phaeron said:

The most mysterious thing is that quite a bit of the interesting functionality is locked behind a 9th switch ($1000 bit 4) which is presumably the internal jumper in the pictures above. This includes a number of diagnostic test modes and enhanced density support, which are selected via the density switches. The enhanced density support seems pretty incomplete as it only works if test mode is enabled, the density switches are set to a mix of SD and DD that does not trigger one of the diagnostic modes, and even then for some reason it sets the sector limit to 1024 sectors instead of 1040.

A review of the drive in "COMPUTE! ISSUE 46 / MARCH 1984 / PAGE 110" describes the function of the DIP switches, but it looks like you documented these better in your source.

• 1-4 Boot-up density selection
• 5&6 sets which of the 4 physical drives is the boot drive (D1?)
• 7 sets an external drive as boot drive
• 8 on=1050 compatible 'dual density' off=256 byte double density

I guess if they only had DOS 2.5 as an example, maybe they thought noone would need to use sectors 1024-1040... But that compute page references DOS 3.0 - Pretty sure DOS 3 could use those sectors... Does it actually FORMAT those last sectors? would the sectors on the resulting disk be accessible in a 1050?

 

LOL re the "Get easter egg command ($6D)" - sure I saw that text earlier in the binary, but that's funny that there's actually a command to request it. Actually, the Compute! article mentions a "Version" utility that "tells you the version number and date of the AMDC operating software which may help should you have a problem" - This must use the $56 command, but it looks like the $6D is identical in code and length other than the text string returned...

[phaeron]

21 hours ago, Nezgar said:

A review of the drive in "COMPUTE! ISSUE 46 / MARCH 1984 / PAGE 110" describes the function of the DIP switches, but it looks like you documented these better in your source.

• 1-4 Boot-up density selection
• 5&6 sets which of the 4 physical drives is the boot drive (D1?)
• 7 sets an external drive as boot drive
• 8 on=1050 compatible 'dual density' off=256 byte double density

I guess if they only had DOS 2.5 as an example, maybe they thought noone would need to use sectors 1024-1040... But that compute page references DOS 3.0 - Pretty sure DOS 3 could use those sectors... Does it actually FORMAT those last sectors? would the sectors on the resulting disk be accessible in a 1050?

I used that article as a reference, but some of the switch descriptions aren't quite right. Switches 5 and 6 don't set the boot drive, they set what logical drive the physical drives start at, e.g. starting at D1: or starting at D2:.

 

The switch 7 description is mostly correct but a bit misleading. What this switch does is determine whether the firmware assigns logical drive numbers to the internal drives first or the external drives first. Non-present drives are skipped, so if there is only one internal drive and it is mapped to D1:, the external drive is mapped to D2: and not D3:.

 

The switch 8 description does seem to be accurate, but it works in a strange way: it causes the firmware to inject Record Not Found errors into certain error handling paths. This appears to affect the density detection code to block double density, though I haven't figured out quite how. The drive should be formatting a full 1040 sectors for ED at least since the format code is based on physical track/sector and not logical sectors. Needless to say, it should have been possible to implement both ED and DD without needing this explicit switch.

 

Density detection is surprisingly tricky to do right, and it's interesting how many bugs there have been: XF551 not doing re-detection properly except with specific read patterns, ATR8000 only doing it once per drive, most drives failing to notice if the disk is changed during an active command (with the notable exception of the Indus GT due to hardware assist), Amdek dropping double-sided mode on detection, etc.

 

21 hours ago, Nezgar said:

LOL re the "Get easter egg command ($6D)" - sure I saw that text earlier in the binary, but that's funny that there's actually a command to request it. Actually, the Compute! article mentions a "Version" utility that "tells you the version number and date of the AMDC operating software which may help should you have a problem" - This must use the $56 command, but it looks like the $6D is identical in code and length other than the text string returned...

The command name is placeholder, obviously. It seemed better than "Get author name and message for Mom ($6D)".

 

I would love to get a copy of that operating software as it would validate the assumptions about the hardware design and probably reveal more of the unknowns. Sadly, we're already lucky enough that JR> was able to dump the ROM, being able to find an image floating around of software from a non-standard physical disk geometry is going to be a hugely long shot.

[+Nezgar]

1 hour ago, phaeron said:

I used that article as a reference, but some of the switch descriptions aren't quite right.

I guess it's understandable for the Compute! article to not be perfect, as it is second hand information. Your explanations make much more sense. It would also be nice to see what's written in the manual, if one exists. That the Compute! article mentions tools for Atari DOS, OSA+, DOS/XL, and that "Most of these utilities are quite complex and are intended for programmers" would support that a manual would have been necessary...

 

1 hour ago, phaeron said:

I would love to get a copy of that operating software

And if it's ever found, it would probably be on a 3" disk, just to make things even more difficult. I just learned that those "3 inch" disks are actually 3^1/8 inches by 3^15/16 inches.

 

And for those who haven't seen yet, Amdek AMDC-I/II disk emulation has been incorporated into Altirra 3.90-test11:

 

[+davidcalgary29]

It looks like California Access repackaged 8-bit storage units sold in the US for the Central European market. What was their business model?? Why the "CA" rebranding of the XC12? And wasn't the XC12 sold in Central Europe anyway? I've sure seen enough of them floating around on the auction sites...

[+MrFish]

On 9/7/2019 at 9:41 PM, JR> said:

I've got the manual around here somewhere too.  Hopefully I can locate that and scan it.

 

Ever have any luck coming up with the manual for your Amdek?

 

Edited November 8, 2020 by MrFish

[Sikor]

On 9/22/2019 at 12:18 AM, davidcalgary29 said:

What was their business model?? Why the "CA" rebranding of the XC12? And wasn't the XC12 sold in Central Europe anyway?

Yes, i bought my ATARI 65XE and ATARI XC12 in PEWEX, shop in Poland (1987 year).

LDW and its brand (CA) was made some peripherals on Atari licence in Tramiel time. Tramiel leave 8-bit busines, so Lucjan Daniel Wencel (LDW it's his name first letter) was product for example XCA12 first (from Atari spare) and after then rebranding it fo CA12. Anyway - XC12, XCA12 and CA12 is variants of Phonemark PM44 if I remember, very cheap alternative of casette recorder for Atari and Commodore...

SOme info (in Polish): http://atariki.krap.pl/index.php/XC12

Edited November 8, 2020 by Sikor
link added

[JR>]

10 hours ago, MrFish said:

 

Ever have any luck coming up with the manual for your Amdek?

 

Not yet, but it's finally cool enough to go rooting about in the garage...LOL

[+MrFish]

10 minutes ago, JR> said:

Not yet, but it's finally cool enough to go rooting about in the garage...LOL

Haha... ok, glad I alerted you in the appropriate season.

 

Thanks for the board pictures and ROM dump, btw.

 

[JR>]

On 11/8/2020 at 9:54 AM, MrFish said:

Haha... ok, glad I alerted you in the appropriate season.

 

Thanks for the board pictures and ROM dump, btw.

 

Well, so far rooting about has not yet yielded the manual.  Searching my email does reveal that I should have a photocopied manual somewhere. Apparently Rory McMahon was kind enough to send this to me way back in 2005.  We also discussed the disks.  He was going to check and see if he had them in with his boxed Amdek III, but it doesn't look like either of us ever followed up on that.

 

Back to rooting.....coming across all kinds of stuff I'd forgotten about!

[+MrFish]

1 hour ago, JR> said:

Well, so far rooting about has not yet yielded the manual.  Searching my email does reveal that I should have a photocopied manual somewhere. Apparently Rory McMahon was kind enough to send this to me way back in 2005.  We also discussed the disks.  He was going to check and see if he had them in with his boxed Amdek III, but it doesn't look like either of us ever followed up on that.

 

Back to rooting.....coming across all kinds of stuff I'd forgotten about!

 

Sounds like an interesting adventure. Thanks for taking the time to look into it.