Date   : Sat, 09 Sep 2006 08:25:33 +0100
From   : Sprow <info@...>
Subject: Re: Bugs in ArmCoPro OS

In article <060907235513@...>,
   Jonathan Graham Harston <jgh@...> wrote:
> >Message-ID: <4e624f8069info@...>

[OS_Arg return values]

> > > A%=&FD, Y%=&00 FD
> > > A%=&FE, Y%=&00 Last drive
> > 
> > Where are these documented?
>  
> The test lists starts at &FD to start one before the listed calls,
> and ends at &06 to end one after the listed calls.

Ah right. I'm easily confused.
  
> A%=&FE, Y%=&00: Read last drive used. Watford DFS User Guide,
> HADFS Reference Guide. I had only ever seen this implemented in
> Watford DFS prior to implementing it in HADFS.

I see, section 4.05 of the manual. I suspect that was a Watford Electronics
dice rolling reason code assignment there.
 
> > > 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
> > 
> > Where are all these documented?
>
> A%=&02, Y%=&00: Version type
>   Master Operating System, p148
>   Econet Advanced User Guide, p41
>   "In NFS 2.34, [indicated by A=&01] pointer set to position
>   immediately after '*'. In version 3.40 and later [indicated by
>   A%<>&01], pointer set to first nonspace position after command
>   itself."
>  
> A%=&03, Y%=&00: libfs number
>   Master Operating System, p148
>   My copy of Master Reference Manual omits OSARGS calls >1
>  
> A%=&04, Y%=&00: Disk space used
>   I can't find the reference to hand, but I encountered it before
>   1989 as I decided it was sensible to implement it in HADFS.
>  
> A%=&05, Y%=&00: Disk free space
>   I can't find the reference to hand, but I encountered it before
>   1989 as I decided it was sensible to implement it in HADFS.

These 4 seem to have been erased from history by the time we get to the
OS_Args SWI definition. The free/used space ones do sound sensible, as
referenced in <62D9C34C5CEE40979EF87D1FB18A016.MAI@...>
recently it's a shame it wasn't implemented from day 1 instead of all these
oddball OSWords and peeking the disc catalogue.

Seems to have ended up in OS_FSControl (R0=49 or R0=55) now.
>  
> > > A%=&FE, Y%=&20, !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.
>  
> There's also ANFS's "read handle info", which I'd forgotten about,
> having not implemented in HADFS ;)

[snip much API movement]

> > No, A (or R0) should be preserved.
>  
> Should be: A preserved if call unimplemented, A not preserved if
> call implemented. Returning A=&00 is a subset of "not preserved".
>  
> But anyway, all this is what the *filing system* should implement.
> Any interface to the filing system, such as a TubeOS, should just
> values pass to and from the filing system unchanged.
>  
> > Your function args0 is naughty:
> > 
> >  DEFFNargs0(A%,Y%,ptr%):LOCAL 
> >  X%,E%:X%=&70:!X%=ptr%:IF?(TOP-3)=0:E%=Y%:Y%=0
> [snip]
> > 
> > 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...
>  
> It worked in 1991 when written! Yes, I should update that.
> Checking PAGE is an unsatisfactory method of deciding that "SYS"
> is available, but I couldn't work out anything else. Checking
> HOST=6 will not work, as HOST will be 6 if you are running non-ARM
> code on RISC OS, eg, 65Tube, Z80Tube, PDPTube, etc. etc. etc.

I wasn't so much worried about comparing PAGE with &8000 (the ARM
Coprocessor will have page > &8000 so passes your test), but that just after
the LOCAL statement there's an unconditional poke to &70 in zero page and
more just after the IF.

On my Risc PC that gives a data abort because zero page is read only from
user mode, quite rightly so. On the ARM coprocessor you're poking over the
FIQ handler.

You want something like
 
 DIM commonblock 4
 :
 rest of program
 :
 DEFFNargs0
 IF PAGE>&8000 THEN=FNargs0usingsys ELSE=FNargs0usingcall
 :
 DEFFNargs0usingsys
 SYS"OS_Args"...TOr0,,r2:!commonblock=r2
 =r0
 :
 DEFFNargs0usingcall
 !&70=...CALL
 !commonblock=!&70
 =A%

so that there's no use of zero page to return the second result from the
function

> > 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
>  
> All my docs says that A is preserved if the call is *not*
> implemented, and is changed if the call *is* implemented, but,
> again, that's what the filing system should be doing, not any
> interface code.
>  
> > 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:
>  
> Code that passes on calls to OSARGS (or anything else) should
> *NEVER* impose it's own beliefs of the underlying system's
> capabilities. It should just pass eveything on, and let the
> underlying system complain if it's outside it's abilities.

True, but in a number of places the API details have changed between the BBC
micro CALL address and the correspondingly named SWI (even if the reason
codes are the same). The ARM Tube OS has to do some degree of jiggling
around of entry parameters or return parameters to account for this,
admittedly in 80% of calls this not required.

For example OS_Word 14, the SWI definition has some subreason codes not
implemented on 8 bit machines, so I check this and postprocess the results.
I think this is far more useful than just blindly passing the call onto the
host - if I have a program written to run on an ARM machine I want as many
system calls fully available as possible so I don't have to make any
changes. Particularly in this example where the host doesn't complain if you
pass a bum reason code.

On those grounds I've adjusted the logic so R2 is always updated based on
the result from the host (leaving the choice of whether to corrupt it or not
up to the filing system), but only update R0 when R0=0 and R1=0 on entry per
the SWI definition. 

I think the loss of other esoteric reason codes R1=0 wont cause much loss of
sleep,
Sprow.