Date : Wed, 13 Sep 2006 14:47:45 +0100
From : jgh@... (Jonathan Graham Harston)
Subject: Re: Bugs in ArmCoPro OS
>Message-ID: <4e64ca06cfinfo@...>
Sprow <info@...> wrote:
> > > OS_Args SWI definition. The free/used space ones do sound sensible, as
> > You've found a reference? All I can find are my own hand-typed API
>
> Sorry no - the reference was to the recent thread "*INFO" where a disc
> used/free space call from day 1 would have been handy.
I wish I could find where I'd originally seen it. If I'd invented
it for HADFS, I'd have continued backwards from &FE as with OSARGS
&FD and OSFILE &FD.
> > 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:
X% is defined outside the the functions as per the "global X%
points to a global control block" convention.
> where the extra parameter buf% is some arbitrary spare DIMmed block. This
> allows the function to return 2 values.
The arbitary spare DIMmed block is pointed to by X%
> > 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.
It does, X%?2=version x of x.yz, X%?3=version yz of x.yz. It's
just different callers may find it easier to use the result in
different ways, eg:
LDA #&FD:LDX #&70:LDY #&00:JSR OSARGS
CMP #42:BCC early_version
> > 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
Most of my manuals are full of scribbled notes where I have
discovered that the real world doesn't conform to its
documentation. Flakey documentation got really annoying when I was
initially putting HADFS together :(
> 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.
It all depends on whether you are expecting OS_Args on an ARM
(co)processor to be a call to RISC OS or a call to a BBC Micro ;)
If I'm running code on a BBC Micro, regardless of what CPU I
happen to be running the code on, I would expect to be able to get
OSARGS's A result. Acorn's ARMCoPro uses the followng code:
.ArgsTube
STMDB R13!,{R0,R14} ; Save function on stack
MOV R0,#&0C ; =12
BL &00000CE4 ; Send command &0C - OSARGS
MOV R0,R1
BL &00000CE4 ; Send handle - OSARGS Y value
MOV R0,R2 ; Move data to R0
BL &00000CA4 ; Send 32-bit data
LDR R0,[R13],#0 ; Get function from stack
BL &00000CE4 ; Send function - OSARGS A value
BL &00000D24 ; Wait for returned result
STR R0,[R13],#0 ; Save it on stack
BL &00000D24 ; Wait for b24-b31 of returned data
MOV R2,R0,LSL #24 ;
BL &00000D24 ; Wait for b16-b23 of returned data
ORR R2,R2,R0,LSL #16
BL &00000D24 ; Wait for b8-b15 of returned data
ORR R2,R2,R0,LSL #8
BL &00000D24 ; Wait for b0-b7 of returned data
ORR R2,R2,R0
LDMIA R13!,{R0,PC}^ ; Get result from stack
; R0=result, R1=preserved, R2=data
Is there a spare SetSomething call the ARMCoPro OS could provide
to make this selectable?
> You'd have a much harder job changing all the places in the world where R0
> is relied on after a SWI. [to OS_Args]
Probably just as hard a job as changing all the places in the
world where A is relied on after a CALL to OSARGS.
> > 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:
The carry flag is very inconsistantly set correctly.
SJ Manual: "On some filing systems the carry flag is set on
reaching the end of the file/directory, this should not be relied
on. To write software that is compatible with all filing systems
the only method of finding whether all the files have been read is
to check the contents of (control block+4)."
and repeated with slight alteration to the wording on each page
describing the individual OSGBPB functions.
> 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.
SJ MDFS Guide, page 10-3:
DEFPROCwrite_string(handle%, $data%, offset%)
LOCAL A%,X%,Y%
blk%?0=handle%
blk%!1=data%
blk%!5=LEN$data%
blk%!9=offset%
X%=blk%
Y%=X% DIV 256:A%=1
IF (USR(osgbpb) AND &FF)<>0 THEN PROCsimulate_osgbpb(blk%)
ENDPROC
> I can't find anything on paper to suggest GBPB corrupts A, so those programs
> must run slowly using BGET!
SJ MDFS File Server Manager's Guide, page 10-2.
--
J.G.Harston - jgh@... - mdfs.net/User/JGH
BBC IDE Hard Drive Interface - http://mdfs.net/Info/Comp/BBC/IDE