Date   : Fri, 13 Oct 2006 00:29:40
From   : jgh@... (Jonathan Graham Harston)
Subject: Re: Tube Documentation

"David Harper" <dl.harper@...> wrote:
> Jonathan Graham Harston wrote:
> > Errors and bugs in Tube documentation & code
> of glitches and variations from the standard. (OSBYTE and OSWORD are
> implemented in the 80186 ROM, accessed via Interrupts 4Bh and 4Ah. They can
> be called from within DOS-Plus, provided appropriate Tube claims and

No, the host (ie, the IO processor) does the claims and releases.

> The 80186 ROM implements OSBYTE using a simple Tube protocol:
>     for A<&80, the A and X values are written to the host, and the X value
>  read back;
>     for A>=&80, the A, X and Y values are written and the C, X and Y
>  values read back.
> There are four (and only four) exceptions to this:
>     if A=&9C, the protocol terminates after writing
>     if A=&82, &83 or &84, then no action is taken and the equivalent
>  of X=Y=0 is returned

Yes, that's the standard protocol, with the omission of dealing
with the fact that OSBYTE &8E has only a single ack. byte.

> > OSBYTE &8E, page 22
> If you were to try and do this from within DOS-Plus it will simply crash the
> system. If you do it from the 80186 monitor, then the results are
> unreliable.

Because the client OSBYTE code, as you described above, expects
three bytes to be returned whereas OSBYTE &8E only returns one
byte back. The client code will hang and/or crash waiting for the
nonexistant second return byte, like the Z80 client does.

> > All hosts treat &81 to &FF as being zero. The 6502 clients correctly send
>
> Not quite true. The 80186 ROM places extra code in the host to handle a
> special OSWORD &FA. Also, when the Master 512 is running DOS-Plus then it
> transfers some code into the host (from the file 6502.SYS on the boot disk)
> which looks after OSWORDs &FB to &FF. In practice, &FD and &FE are not used.

It is true. The fact that there is extra code copied into the host
does not change the OSWORD protocol or what the client and host
do. OSWORD &FA,&0D,&01,addr,off,seg,len,type sends 13 bytes to the
host and waits for one back.

The code copied into the host then does some cross-Tube data
transfer operations, in the same way that in the middle of an
OSFILE tranaction the host does some cross-Tube data transfers.

> > Data transfer Sync Bytes, p26, 27
> > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> > The documentation for Transfer Types 4, 6 and 7 shouldn't really say "Wait
> > for data in R4DATA, discard it", it should say "Wait for and remove
> > synchronising byte from R4DATA", as with transfers 1 to 3.
>
> Obviously if a byte is intended to be discarded, then it should not be
> called "data"

It's a synchronisation byte that is discarded once it has been
read. Either *all* the calls should say "wait for byte and discard
it", or *all* the calls should say "wait for synchronisation
byte".

> The 80186 ROM code is also rather untidy, but the DOS-Plus code is better,

The 80186 client code is the only one I don't have. I don't
suppose you could image your ROMs? The circuit diagram shows two
16K EPROMS, so it is likely that '*SAVE 80186 F0000000+8000' from
the client MOS '*' prompt would do it.

--
J.G.Harston - jgh@...                - mdfs.net/User/JGH
BBC BASIC for Windows and Internationalisation
  See http://mdfs.net/Software/BBCBasic/Windows/ProgTips