<< Previous Message Main Index Next Message >>
<< Previous Message in Thread This Month Next Message in Thread >>
Date   : Fri, 13 Oct 2006 00:29:39
From   : jgh@... (Jonathan Graham Harston)
Subject: Re: Tube Documentation

>Message-ID: <4e7454f1e2info@...>

Sprow <info@...> wrote:
>    Jonathan Graham Harston <jgh@...> wrote:
> > noticed several documentary errors and code bugs.
>
> It is a terrible document, presumably because the number of people
> requesting it at the time was limited and they either worked at Acorn so
> could just ask other staff or figured it out for themselves.

I suspect that the documentation consisted of a BBC computer :)

> I think you've only scratched the surface here, as you soon find out all the
> ambiguities when actually implementing a coprocessor!

Indeed. When I was coding some coprocessor code back in 1990
(eek! sixteen years ago!) A particular gotcha is that 256-byte
write has a terminating ack, whereas 256-byte read does not.

> > OSBYTE &82
>   ^^^
>   &8E

silly typo *)

> > In fact, the both the 6502 TUBE v1.10 client and the 65C102 CoProcessor
> > v1.10 client:
> >       sends 1 and receives 24 bytes for OSWORD 14 and
> >       sends 32 and receives 0 bytes for OSWORD 15
>
> In 6502 Tube OS 1.20 this is s8/r25 for OSWORD 14
>   and s8/r8 for OSWORD 19

I've only ever found "TUBE 1.10" and "Co-Processor 1.10" in the wild and
the same from thorough combing of the wibble. It would be useful to add
version 1.20 to my collection.

> though of course because the ROM is downloaded into RAM the table is easily
> fixed in other versions with a bonus poke. Alternatively, always do

Which is exactly what the Z80 BASIC ROM does.

> buffer?24 after reading the clock? Yuk.

Because code can never guarrantee that it will be run on a BASIC
with TIME$, and the absense of TIME$ from the BASIC you are running
from does not imply that there is no code implementing OSWORD 14, I
use the following code:

    ?X%=0:A%:CALL&FFF1:IF ?X%=0:="" ELSE X%?24:=$X%

which explicitly puts a <cr>@... end.

> > Suggestion for reading memory limits with OSBYTE
>
> or did I miss something?

Just an idea for a useful extension. Would allow:

    membot%=FNfx(&83,0,0)+65536*FNfx(&82,0,0)
    memtop%=FNfx(&84,0,0)+65536*FNfx(&82,0,0)
    PRINT "User memory from &";~membot%;" to &";~memtop%

--
J.G.Harston - jgh@...                - mdfs.net/User/JGH
HADFS System Resources - http://mdfs.net/Software/HADFS
<< Previous Message Main Index Next Message >>
<< Previous Message in Thread This Month Next Message in Thread >>