Date   : Fri, 15 Sep 2006 09:12:10 +0100
From   : Sprow <info@...>
Subject: Re: Bugs in ArmCoPro OS

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

[zero page poking]

> > 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%

So it is, I didn't download the full program to see FNargs0 in context.

Sadly it still falls over on a Risc PC, this time because opening a filename
"*" fails as you might expect and so I get a "Channel" error equivalent,
then the error recovery doesn't reset B% so it goes round again then gets
stuck in an infinite loop of B% growing and "Subscript out of range". No
data aborts though!

> > > [...] 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 :(

Agreed there does seem to be considerable variability, thus making relying
on the return code rather pointless (unless you first read the FS number and
have some way of dealing with different FS implementations, though reading
the FS number was a bit broken in ARMTubeOS 0.25!).

I'd like to see some commercial code that does this.

> > 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. 

On that basis, if I'd used an x86 processor instead and ported DR DOS to the
board you'd expect me to corrupt AX when calling Int 0x21 to get the file
length? That would be a nightmare - I've have to patch or track down the
sources to any DOS utilities that I wanted to run and modify them to handle
corrupted AXs.

Put differently, if I wrote a C program for RISC OS and the compiler assumed
register N was preserved (ATPCS) but I corrupted register N because the BBC
Micro told me to, the program would quite quickly go wrong - or I'd need to
change the compiler calling standard somehow.

> > 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.

I'd beg to differ - your own documentation scribblings suggest return values
of A are so variable as not to be useful.

> > > 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.

I was hinting to use C to tell if the call was implemented, inspecting the
block to tell if anything actually happened is a wise addition. Though I
can't discount the comment in the MDFS user manual, it doesn't carry as much
weight given the numbers of MDFS units versus numbers of BBC Masters for
example.

> Is there a spare SetSomething call the ARMCoPro OS could provide
> to make this selectable?

Great - a compromise to stop my fingers getting sore. You can already do
this, just intercept the SWI vector, look at the SWI number and do whatever
you want with it (or for unknown SWIs the OS_ChangeEnvironment allows you to
trap it further down the food chain if you're an application). Contact me
off list if you need a hand with this.

There are other mechanisms and as I've just spotted your 6502 emulator
(cool!) in BASIC I think I've just got the missing piece of the jigsaw,
Sprow.