Disc Error 20/21/23 and SATA->IDE support

[sirbod]

I've been looking at these issues on a RiscPC and have now tested dozens of SD/CF/SATA devices on the native IDE with stock ADFS in RISC OS 3.70.

Disc Error 20 appears to be a timing issue, which can be resolved with a patch. This is going to go into RISC OS 5 soon, so should resolve the issue going forward. For legacy OS a small ADFS patcher can be provided for loading early in the !Boot sequence.

Disc Error 21 is reproducible with SATA, but appears to be a side effect...see below. I've not produced it on any othe devices I've tested.

Disc Error 23 is remaining elusive, I've yet to get a device to trigger it, so have done no diagnosis. At the London Show the Iyonix did show it once on power up, but the machine is now dead so no testing there. Power cycling the machine resolved it, so it does sound timing related. If you have a device that reliably produces this error, please contact me.

SATA->IDE is a different issue. On power up, the IDE controller gets in a state initialising any SATA drive - as evident by the activity light being constantly on. Resetting the controller gets the drive working again and sending an Identify to the drive gets the correct response, however the MSB (top 8 bits of the 16 bit data transfer) is blank, so only half the data is transferred...every other byte is rubbish to be exact.

Without a logic analyser, it's impossible to tell if the MSB is on the bus, but my guess is that it will be as SATA appears to only support 16 bit transfers. All the SATA drives I've tested respond with Aborted if I attempt to force 8bit transfers and checking the drive spec sheets confirms this.

The ADFS data transfer code can be ruled out, as it correctly reads words from the IDE data port and writes them to memory, so the issue is possibly lower in the chain. One possibility is incorrect assertion of the -IOCS16 line as this does come into play when DMA isn't being used. IOMD doesn't support IDE DMA, so I can't test that, but this may explain why some SATA->IDE work on the Iyonix.

Fix Disc Error 20 and 23 on ADFS 2.67 / RISC OS 3.11 (abridged version for quick testing)

Code: Select all

*BASIC
*RMFaster ADFS
SYS "OS_Module",18,"ADFS" TO ,,,A%
A%?&24AC=1
A%!&2560=&E3A01801

Fix Disc Error 20 and 23 on A3020, A4000, A5000 - use ADFS268 attached below in preference to this

Code: Select all

REM Live patch ADFS pre RiscPC for Disc Error 20 / 23
REM -------
REM Increases DRQ timeout (Disc Error 20 fix)
REM Caps large transfers to 1 sector (Disc Error 23 fix)

*RMKill ADFS
*RMReinit ADFS
*RMFaster ADFS
DIM temp% 16
P%=temp%
[OPT 2
MOV R1,#700
MOV R1,#65536
MOV R9,#&FF
]
C%=!temp%
D%=temp%!4
E%=temp%!8

SYS "OS_Module",18,"ADFS" TO ,,,adfs%
S%=!(adfs%-4)

FOR L%=0 TO S% STEP 4
  Z%=adfs%!L%
  IF Z%=C% THEN
    adfs%!L%=D%
    PRINT "DRQ timeout increased ("+STR$~L%+")"
  ENDIF
  IF Z%=E% THEN
    adfs%?L%=1
    PRINT "Transfers capped to 1 sector ("+STR$~L%+")"
  ENDIF
NEXT

REM Remove next line to save the patched ADFS Module to RAM::0
END
OSCLI "SAVE ram::0.$.ADFS "+STR$~adfs%+"+"+STR$~S%
*SetType ram::0.$.ADFS Module

Fix Disc Error 20 on A7000, RiscPC

Code: Select all

REM Live patch ADFS RiscPC for Disc Error 20
REM -------
REM Increases DRQ timeout (Disc Error 20 fix)

*RMKill ADFS
*RMReinit ADFS
*RMFaster ADFS
DIM temp% 16
P%=temp%
[OPT 2
MOV R1,#700
MOV R1,#65536
]
C%=!temp%
D%=temp%!4

SYS "OS_Module",18,"ADFS" TO ,,,adfs%
S%=!(adfs%-4)

FOR L%=0 TO S% STEP 4
  IF adfs%!L%=C% THEN
    adfs%!L%=D%
    PRINT "DRQ timeout increased ("+STR$~L%+")"
  ENDIF
NEXT

REM Remove next line to save the patched ADFS Module to RAM::0
END
OSCLI "SAVE ram::0.$.ADFS "+STR$~adfs%+"+"+STR$~S%
*SetType ram::0.$.ADFS Module

[sirbod]

Given the technical nature of folk around here, my post on ROOL, which I repost below, might spark someones interest to test the theory if they have the necessary skills:

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 would 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.

[sirbod]

I've managed to reproduce Disc Error 23 on an A5000 with a CF.

The error occurs when transferring more than 1024 bytes at a time, so is almost certainly a bug in ADFS. By capping transfers to 1024 bytes, I've successfully managed to format the CF without issue.

Unless anyone has seen this error on a RiscPC, I believe its only affecting pre RISC OS 3.50 based machines.

[danielj]

Excellent. Is this unrelated to broken directory then, or inter-related?

d.

[sirbod]

Excellent. Is this unrelated to broken directory then, or inter-related?

Hard to say unless I can see what’s happening.

A broken directory is usually triggered by a failed write, so you’d see a Disc Error 20 first. If not that, then a read of the catalogue that’s failing, but that should trigger a Disc Error 23.

Of course, my testing has now ground to a screeching halt as my A5000 has decided to fail during POST before initialising VIDC ... just as I’m about to test a patch!

[davidb]

I've managed to reproduce Disc Error 23 on an A5000 with a CF.

The error occurs when transferring more than 1024 bytes at a time, so is almost certainly a bug in ADFS. By capping transfers to 1024 bytes, I've successfully managed to format the CF without issue.

Unless anyone has seen this error on a RiscPC, I believe its only affecting pre RISC OS 3.50 based machines.

This probably isn't helpful but your report triggered vague memories of some advice I read about setting ADFSBuffers to 0. A quick search reveals this advice from Chris's Acorns:

The first A5000 models (ALB10, ALB12, ALB14) were launched with RISC OS 3.00 but it had a serious bug in the ADFSBuffers code which caused disc corruption. if you are running RISC OS 3.00 you must set ADFSBuffers to 0 to avoid this fault. Acorn produced an bug fixed version RISC OS 3.10 which was used in subsequent A5000s.

So, possibly not a bug a RiscPC should have.

Edit: This advice, from the csa.* RISC OS FAQ might be relevant:

Under 3.5 the number of ADFSBuffers can be left at the OS's discretion and generally the OS chooses a number based on the amount of memory present in your RiscPC. Unfortunately this cannot be said of RISC OS 3.6, 3.7 or 3.5 using a softloaded copy of the 'extended' FileCore. When running under these conditions if you have a hard drive partition larger than 2 GB then the buffers must be configured off to allow the drive to work, however installing ROM Patch 3 from the Acorn ftp site will fix this bug with large hard discs.

[danielj]

Of course, my testing has now ground to a screeching halt as my A5000 has decided to fail during POST before initialising VIDC ... just as I’m about to test a patch!

ARgh! That's a nightmare

If you'd like me to test it on the A3010 I can. With regard to the broken directory, there are no disk errors at all, just a straight broken directory I can dump the SD card so we can see what happened if that's any use?

d.

[sirbod]

If you'd like me to test it on the A3010 I can.

It's an interactive thing...poke a byte in ADFS...see what happens...poke another byte...etc

With regard to the broken directory, there are no disk errors at all, just a straight broken directory I can dump the SD card so we can see what happened if that's any use?

What machine/OS and is it reproducible? If you can provide me with repro steps, I'll see if I can reproduce it to investigate.

[danielj]

It's my bodged A3010 (but would assume it'll be the same on any 3.1), with the SD-IDE adaptor linked above. Format the drive with hform - all looks fine. Try to open and instantly get "Broken Directory".

d.

[sirbod]

It's my bodged A3010 (but would assume it'll be the same on any 3.1), with the SD-IDE adaptor linked above. Format the drive with hform - all looks fine. Try to open and instantly get "Broken Directory".

It’s controller specific then as my A5000 has an FC1306T based SD adapter and doesn’t exhibit the issue.

What’s the chip on the adapter?

[danielj]

It's an FC1307A - most of the more recent ones use this, and they don't behave well... I'll test it with Wizzo a bit later.

[danielj]

OK - it's clearly an ADFS bug causing the broken directory issue, Wizzo IDEFS once loaded can see the drive (which was formatted under ADFS), and use it normally.

d.

[sirbod]

OK - it's clearly an ADFS bug causing the broken directory issue, Wizzo IDEFS once loaded can see the drive (which was formatted under ADFS), and use it normally.

d.

Read timing issue then, strange it doesn’t report a disc error, I’d expect to see 20 or 23.

Given up on the A5000, so will move on to breaking the A4000 tomorrow.

[danielj]

The problem with that is going to be "how do you load the patched ADFS" - if you get broken directory when you try and read the disk, even when fixed it's going to take a new set of ROMs to sort it out

d.

[ajw99uk]

The problem with that is going to be "how do you load the patched ADFS"
d.

Two stage boot, floppy then HD, like using the new filecore beta under 3.50.

[danielj]

Although in that case you may as well use Wizzo and gain the extra partitions. Removing the reliance on obsolete media is one of the bonuses of getting this worked out (at least for me). I guess it should be perfectly possible to burn some patched ROMs...

d.

[sirbod]

I guess it should be perfectly possible to burn some patched ROMs...

That was my thought. I purchased an EPROM programmer the other week with that in mind.

Roll on RISC OS 3.20

[sirbod]

Interim fixes for Disc Error 20 and 23 now in the OP, I've included an abridged version for RISC OS 3.11 if you want to test it without a floppy.

There's two patchers for Arc's and RISC PC, which will live patch ADFS. Uncomment the *END* if you want to save a copy to include in a Podule.

[danielj]

This won't have any effect on "broken directory" though?

d.

[sirbod]

This won't have any effect on "broken directory" though?

We’ll know once you’ve tested it.

[Phlamethrower]

For those not keeping track of the thread(s) on the ROOL forums, it's worth mentioning that the disc error 20 fix went into RISC OS 5 around a week ago, and there's a beta ROMPatch which will apply the same fix to RISC OS 3.5/3.6/3.7/3.71/4.02.

For Jon's Arc patcher, it's also worth bearing in mind that it won't play nice with the version of ADFSUtils that's in the 3.11 ROM. So unless you have a softloadable ADFSUtils (if such a thing was ever produced?) you may need to tweak your ADFSBuffers settings in a similar way as is required on RISC OS 3.10, in order to avoid floppy access problems.

[danielj]

What's the upshot of that?

The patch process won't work, or once patched it won't work without adjusting ADFSBuffers? I'm also not entirely clear on what I should be adjusting it to (I also thought there was something at some point about setting it to 0? Or was that with 3.5-3.6?)



(sorry for confusedness, I speak 8bit Acorn more fluently)

d.

[davidb]

Nice to see you posting on here, Jeffrey. Feel free to introduce yourself on the relevant forum unless you want to fly under the radar. No pressure.

[Phlamethrower]

What's the upshot of that?

The patch process won't work, or once patched it won't work without adjusting ADFSBuffers?

The disc error patch will work, but it will break the lazy way that Acorn patched the ADFSBuffers bug for RISC OS 3.11.

I'm also not entirely clear on what I should be adjusting it to (I also thought there was something at some point about setting it to 0? Or was that with 3.5-3.6?)

The c.s.a.* FAQ has a summary of the various bugs that tweaking ADFSBuffers will fix.

http://www.riscos.org/csafaq/part4.html#4_1

The bug that was in RISC OS 3.10, which could be cured by an ADFSUtils module, was "fixed" for RISC OS 3.11 by bundling the ADFSUtils module in the ROM image. But that ADFSUtils module will only work with the ROM-based ADFS, so doing *RMFaster ADFS, or loading a completely different ADFS, will prevent the fix from working (so you'll need a new ADFSUtils, or a version of ADFS which doesn't suffer from the bug).

For RISC OS 3.6/3.7, the beta ROOL ROMPatch I linked to above will fix both the ADFSBuffers bug and disc error 20.

[sirbod]

The disc error patch will work, but it will break the lazy way that Acorn patched the ADFSBuffers bug for RISC OS 3.11.

How is ADFSUtils patching ADFS? By intercepting ADFS calls, or mapping memory over it?

If it's the former, the patch should work. If it's the later, I just need to change the patch to copy ADFS from ROM into the RMA. Bare in mind this is an interim fix, whilst we work out a proper patch.

The bug that was in RISC OS 3.10, which could be cured by an ADFSUtils module, was "fixed" for RISC OS 3.11

Wasn't the bug in 3.0 and patched in 3.10?

[danielj]

OK - Patch works - no more Broken Directory!



d.

[sirbod]

OK - Patch works - no more Broken Directory!

Excellent news.

[Phlamethrower]

The disc error patch will work, but it will break the lazy way that Acorn patched the ADFSBuffers bug for RISC OS 3.11.

How is ADFSUtils patching ADFS? By intercepting ADFS calls, or mapping memory over it?

I haven't done a full disassembly yet, but it looks like it hangs off of the floppy IRQ vector and peeks & pokes ADFS's workspace. It also looks like it branches into the code for some things.

Remember that mapping memory over a ROM module is a physical impossibility with MEMC, since the ROM isn't in the MEMC logical addressing area.

Although I can't track down a softloadable version of ADFSUtils, it looks like one used to exist, judging by the construction of the code - it looks like all of the code addresses it branches to are held in a table at the end of the module. So as long as the offsets within ADFS remain the same it should be pretty trivial to produce a version of the module which can adapt to different ADFS base addresses.

The bug that was in RISC OS 3.10, which could be cured by an ADFSUtils module, was "fixed" for RISC OS 3.11

Wasn't the bug in 3.0 and patched in 3.10?

You're making the mistake of thinking there was only one bug! 3.0 had one bug (fixed in 3.10), 3.10 had another (which was then "fixed" in 3.11 by the addition of ADFSUtils - 3.10 and 3.11 appear to contain the same ADFS module, at least going by version number alone. A proper source code fix came later, in time for 3.19). Then 3.60/3.70 had a third bug (fixed in 3.71 or via ROMPatch)

[sirbod]

I haven't done a full disassembly yet, but it looks like it hangs off of the floppy IRQ vector and peeks & pokes ADFS's workspace. It also looks like it branches into the code for some things.

<snip>

Although I can't track down a softloadable version of ADFSUtils, it looks like one used to exist, judging by the construction of the code - it looks like all of the code addresses it branches to are held in a table at the end of the module. So as long as the offsets within ADFS remain the same it should be pretty trivial to produce a version of the module which can adapt to different ADFS base addresses.

Quick fix, RMFaster ADFSUtils and patch it along with ADFS. Shouldn't be too hard if it's using a table, I'll investigate over the weekend.

Can't help thinking the changes should be patched directly into ADFS though. Total botch job on Acorn's part adding a Module instead of fixing the original source

[danielj]

Can we not just use ADFS from 3.19 and patch that?

d.