Detecting Various Types of Drives via SIO

[phaeron]

The AT88 is probably the most in need of an actual hardware test, because IIRC I didn't actually have a schematic for it and had to infer the memory map, and the canonical addresses for the RAM and the ROM are rather far away ($5000 vs $F800). The RFD's memory map is exactly decoded, but its RAM is much higher in the address space at $DC00, and while the SPD's firmware also accesses RAM at $5000, its hardware ignores A14/A15 and only decodes 16K of address space. Altirra currently assumes that the AT88 is more similar to the AT88-SPD and mirrors the address space the same way. PERCOM didn't seem to have as much of a focus as other disk drive vendors on optimizing their designs, between decoding about half a dozen more address lines than needed on the RFD and shipping a ~56% full 4K ROM on the SPD.

 

Incidentally... if Read Sector works for this, Write Sector offers an even more interesting possibility: overwriting the stack and executing custom code on the drive.

 

[+CharlieChaplin]

15 hours ago, Zolaerla said:

1440k? As in 1.44MB 3.5" disks w/ 512 byte sectors? Cause that'd be pretty neat using a floppy drive using still readily available media with a lot of space for the old Atari. So long as the Percom block data comes through correctly, it wouldn't even be too hard to support on the code side since it's just 2,880 sectors so far as SIO communication cares. Maybe I need to find one of these, not that I hate my SIO2PC, but it just sounds cool to play with.

 

 

Well, HDI uses only 256 byte sectors, therefore 5760 sectors (DS, DD, 80 tracks per diskside, 36 sectors per track) for 1440k.

 

[+DjayBee]

Did you find a method to distinguish a stock 810 from a stock 1050 except different status codes for some of the bad sectors?

[Zolaerla]

35 minutes ago, DjayBee said:

Did you find a method to distinguish a stock 810 from a stock 1050 except different status codes for some of the bad sectors?

 

Yes, but I hadn't explicitly coded for it. After determining the drive isn't one of the known drives, it would involve using command $23 which can be used to measure drive speed on the 1050 (reads sector 1 so it takes a moment) and will return which rev the drive is via command $24. If this command doesn't exist (it should get NAK'd pretty quickly), it's probably an 810 at that point. I do have a test already coded for specifically the 810 Rev E, because it returns FDC status of $00 instead of $FF. So if I added support for testing the 1050, I could added the 4 known revisions of the 1050 to the list, and assume what is left is the 810 or equivalent. I haven't found a way to tell a standard Rev B/C 810 from a Happy 810 before its Rev 7, or an 810 Archiver yet.

 

Edited May 10, 2023 by Zolaerla

[Zolaerla]

I tried to make a flow chart of the detection I came up with so far. I've never made one of these things before, so it's a bit of a mess, but shows most of the process without resorting to raw ASM.

EDIT: That "Get Status" in the beginning should be ($53)... blarg.

 

Edited May 10, 2023 by Zolaerla
fixed chart

[E474]

Hi @Zolaerla,

 

You could upload code to the 1050 Duplicator to get the ROM version (I can't remember if you can get the version via an SIO code, but you can definitely upload code via SIO which can inspect the ROM). See my 1050 Duplicator Repos at: https://github.com/e474 for examples of uploading code, etc. Actually, I can't remember if you can read the drive ROM directly, but also may be worth checking.

 

There's a Basic example program for changing settings on the 810 Archiver in Appendix D of the Archiver/Editor manual, and section 7.4 of the manual says you can upload code, though you'd need to disassemble the ROM, find the documentation for it, or disassemble the Archiver/Editor software to see if it includes that code (or similar checks) - unless someone has the info.

 

  I didn't see anything for the SuperArchiver or BitWriter - I think they can probably be identified via SIO codes though, or by uploading code, assuming someone knows how/can figure it out.

 

 Also you can tell the difference between a Happy and a Lazer (or similar clone) by looking at the Command Table (Lazer is missing one command). I don't know if you can finger print Happy Rev.1 and Rev.2 by comparing command tables either (code for loading Command tables is in my Dump1050 repo), and the jump vectors for each command, but you can always upload code that will checksum the ROM (and also check the amount of onboard RAM).

 

  Hope this helps!

[Zolaerla]

19 minutes ago, E474 said:

Hi @Zolaerla,

 

  Hope this helps!

 

Thank you for the info!

 

I'll have to check out the Duplicator stuff some time if I feel the need to distinguish between its revs.

 

The 810 Archiver sounds like its maybe doable, but will be a bit of work. It has a lot of custom commands that I haven't fully researched yet which likely will help figure it out, and might require the full disassembly like you're talking about. Just hopefully it'll be something short and easy to test.

 

I already can fingerprint the 1050 Duplicator (not different revs though), Happy 1050 Rev 1, and Happy 1050 Rev 2. The Happy Rev 2 supports US Doubler speed, and the Happy Rev 1 does not, so it's pretty easy to tell them apart.

 

I don't know much about SuperArchiver, BitWriter, or Lazer drives... or the HDI or Amdek AMDC or TOMS Turbo Drive for that matter. I added BitWriter and Lazer to my list of "need to find info/firmware" drives, so thanks! I do have a list with a huge number of obscure drives as well, but detecting everything requires having something to test with, so I guess if anybody has any of these drives, I'll have to make a test SD .atr file to pass around. The only drives I've been able to test are those that are emulated, except I have my own 1050 I need to probably buy some disks for (I use SIO2USB instead of physical disks).

[E474]

Hi @Zolaerla,

 

On 5/11/2023 at 12:12 AM, Zolaerla said:

 

Thank you for the info!

 

I don't know much about SuperArchiver, BitWriter, or Lazer drives... or the HDI or Amdek AMDC or TOMS Turbo Drive for that matter. I added BitWriter and Lazer to my list of "need to find info/firmware" drives, so thanks! I do have a list with a huge number of obscure drives as well, but detecting everything requires having something to test with, so I guess if anybody has any of these drives, I'll have to make a test SD .atr file to pass around. The only drives I've been able to test are those that are emulated, except I have my own 1050 I need to probably buy some disks for (I use SIO2USB instead of physical disks).

 

   I have some of those drives BitWriter, Lazer, etc., so give me a shout if you want to remotely test code on them. Only drawback is that I am usually quite busy, so there might be a bit of a lag!

 

   Hope this helps.

[Zolaerla]

6 hours ago, E474 said:

Hi @Zolaerla,

 

 

   I have some of those drives BitWriter, Lazer, etc., so give me a shout if you want to remotely test code on them. Only drawback is that I am usually quite busy, so there might be a bit of a lag!

 

   Hope this helps.

 

My data tester only works on D1 right now. I will have to make a more refined version specifically for testing drives, or you could just make a generic boot disk to run it on each drive individually. Let me know if I need to make a new .atr for that.

 

Anyways, it's part of my OS test from last year (the drive detection is disabled in this version, everything shows up as "Unknown SD drive", in case one of the tests clashes with the new drives), so the easy way is to reuse what I already have, so there are lots of incomplete tests on this disk that have nothing to do with the drives.

 

With the attached .atr, after the OS loads and you get to the test menu, press 7 for Drive I/O Tests, then 1 for Test Various Commands. I need a screen shot or the text of the output (or error data if it fails) from each of the tests: SIO Status Test, US Doubler Get Speed Test, Happy Test, Percom Read, Percom Write Absurd and Read, Percom Write FFs and Read, Percom Write 00s and Read. The way the drives respond to these (or error) has so far given me enough to distinguish almost every drive.

 

Do note, the Percom bizarre writes may cause the drive to become inoperable until the drive is reset (such as the Percom drives themselves) because one of the bytes is whether the drive is present and some drives take a 0 here to literally to mean to stop being present! These drives, if you start the test a second time, fail on everything.

 

No rush or anything, just when you have a moment to test out the drives. Thank you!

QuickOSTest.atr

Edited May 19, 2023 by Zolaerla
clarification

[E474]

Hi @Zolaerla,

 

   I just downloaded the ATR, and booted it up in the atari800 emulator (under Debian), and it gave me an error screen saying "Your system is not supported by QuickOS! Currently, only NTSC is supported." I'm assuming this will also be the case with my real 800XLs as I only have PAL systems. Haven't hooked anything up yet, but this might be the first stumbling block

[TGB1718]

Tried in Altirra NTSC, says it finds D1: Type Unknown SD Drive

although it's an emulated 1050 drive.

 

But later tests for USD show:-

Received Speed Data:

POKEY Divisor $0A

 

Last ACK: $41

Last Complete $43

 

It does not work if set to PAL, says it's an unsupported OS.

[drac030]

Under emulator, when it stops and displays the message that it only can work in NTSC, hit F8, then type this into the console:

 

r p.z 0

g

 

It will run then

 

Also, it cannot be booted as an ATR from a HDD:

 

There is also a minor typo in this message, it says "SOIAux2" which probably should be "SIOAux2".

 

[Zolaerla]

20 hours ago, E474 said:

Hi @Zolaerla,

 

   I just downloaded the ATR, and booted it up in the atari800 emulator (under Debian), and it gave me an error screen saying "Your system is not supported by QuickOS! Currently, only NTSC is supported." I'm assuming this will also be the case with my real 800XLs as I only have PAL systems. Haven't hooked anything up yet, but this might be the first stumbling block

I later added PAL support... I'll have to make a new disk. Sorry about that!

[Zolaerla]

10 hours ago, TGB1718 said:

Tried in Altirra NTSC, says it finds D1: Type Unknown SD Drive

although it's an emulated 1050 drive.

 

But later tests for USD show:-

Received Speed Data:

POKEY Divisor $0A

 

Last ACK: $41

Last Complete $43

 

It does not work if set to PAL, says it's an unsupported OS.

 

Ok, guys, I said this was an old version of my OS and tester and it specifically disabled the detection so it wouldn't give a false positive and then run really badly because it's trying to give a non-Happy drive WARP load commands. I had added PAL support so long ago, I forgot this was older than that. I can upload the up-to-date version, this was just my test version.

[Zolaerla]

Ok, I have re-assembled the test with the latest OS, instead of an older one. There are now two separate disks: one with full detection (to see it detect the drives according to the flow chart, minus a standard Atari 1050 since I haven't added the code for that yet), and one without the full detection for use with testing drives that are not supported yet. FullDetect.atr will attempt to detect and use the drive's full speed capabilities. NoDetect.atr does not do the detection at all, and would be used to test a drive in the Drive I/O tests without any drive-specific code or speed ups.

 

I have not done anything yet to support HDDs. If it is using 256 or 512 BPS, that is not enabled on this test disk. I have no idea how a boot disk even runs from a hard drive, so once the OS replaces the ROM (after the initial QuickOS test screen finishes and you press a key), it is probably failing trying to load from D1 as if it was a standard 128 BPS floppy.

 

Oh, and I did fix the SOIAux2 typo to SIOAux2. Thanks! How the heck did I not notice that?

FullDetect.atr NoDetect.atr

Edited May 20, 2023 by Zolaerla
oops, forgot the files!

[flashjazzcat]

15 hours ago, Zolaerla said:

I have not done anything yet to support HDDs. If it is using 256 or 512 BPS, that is not enabled on this test disk.

I think Konrad is referring to the fact the ATR crashes when booted via disk image support on a PBI host adapter. I would assume Konrad is using the IDE Plus 2.0 adapter, but in any case, attempting to boot the disk image here using U1MB/SIDE3 results in the software hitting a BRK instruction at $A0A1 when returning from code pointed to by JVECK ($028C), then crashing at $EA32 when returning from the IRQ service routine executed as a result of said BRK instruction.

 

Although I haven't established the reason for the crash, a common reason for such issues is that PBI-based ATR transfers are generally much faster than SIO transfers, so the setting up of interrupt handlers, etc, can encounter issues if it relies on arbitrary SIO timings.

[Zolaerla]

7 hours ago, flashjazzcat said:

I think Konrad is referring to the fact the ATR crashes when booted via disk image support on a PBI host adapter. I would assume Konrad is using the IDE Plus 2.0 adapter, but in any case, attempting to boot the disk image here using U1MB/SIDE3 results in the software hitting a BRK instruction at $A0A1 when returning from code pointed to by JVECK ($028C), then crashing at $EA32 when returning from the IRQ service routine executed as a result of said BRK instruction.

 

Although I haven't established the reason for the crash, a common reason for such issues is that PBI-based ATR transfers are generally much faster than SIO transfers, so the setting up of interrupt handlers, etc, can encounter issues if it relies on arbitrary SIO timings.

 

I have no clue what JVECK is, or why it would be in the middle of part of my program (which loads at $0200), but this is a complete OS-replacement that treats all 62KB available as valid memory, and accesses the SIO directly. If PBI does not function like a standard SIO device, or it tries to modify part of the available memory arbitrarily, then this absolutely will not work. I'm not trying to test hard drives right now, just floppy drives, so I haven't even done any research into how these function.

 

The SIO routines in the OS can handle all the way down to divisor $00 with its custom VBI handler, so the speed is not a concern. Everything loads very fast with an SIO2PC or in Altirra, for example

Edited May 21, 2023 by Zolaerla

[flashjazzcat]

12 minutes ago, Zolaerla said:

If PBI does not function like a standard SIO device, or it tries to modify part of the available memory arbitrarily, then this absolutely will not work.

If the boot loader is calling DSKINV (which it appears to do), there's no reason why it shouldn't work, since the low-level IO is completely abstracted from the OS SIO entry points. You shouldn't really have to worry about what hardware is hosting the ATR; it should 'just work'.

[Zolaerla]

2 minutes ago, flashjazzcat said:

If the boot loader is calling DSKINV (which it appears to do), there's no reason why it shouldn't work, since the low-level IO is completely abstracted from the OS SIO entry points. You shouldn't really have to worry about what hardware is hosting the ATR; it should 'just work'.

 

The only time it loads from the built-in Atari OS is when the first screen is loading, to load the new replacement OS from the disk. Then the Atari OS is completely replaced. Just my code, the hardware, and the 6502. Nothing else. DSKINV no longer exists then, because the Atari OS no longer exists.

[flashjazzcat]

1 minute ago, Zolaerla said:

 

The only time it loads from the built-in Atari OS is when the first screen is loading, to load the new replacement OS from the disk. Then the Atari OS is completely replaced. Just my code, the hardware, and the 6502. Nothing else. DSKINV no longer exists then, because the Atari OS no longer exists.

My apologies. It actually loads perfectly well once I remember to enable the PBI HDD.  I've been poorly this week and lost a lot of sleep.

 

The loader was installing its own RAM-based OS (in the absence of PBI BIOS support), so no wonder things weren't working. Sorry about that.

[E474]

Hi @Zolaerla,

 

   I managed to start testing. Only managed 1 drive so far, it's a Happy clone I got second hand, I have included a picture of the PCB in case that helps. 

 

   I didn't have much luck with FullDetect, though I tried it with 2 floppies in case it was a bad disk (but I don't think it was).

 

   NoDetect printed a lot of data.

 

   See pictures in this post and Next one(s).

 

FullDetect testing:

[E474]

NoDetect testing (1/2):

 

 

[E474]

NoDetect testing (2/2):

 

Btw, being able to log this info to a file, and upload that would be a bit easier.

 

Not sure if you want to look at why FullDetect failed before I try any other drives?

 

Hope this helps!

[Zolaerla]

Lots of error code $92 which is a framing error, generally from the POKEY timer and the drive timer being out of sync. That is totally not what I would expect to see in any of this, with the full detect version or no-detect version. Because doing the 0'd out PERCOM is failing, the detector treats this as a Tygrys instead of Happy drive, though I may have to limit that further since Tygrys will return an 'E' for complete, not fail out due to framing problems. The final NAK on Write Percom Block is also confusing, considering it hasn't been sent the weird PERCOM block to complain about it yet. I have these files set to abort very quickly (only 5 retries I think at full speed, then 5 again at low speed), and wonder if that might be a factor as well. Have you used HISIO or other high speed loaders with this drive without a problem?

 

Considering that things are acting weird only after the Happy commands are sent (during OS load in the first, it's how it detects Happy ... and after testing for Happy support in the full detect list), I wonder if perhaps it is expecting data to be passed differently at that point, such as through the Happy-style warp commands, instead of the US Doubler-style speed ups. If it was expecting that, this would explain all the framing issues... though I don't know why it would unless the drive software assumes that if you tried to enable the Happy write buffer, you'd then immediately use Warp communication... or something. I am just pretty confused about that one.

 

What kind of drive is this? The status is returning a $08 for the first byte and $9B for the second byte, which I could use to try to make a new detection path specific for this drive type since no other drive I've seen does that. With the framing issues, it's likely that what is being sent to it is causing it to run in an unexpected way. I just tried running things through Altirra on PAL since I have no real PAL Ataris, and couldn't cause similar problems with a Happy 1050 or a Tygrys 1050, so I'm not certain what's up with the framing issues.

 

I haven't written support for DOS files yet, so there is no way currently to save to a file. It could save to some select sectors on the disk, but I doubt that'd be very helpful unless it's easy to make XFD/ATR images on your end. It also might be unreliable, considering the types of errors this is getting with that drive.

 

Edit: If the SIO status flags are correct and not just arbitrary values, then it means the drive believes that three faults happened: data was lost on the disk, there were deleted sectors (not totally sure what that error code means), and that the disk is write protected. Maybe the "data lost" and "deleted sectors" bits are always clear on this drive, but it certainly is strange seeing them set when most other drives would return $FF instead of $9B for the FDC status flags, except the 810 rev E which returns $00 (everything's wrong!) and the Speedy 1050 which returns a similar $DB ("Lost Data", "Deleted Sector"). I check for $00 there to determine if it's the 810 Rev E, because not everything should be wrong unless something is really, seriously, messed up with the drive and disk... no idea how reliable $9B would be on this drive.

Edited May 28, 2023 by Zolaerla
Additional notes

[phaeron]

I can also reproduce this on my NTSC 800XL + Happy 1050 v2, it is detected as a Tygrys 1050 instead of a Happy 1050.

 

The problem appears to be with the PERCOM tests being run at high speed. The command frame is going out fine and getting ACKed:

 

However, the data frame is NAKed by the drive:

 

Based on what I'm seeing in the emulation trace, it looks like the high-speed SIO routines are sending the data frame too quickly after the ACK -- the computer is already sending the start bit by the time the drive is able to turn around and start its high-speed receive routine. Combination of micro-timing and analog signal effects probably explains the reliability issues as in emulation you get ideal clocks with perfect signal quality, vs. the slower rise times above.

 

The timing above is about 250us from end of ACK to start of data frame, which is too short and a SIO spec violation, which specifies 1.0-1.8ms. Things get fuzzy with high-speed SIO where there isn't a clear spec, but SpartaDOS X does sends with ACK-to-data delays in the ball park of 1.2-1.5ms.