Date   : Wed, 06 Sep 2006 22:51:04 +0100
From   : Sprow <info@...>
Subject: Re: Bugs in ArmCoPro OS

Hi,
Wow - a comprehensive list, but I think it's rather more subtle that what I
would brand a "bug".

In article <060906002506@...>,
   Jonathan Graham Harston <jgh@...> wrote:
> Sprow <info@...> wrote:
> > > That will be the ARMTube OS, not LogCopy. There are some calls
> > > that are not correctly passed to the host. I found one or two
> > 
> > OSArgs 0,0 does get passed to the host correctly, but I've just spotted 

[small bug]

> Using http://mdfs.net/Software/HADFS/Progs/Extras/FSTest gives:
>  
> OSARGS                                                                     >
> ======                                             
> A%=FD, Y%=00 FD
> A%=FE, Y%=00 Last drive

Where are these documented?

> A%=00, Y%=00 Current FS

Agreed this is a bug, fixed in my local copy pending release.

> A%=01, Y%=00 Command line
> A%=02, Y%=00 Version type
> A%=03, Y%=00 libfs number 
> A%=04, Y%=00 Disk space used
> A%=05, Y%=00 Disk free space 
> A%=FD, Y%  FD 

Where are all these documented?

> A%=FE, Y% , !X%=000000CE: FE                 A%=FE !X%=000000CE
> prolly ok. FS should return A%=0 if this call does something.

I've got that as "read info on file handle", but see later.

> A%=FF, Y% , !X%=000000CE: Ensure file        A%=FF !X%=000000CE
> prolly ok. FS should return A%=0

No, A (or R0) should be preserved.
  
> A%=00, Y% , !X%=000000CE: Read PTR           A%=00 !X%=00000000
> prolly ok. FS should return A%=0

And it did!
  
> A%=01, Y% , !X%=000000CE: Write PTR          A%=01 !X%=000000CE
> prolly ok. FS should return A%=0 if PTR moved past EXT, but some FSs don't
> implement this.

See later logic.
  
> A%=02, Y% , !X%=000000CE: Read EXT           A%=02 !X%=000000CE
> prolly ok. FS should return A%=0.

No, A (or R0) should be preserved.

> A%=03, Y% , !X%=000000CE: Write EXT          A%=03 !X%=000000CE
> prolly ok. Should return A%=0 if EXT moved past current EXT, but some FSs
> don't implement this. FS should return A%=3 if not implemented, A%=0 or
> &FF if implemented.

No, A (or R0) should be preserved.

> A%=04, Y% , !X%=000000CE: Read allocated     A%=04 !X%=00000400
> prolly ok. FS should return A%=0 if implemented, A%=4 if not

No, A (or R0) should be preserved.

> A%=05, Y% , !X%=000000CE: Read EOF           A%=05 !X%=000000CE
> prolly ok. FS should return A%=0 if implemented, A%=5 if not

No, A (or R0) should be preserved.

> A%=06, Y% , !X%=000000CE: Ensure size        A%=06 !X%=000000CE
> prolly ok. FS should return A%=0 if implemented, A%=6 if not

No, A (or R0) should be preserved.

Your function args0 is naughty:

 DEFFNargs0(A%,Y%,ptr%):LOCAL X%,E%:X%=&70:!X%=ptr%:IF?(TOP-3)=0:E%=Y%:Y%=0
 IFPAGE<&8000:=(USR&FFDA)AND&FF
 IFA%=0:IFY%:!&70=PTR#Y%:=A%
 IFA%=1:PTR#Y%=!&70:=A%
 IFA%=2:!&70=EXT#Y%:=A%
 IFA%=3:EXT#Y%=!&70:=A%
 SYS"OS_Args",A%,Y%,ptr% TO A%,Y%,ptr%:!&70=ptr%:=A%
 =(USR&FFDA)AND&FF

because although you check PAGE and decide whether to use SYS"OS_Args" or
not, but both before the decision and after the decision you poke &70
anyway. Please don't go poking zero page on an ARM machine! That's part way
through the FIQ handler...

Infact RISC OS 4 and later write protects that in the pagetables.

A number of your observations suggest some modification of A to signify
extra results, but all the docs I have say that A (or R0) is preserved:

 PRM 2 page 46
 Advanced user guide page 338
 Master reference manual part H3-5

so I'm sticking with that.

There's also a whole raft of reason codes for Y=0 that I've never seen
before. The basic OS_Args logic I use goes along these lines:
 
 1. Pass R0 (the reason code), R1 (handle), R2 (value) to the host
    with no changes. R0 and R1 are byte values, R2 a word.
 2. On return, read the equivalent of !X (value).
 3. Read the returned value of A.
 4. Restore R0/R1/R2 from a stacked copy *before* the call
 5. Look at the calling reason code
    If it's 1, 3, 8, 255 do nothing otherwise move !X into R2 so it's
    returned to the caller with the updated value from the host.
 6. Look at the calling reason code again
    If it's 0 then move A into R0 so it's
    returned to the caller with the updated value from the host.

So calls that write things via OS_Args return with everything preserved.
Calls that read things only update R2 (R0 & R1 preserved).
Calls that read the FS id also update R0.

Cheers,
Sprow.