ADFS_IDEUserOp with 48-bit LBA addressing

The following code on a RiscPC running RISC OS 5.29 (09-04-23 build to be exact) doesn’t do what I expect. It should read LBA 0 on the primary IDE drive, but instead returns Disc Error 22.

!&10000=0
!&10004=0
!&10008=0
?&10001=1   : REM Read 1 LBA
?&1000A=&20 : REM Read sectors
SYS "ADFS_IDEUserOp", %1000 OR (1<<24),,&10000,&10100,512 TO A%
PRINT A%

The documentation (which admittedly I updated based on the source code ) states that from ADFS 3.34, bit 3 of R0 indicates the parameter block is 11 bytes using 48-bit LBA addressing, but error 22 is something I’d expect when using a 7 byte parameter block and CHS addressing.

Did I document ADFS_IDEUserOp incorrectly?

Is it possible that there’s a difference in behaviour with ADFS4 compared to the older ADFS used on the RiscPC and Iyonix?

Is it possible that there’s a difference in behaviour with ADFS4 compared to the older ADFS

That was my initial thought, but then I figured peer review would pick up the fact that ADFS4 would introduce an ADFS that behaves differently.

If the documentation that accompanies the ADFS4 source is to be believed, I’m unsure how to determine if ADFS_IDEUserOp supports 48-bit LBA addressing…short of trying to read LBA 0 and seeing if it returns error 22.

I suspect the documentation accompanying ADFS4 is wrong, hence my initial question. I think that where is says from ADFS 3.34 it should read from ADFS 4.00, although even that is dangerous as we then have two versions of ADFS ticking up to a collision at some point in the future.

It would be okay if ADFS4 was backward compatible replacing earlier ADFS and in all builds, but it looks like it’s specific to one build or ATA implementation, but that doesn’t make any sense either as that’s what IDEFS is for…which again I would have expected to be been picked up by peer review.

Perhaps the author could review the documentation and correct or clarify please? In particular clarify how to determine if bit 3 of R0 is supported?

Hmm…

In the older ADFS it was simple, it just set the WinIDECmdFlag_48bit flag prior to doing an LBA command.

At a brief rummage, it appears that all ADFS4 does is to set the size of the parameter block to be 11, which flags to the ATA driver (SATADriver module, something entirely different!) that it’s a 48 bit LBA command.

Anyway, looks like the request is being signalled through.

As for how to tell if it is supported? Well, it seems that the older ADFS has this function that doesn’t appear to be called by anything (searching the entire ADFS code for the function name returns only the function itself):

WinIDESupports48bit   ROUT
;
; Tests whether a drive supports 48-bit addressing
;
; Entry:
;    WinIDEDriveNum = drive number
;
; Exit:
;    R0 undefined
;    EQ if supports 48-bit, NE otherwise

        Push    "LR"

        LDRB    LR,WinIDEDriveNum               ; get drive number
        ADR     R0,WinIDEDeviceNoIdFlags
        LDRB    R0,[LR,R0]                      ; check it had Identify info
        TEQ     R0,#0
        Pull    "PC",NE
        sbaddr  R0,WinIDEDeviceIds
        ADD     R0,R0,LR,LSL #9
        LDR     R0,[R0,#WinIDEIdCommandSets2]   ; check magic "01" marker in word
        AND     LR,R0,#&C000
        TEQ     LR,#&4000
        Pull    "PC",NE
        AND     LR,R0,#IICS2_48bit
        TEQ     LR,#IICS2_48bit
        Pull    "PC"

So older versions of ADFS do appear to support 48 bit LBA addressing, thus the 3.34 is correct.

It appears that there may be some sort of flag to determine if a drive supports LBA48. Take a look at the source for HForm, it says:

IF ((IDEid%!(83*2))AND&C400)=&4400 THEN IDEHasLBA48%=1 ELSE IDEHasLBA48%=0

Work out where it gets that information from and you’ll be able to determine if the drive supports it.

The ATA-6 spec says IDENTIFY DEVICE bit 10 word 83 indicates support for 48-bit addressing so that’ll be what HForm is looking at.

I believe I’ve figured it out. I’d mistakenly assumed that as bit 3 stipulates LBA addressing, it would set the LBA bit (bit 6) before passing the command on…in a similar way to what it does with the device bit (bit 4) from ADFS 4.00.

So…the correct code should probably be:

!&10000=0
!&10004=0
!&10008=0
?&10001=1   : REM Read 1 LBA
?&10009=1<<6: REM LBA addressing
?&1000A=&20 : REM Read sectors
SYS "ADFS_IDEUserOp", %1000 OR (1<<24),,&10000,&10100,512 TO A%
PRINT A%

I’ll add a note to the documentation to clarify.

I think that where is says from ADFS 3.34 it should read from ADFS 4.00

So older versions of ADFS do appear to support 48 bit LBA addressing, thus the 3.34 is correct.

Adding on to this, the mention of ADFS 3.34 does look reasonable at a glance, since that matches up with this commit that explicitly mentions adding support for 48-bit LBA.

It would be okay if ADFS4 was backward compatible replacing earlier ADFS and in all builds, but it looks like it’s specific to one build or ATA implementation, but that doesn’t make any sense either as that’s what IDEFS is for…which again I would have expected to be been picked up by peer review.

As I understand it, the intention is to eventually use ADFS4 on all platforms with ATA hard drives instead of just the Titanium and OMAP 5 ports, it’s just that no one’s gotten around to adding support for PATA controllers and floppy drives yet. At the very least, the description of the Filing system improvements (step 3) bounty states “We are not expecting to maintain the assembler version of ADFS any longer”, which suggests that keeping it around for the RiscPC and Iyonix is just a stopgap measure.