HForm "Cannot read disc identity"

Whilst trying various drives on a RiscPC today in an attempt to reproduce Disc Error 23, I’m finding HForm can’t identify most of the discs.

Does an uncompressed version of HForm exist, so I can take a look at this issue as well?

The source is here, although it looks like it’s designed to be run through the C preprocessor, so will need some finagling if you’re planning on running it (or you could probably grab an intermediate copy of the file from a Disc build environment)

Thanks.

I appears HForm fails to find some discs when it does the ADFS_IDEUserOp to identify the drive because WinIdeCommandDisc doesn’t attempt the command if the disc is saying its busy.

I believe the drive is showing as busy because FileCore/ADFS are trying to identify the disc from booting as the drive light is on constantly from boot. Should HForm not attempt to reset the drive if its busy, before attempting to send an identify command to it?

Resetting the drive if it’s busy could be dangerous – doesn’t ADFS/FileCore do some stuff in the background?

Does *Dismount fix it? If so, HForm could dismount the drive before it tries issuing the command (it looks like PROCProbeDriveDetails, which makes the ADFS_IDEUserOp call, already contains a *Dismount at the end, so adding an extra one at the start shouldn’t hurt)

A Dismount before the ADFS_IDEUserOp does something as there’s now a timeout instead of instant failure.

EDIT: On further investigation the DISMOUNT just timesout waiting for the drive to become ready, so doesn’t help.

After a lot more testing with SATA drives, if I reset the controller first via ADFS_IDEUserOp 1 it does return valid data however every other byte is 0. So for example where the model is SSDSA2UP020G3H what’s returned is .S.S.2.P.2.G.H. I’ve tried three SATA→IDE converters and they’re all the same.

Any ideas what could cause that? Does PIO support 8 and 16bit transfer modes and it needs forcing to 8/16bit?

SATA is natively 16bit, so if ADFS is doing 8bit transfers then that will definitely cause problems.

I’ve just tried setting feature set 1, which should force 8 bit if the drive supports it. All the drives responded with an error, so it certainly looks like SATA (or my test sample at least) only support 16 bit transfers.

Does the RiscPC support 16 bit transfer and can ADFS be modified to switch to it?

EDIT: ADFS appears to already be doing 16bit transfer so where is the MSB disappearing?

where is the MSB disappearing?

After some basic diagnosis with a volt meter on the IDE cable and visual inspection of the SATA adapter boards today, I think I have an idea about why the MSB is missing. None of the SATA adapters control the -IOCS16 line, so they’re really designed for DMA transfer only where the line is ignored. RiscPC doesn’t support DMA, only PIO, so it’s expecting -IOCS16 to be pulled low if 16bit data is presented on the bus.

There appears to be a mismatch however between the motherboard chipset and ADFS, as the chip does appear to support 8 bit transfers, but the ADFS code only supports 16 bit transfers. So, the drive/adapter are performing 16 bit transfers, the chipset 8 bit transfers and ADFS 16 bit transfers, so the MSB gets lost at the chipset.

This can only be resolved with a hardware solution, one option is to use an adapter that does control -IOCS16. I’ve looked at dozens on eBay today and even though they say they support PIO, none of them visually appear to control -IOCS16, the pin appears to have no connection.

Adapter boards could probably be modified to control the line, with a transistor or a 74 series but that’s not really a workable solution except for the hobbyist.

A more drastic option is to modify the RiscPC motherboard, by removing the pull up resistor on -IOCS16 and grounding it instead to force 16 bit transfers. Alternatively, modify an IDE cable to do the pull down.

A better solution might be to design an intermediary board that pulls -IOCS16 low when data is present on the bus, which should work for all adapters across the varying machines that support PIO.

This is all just a theory mind you, something that would need testing by someone more electronically minded than myself.

EDIT: -IOCS16 was removed in ATA-3 and as a result, IDE controllers no longer control the line or even have it connected. All the CF specs I’ve looked at do control the line, so most CF’s will work on a RiscPC. SD and SATA adapters are however very likely to be missing the MSB during data transfers without -IOCS16 being pulled low because the IDE controller on the RiscPC will perform an 8bit transfer.

-IOCS16 was removed in ATA-3 and as a result, IDE controllers no longer control the line or even have it connected.

Nice sleuthing, again!

Although modifying the motherboard is one option, I expect that suppliers like CJE would be more interested in modifications they can make to IDE cables or SATA/SD adapter boards. After all, they need a solution which they can easily convince users to go for.

Personally I wouldn’t modify the motherboard. A modified IDE cable is probably the cheapest option for home brew, but my preference would be an in-line board that plugs into the motherboard IDE socket so you can use stock IDE cables. Not as cheap, but a more future proof solution I think.

Made a bit of progress today, in that I managed to format and use an SSD on a RiscPC via a SATA→IDE adapter. There’s possibly changes required to ADFS though as pulling -IOCS16 low isn’t enough to get it working, I also had to reset the controller and manually issue an Identify command to it before it responded correctly.

The drive light still stays on constantly though, so there’s another issue that needs investigating. It may be this that’s causing ADFS to fail to ID the drive without the controller reset.

While looking up ADFSBuffers issues I found a reference to this newsgroup thread, which covers similar research into IOCS16 issues on the RiscPC (n.b. I haven’t read through it all to see if there’s anything useful you don’t already know)

https://groups.google.com/forum/#!topic/comp.sys.acorn.hardware/4M8i-cIhMoU

And they were so close to a fix back in 2006! Thanks for the link.

Probably explains why certain drives behaved better than others – certain drives had on board controllers that drove the pin or pulled it one direction for a consistent behaviour.

Hi, I found this old thread when googling why my Tanscend PATA SSD is loosing MSB when connected to my old 386 while it works on a bit newer systems. Now I know the problem is in IOCS16# that is not connected on the SSD side. My ISA IDE controller directly route this pin (32) to the same ISA bus signal (D2). How did you solved IOCS16# generation? I just tried a quick diode hack from CS1#, CS0# but it didn’t work. I seems I need to decode also A2:0 signals to generate IOCS16# ONLY when data register is accessed. Am I right? Does anybody succeed with some HW solution?

[…] my old 386 […] to the same ISA bus signal […]

You may have more luck asking this question on a forum that deals with old PCs.

IOCS16# that is not connected on the SSD side.

As far as I’m aware, IOCS16 only applies to ATA-1. Which is why your old PC has it, but a newer device doesn’t.

Hi, I found this old thread when googling why my Tanscend PATA SSD is loosing MSB when connected to my old 386 while it works on a bit newer systems. Now I know the problem is in IOCS16# that is not connected on the SSD side. My ISA IDE controller directly route this pin (32) to the same ISA bus signal (D2). How did you solved IOCS16# generation? I just tried a quick diode hack from CS1#, CS0# but it didn’t work. I seems I need to decode also A2:0 signals to generate IOCS16# ONLY when data register is accessed. Am I right? Does anybody succeed with some HW solution?

In my solution in that newsgroup thread, the suggestion on the Risc PC was to pull IOCS16# low with a resistor, forcing the bus to always be driven in 16 bit mode. I think somebody tested that and it worked.

But the Risc PC doesn’t have an ISA bus, so IOCS16# is purely for the IDE interface, and it was fine to pull it low because there was nothing other than the IDE bus buffer listening for it, and it was fine to do 16 bits at all times. On a PC the signal is used by other ISA cards and if you forced them all into 16 bit mode it probably wouldn’t boot. If you asserted IOCS16# during a control register word-read, it’s possible 16 bits would get written into the target CPU register/memory/etc not 8 bits, which would be wrong.

One other aspect is DMA (which the RiscPC IDE interface doesn’t do). However, according to Intel (PDF page 35) IOCS16# is ignored during DMA transfers, so that’s OK.

So I guess you do need to do a decode so that it’s driven only when the data register is read or written to: IOCS16# = CS0# + A0 + A1 + A2 (ie make IOCS16# low if they’re all low)

Edit: I think you could do this with 4 diodes and a resistor (let’s say 100K). Pull IOCS16# low with the resistor. Then take a diode from it to each of the four signals, cathode pointing towards IOCS16#. Any signal going high will pull IOCS16# high. Better to use schottky diodes but I think regular silicon diodes would probably work (assuming V_IH of the input < 4.3V)

There are an increasing number of disc which wont work with the old PIO modes the motherboard IDE interface is limited. I would recommend getting hold of a 3rd Party IDE controller podule which can do DMA (of which there are a several different modules). Although note that if using a Kinetic card, DMA is disabled, and these boards work even less well with PIO than the motherboard, so wont be able to handle this disc.

Hi,
I succeed to make a simple IOCS16# decoder using 2 log. gates IOs> 7432 and 7403 (simple grounding of IOCS16# is no go as only data register requires 16-bit access and other regs. needs 8-bit). Now the SSD is identified properly and works fine on that ancient 386 with XTIDE BIOS. I plan to make some compact PCB with SMD parts that could be “glued” to old controller. Here are some photo and schematic diagram of decoder:

http://www.ebastlirna.cz/modules.php?name=Forums&file=viewtopic&p=1255069&highlight=#1255069

Thak you for your support.

Well done, that’s good to hear! One thing that would be nice, if making a PCB, would be to throw on a SATA to PATA converter chip (eg the JM20330) and then you could use a SATA drive rather than an expensive or obsolete PATA one. Although I have no experience whether SATA drives would throw up other troublesome issues with ancient device drivers like ADFS or your XTIDE BIOS.

For anyone else, when looking at http://www.ebastlirna.cz/modules.php?name=Forums&file=viewtopic&p=1255069&highlight=#1255069

have the register table on the website wrong, that the polarity of CS0# and CS1# is reversed,

I think that’s the significance of the /CS0 and /CS1 as opposed to CS0 and CS1 as in normal circumstances the / would actually be a line above the CS0 (or CS1)

/CS0 or CS0# or CS0 with an overline all mean ‘active low’, in other words the signal is in the active state when it is at zero volts. That is indeed the case when you want to access the data register, you want /CS0 and the address bits all being zero. The table looks fine to me.

(It is not supposed to be the case that /CS0 and /CS1 are activated at the same time, so I don’t think you strictly need to check CS1/ with this logic. But doesn’t really hurt to do so)

hi, the 2nd table in my post is correct but before when started messing with it I looked at this:
http://www.ebastlirna.cz/modules/Forums/files/ideregs_866.png
where someone reversed polarity or rather swapped CS0 and CS1 columns. It wasted me some hour of scoping to find out, it’s not much clear when looking at waveforms because there was permanent data traffic generated by host even in idle when I didn’t accessed the disk.

Making an ISA-SATA controller with a socket for XTIDE BIOS would be a nice project, maybe… Currently I think a cheap AliExpress SATA-IDE converter will works too with this IOCS16 circuit so no big problem…