Date : Fri, 13 Oct 2006 11:24:50 +0100
From : "David Harper" <dl.harper@...>
Subject: Re: Tube Documentation
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
Sorry, but I must correct this. When DOS-Plus is running there is a separate
Tube claim and release that has to be done from the client processor. (Claim
is done by XIOS call 81h and release by 82h.) A client program running
within DOS-Plus has to issue these calls before and after using the ROM
interrupts, or the machine will effectively crash because all screen updates
will stop. In practice, only programs written specifically for the Master
512 are ever going to use these (MS-DOS programs do not expect there to be a
Tube!), but DOS-Plus itself uses the claims at low level.
This is quite different from the standard Tube claim and release initiated
by the host. These may be important with some co-pros, but they are much
less significant for a Master 512 once DOS-Plus is up and running. They can
be pretty well ignored by programs running on the client side.
If any programs were written to run from the 80186 Monitor rather than
DOS-Plus, then they would not need to make these claims. Has anyone ever
written such a program?
>> 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.
Yes the OSWORD &FA protocol still stands. Regarding OSWORDs &FB to &FF this
is really a matter of terminology. They do not, in fact, use the standard
protocol at all for data, though of course it has to be there for the Tube
host code to work. What I mean is that no data is sent using the standard
protocol (both send and receive lengths are zero), but once the host code is
entered through USERV, parameters are passed using Tube Register 2, and then
data is transferred using the other registers (and not always in the
standard way - Register 1, for instance, normally reserved for OSWRCH is
used heavily by OSWORD &FF, but OSWRCH is never used when DOS-Plus is
running).
>> > 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.
I will send it direct when I get a chance. There is more than one version of
it, and I only have one of them at present, but I will send the one I have.
If I remember correctly from when I last examined it there is only 16K of
it, despite what the circuit diagram appears to show, but I will check. The
principal location for it is at 0F000:0000, but it is echoed in all
locations in the top 256K of the 1Mb memory map. One byte can be changed, as
it has been on mine, to cause it to occupy only the top 64K, allowing more
space in an extended RAM machine.
It is worth remembering that the client ROM code is only used for the
Monitor and the early stages of DOS-Plus start-up. Once DOS-Plus is active
it takes over the machine entirely and never uses the ROM again. (It doesn't
use much of the host MOS either.)
David Harper