Date   : Mon, 11 Sep 2006 18:21:47 +0100
From   : Sprow <info@...>
Subject: Bugs in ArmCoPro OS

In article <060909235504@...>,
   Jonathan Graham Harston <jgh@...> wrote:
> >Message-ID: <4e638bc4e7info@...>
>  
> Sprow <info@...> wrote:
> > > A%=&04, Y%=&00: Disk space used
> > > A%=&05, Y%=&00: Disk free space
> > 
> > OS_Args SWI definition. The free/used space ones do sound sensible, as
> > referenced in <62D9C34C5CEE40979EF87D1FB18A016.MAI@...>
>  
> You've found a reference? All I can find are my own hand-typed API
> references from about 1987.

Sorry no - the reference was to the recent thread "*INFO" where a disc
used/free space call from day 1 would have been handy.

> > > > Your function args0 is naughty:
>  
> The newly uploaded version of FSTest now uses:
>  
> DEFFNargs0(A%,Y%,ptr%):IF?(TOP-3)=0:E%=Y%:Y%=0
> IFPAGE<&8000:X%=&70:!X%=ptr%:=(USR&FFDA)AND&FF
> SYS"OS_Args",A%,Y%,ptr% TO A%,Y%,ptr%:!X%=ptr%:=A%
>  
> Admittedly, it's sort-of broken as it has external side effects,
> but it's written specifically for the test program which needs to
> collect both !X% and A%.

Better, but where is X% defined for the > &8000 case? I was thinking more:

  DEFFNargs0(A%,Y%,ptr%,buf%):IF?(TOP-3)=0:E%=Y%:Y%=0
  IFPAGE<&8000:X%=&70:!&70=ptr%:A%=(USR&FFDA)AND&FF:!buf%=!&70:=A%
  SYS"OS_Args",A%,Y%,ptr% TO A%,Y%,ptr%:!buf%=ptr%:=A%

where the extra parameter buf% is some arbitrary spare DIMmed block. This
allows the function to return 2 values.

> > On those grounds I've adjusted the logic so R2 is always updated based on
> > the result from the host, but only update R0 when R0=0 and R1=0 on entry 
> > per the SWI definition.
>
> I can't think of any time I've needed to read the libfs number,
> but I do have programs that rely on other calls returning values
> in A.
>  
> HADFS returns the version number with OSARGS &FD, and HUtils and
> HEdit have code along the lines of:
>  
> dv%=2:IFFNhadfs_ver>42 THEN dv%=3

Why don't you return the version number in the block? That gives you 4 bytes
to play with, so you could even return some other related capability flags.

> HEdit looks@... &FE and if the return<>&FE uses that as the
> drive number to start editing.
> [...] IF A%=3 THEN set extent in a different manner
> [...] IF A%=5 THEN read free space in a different manner

We can do example table tennis for weeks I'm sure, but given the varying
documentation (Electron AUG, AUG, Master Reference manuals) and varying
implementation as you detailed in <060909095502@...>, and
that when the API slate was wiped clean OS_Args was defined as preserving R0
that's what makes most sense for the ARM Coprocessor. 

You'd have a much harder job changing all the places in the world where R0
is relied on after a SWI. 

> I also know of quite a few programs (eg, TreeCopy, CopyFiles,
> MultiCopy, etc.) that do things like:
>  
> X%?0=ch%:X%!1=data%:X%!5=num%:A%=2:A%=USR(OSGBPB)AND&FF
> IFA%=2:REPEAT:BPUT#ch%,?data%:data%=data%+1:num%=num-1:UN.num%<1

Ah, well there you should be looking at the carry flag, that always works:

  X%?0=ch%:X%!1=data%:X%!5=num%:A%=2:C%=1:C%=USR(OSGBPB)AND&1000000
  IFC%<>0:REPEAT:BPUT#ch%,?data%:data%=data%+1:num%=num-1:UN.num%<1

note that I set C on calling, since the cassette filing system on the BBC B
returns using just an RTS from GBPB. They corrected it by the Master to
return C=1.

I can't find anything on paper to suggest GBPB corrupts A, so those programs
must run slowly using BGET!
Sprow.