Date   : Fri, 15 Sep 2006 23:00:26 +0100 (BST)
From   : Greg Cook <debounce@...>
Subject: Re: Bugs in ArmCoPro OS

On Fri, 15 Sep 2006 09:12:10 +0100, Sprow <info@...> wrote:

> In article <060913155502@...>,
>    Jonathan Graham Harston <jgh@...> wrote:
[...]
> > 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.

I was going to argue that ArmTubeOS is not DR DOS or Risc OS, and so
that doesn't apply -- but if you can be sure you're on ArmTubeOS (and
thereby know there is an accumulator to test), you could use a spare
OSWORD call and install a wrapper on the Beeb to call OSARGS/GBPB and
return A.  If the program might be running on RISC OS then it must be
prepared not to have the 'accumulator' available, full stop.

If you're only testing that the calls are implemented, could you not
preset the control block, perform the relevant read command and test
whether the block has been updated? 

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

As the block seems to be the only thing that always gets returned, it's
the only trustworthy source.  In at least one DFS the return state of
the carry flag was undefined.

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

Presumably the intercepting code would have to source A itself?

Greg Cook
debounce@...
http://homepages.tesco.net/~rainstorm/



               
___________________________________________________________ 
Inbox full of spam? Get leading spam protection and 1GB storage with All
New Yahoo! Mail. http://uk.docs.yahoo.com/nowyoucan.html