Date : Thu, 07 Sep 2006 23:11:44 +0100
From : jgh@... (Jonathan Graham Harston)
Subject: Re: Bugs in ArmCoPro OS
>Message-ID: <4e624f8069info@...>
Sprow <info@...> wrote:
> Jonathan Graham Harston <jgh@...> 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
>
> > OSARGS
>
> > ====
> > 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.
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.
> > 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
>
> Where are all these documented?
A%=&01, Y%=&00: Command line pointer
Advanced User Guide p338
Advanced Disk User Guide, p142
Master Reference Manual, pH3-5
New Advanced User Guide, p252
Acorn Electron Advanced User Guide, p99
and others
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.
> > 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 ;)
On entry: A%=&80, X%=>data, Y%=handle
On exit: X%?0=handle in file server format
X%?1=file server station number
X%?2=file server network number
X%?3 b0: sequence number
b1: known to be a directory
b2: thought to be URD
b3: thought to be CSD
b4: thought to be LIB
b5: current context
b6: EOF, next BGET will give error
b7: writable
> > A%=&FF, Y%=&20, !X%=000000CE: Ensure file A%=&FF !X%=000000CE
> > prolly ok. FS should return A%=0
>
> No, A (or R0) should be preserved.
>
> > A%=&03, Y%=&20, !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.
Hmmm. Econet Advanced User Guide says:
A: in function &00: 0 or, if Y=0 on entry, fs number
in function &01: 0 or, if Y=0 on entry, undefined
in function &02: 0 or, if Y=0 on entry, indicates version
it also says:
...if pointer is moved past file end, file is extended with zeros,
and zero returned in A.
which contradicts what it says earlier.
However, collating various sources gives:
Returns A=&00 if PTR/EXT has been moved past the end of the file
Returns A<>&00 if PTR/EXT has not been moved past end of file
Also, cross-referencing with the SJ MDFS Manager's Guide:
A=&00 if operation completed, A preserved if unimplemented.
So:
> 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.
> 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. This
horrendous practice started in 1981 with:
REPEAT:INPUT "Filename: "f$:UNTIL LEN f$<8
What right is it of the front end program to decide that the
filing system should not be given filenames longer than seven
characters? Even on DFS you can legitimatly use 12 characters,
viz: ":0.$.FILENAM"
> 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.
No, you should never try to interpret what comes back. Just give
them straight back to the caller. Translating the Z80 code to ARM,
with reference to the PDP11 commentary (!) gives:
; ARGS R0,R1,R2 - Action,Handle,Data
STRM SP!,LINK ; Save return address
STRM SP!,{R0} ; Save R0 (Action)
MOV R0,#&0C
BL Tube_SendR2 ; Send Tube Command &0C - ARGS
MOV R0,R1
BL Tube_SendR2 ; Send handle
MOV R0,R2,LSR #24
BL Tube_SendR2 ; Send data b24-b31
MOV R0,R2,LSR #16
BL Tube_SendR2 ; Send data b16-b23
MOV R0,R2,LSR #8
BL Tube_SendR2 ; Send data b8-b15
MOV R0,R2
BL Tube_SendR2 ; Send data b0-b7
LDRM SP!,{R0} ; Get action back
BL Tube_SendR2_FF ; Send action
BL Tube_WaitR2 ; Get Action result (A register)
STRM SP!,{R0} ; Save it
BL Tube_WaitR2 ; Wait for data b24-b31
MOV R2,R0
BL Tube_WaitR2 ; Wait for data b16-b23
ORR R2,R0,R2,LSL #8
BL Tube_WaitR2 ; Wait for data b8-b15
ORR R2,R0,R2,LSL #8
BL Tube_WaitR2 ; Wait for data b0-b7
ORR R2,R0,R2,LSL #8
LDRM SP!,{R0} ; Get returned A back
LDRM SP!,{PC} ; Return
; Returns R0=returned Action, R1=preserved, R2=returned data
That is:
Send command, Action, Handle, data3, data2, data1, data0
Read Action, data3, data2, data1, data0
Return Action, Handle, data3, data2, data1, data0
without imposing any preconceptions on the values.
> So calls that write things via OS_Args return with everything preserved.
> Calls that read things only update R2 (R0 & R1 preserved).
You ("the programmer") have no knowledge of what call is going to
write something, and what is going to read something. Only the
system you ("the programmer") call knows that.
> Calls that read the FS id also update R0.
It's the responsibility of the filing system to preserve what it
should preserve.
--
J.G.Harston - jgh@... - mdfs.net/User/JGH
United Kingdom Tercentenary : 1707-2007 : http://yr300.org.uk