[BBC-Micro] TUBE chip, accessing 'Parasite' side

Johan Heuseveldt johan at waarland.demon.nl
Mon Mar 3 23:17:45 GMT 2008


On Mon 03 Mar, David Harper wrote:
> Johan Heuseveldt wrote:
> > I'm sort of 'designing' a CoProcessor with a 6809 - 2 MHz version (68B09).
> >
> > I refound the schematics for the internal CoPro 80186, but couldn't find
> > The 80186 schematics are also vague (to me) in this respect.
> Don't follow the 80186 too exactly. It is somewhat non-standard. (For 
> instance, it uses a connection to DRQ to prompt for data transfers. The 
> standard is to use NMI, but the 80186 co-pro has to use NMI in a totally 
> different way to get over a problem with certain DOS programs.)

Don't worry! :-)
Yes, I saw the DRQ in use. I know not to take this literary.

As I'm not /too/ familiar with machine cycles of 80186 - or Z80 - and
internals, I can't interpret or understand not seeing a slow down in
hardware, while I /do/ expect something like that. Could be done by the
80186 internally, or is it still within speed limits?

BTW, I'm expecting problems with the 6809 NMIs: all registers are pushed onto
the stack, taken much more time than the 6502. I'll have to investigate this
further, but the design has a 3-pole jumper to connect TUBE NMIs to the FIRQ
input as an alternative to the NMI input.

> > The '004' document for the TUBE doesn't say anything how fast the parasite
> > side can/may be accessed. Even an pin description is without pin numbers.
> >
> > So, does anybody know how fast the parasite side can be accessed by the
> > processor?
> > I assume that at least for a 2 MHz processor, no slow-down is needed?
> The Tube interface is itself designated as 2MHz.

Yes, I suppose when using a 4 MHz Beeb, a slow down is defenitely needed! :-)

> There are specified minimum speeds that the parasite must be able to deliver 
> data to the host, or receive data from it.

That's the total processing time, the software. Not the actual hardware
access of the TUBE chip. That's what I'am after.

> (For speed, the host code reads  and writes without any checks of whether
> there is any data in the buffer of  not.

That's correct, I know. That's because these protocols are used for floppy
data and network data /through/ the TUBE, which in itself on the host/Beeb
side is also dealt with with NMIs, so can't wait for the TUBE! If the TUBE is
seen transparently, the TUBE must be abble to cope with the NMI speed of the
host/Beeb delivering/taken data from/for floppy or Econet.
(Hard disc is another matter)

> If the parasite is too slow, then data will be lost.) On the other  hand,
> it does not matter if the parasite is faster, since it reads and  writes
> under interrupt control (or DRQ for the 80186).

That's how I understand it too.

> If you have the 80186 schematic diagram, you should at least be able to work 
> out the pin numberings for the Master's internal Tube from it, as well as 
> the numberings on the Tube ULA chip.

Which was the easy part, as pin numbers were given there.

> The pin numberings for the external  Tube can be read off the schematic
> diagram of the Master provided at the  back of Watford Electronics'
> "Advanced Reference Manual for the BBC Master".

Or other schematics I have. 
Interesting is that the model B is unbuffered, the B+ is buffered but lacks
address lines A5 and A6. Only A0-2 are needed, but I'm wondering if at the
TUBE side the unused address lines should be terminated. Just for safety


Johan Heuseveldt <johan at waarland.demon.nl>
  aka  waarland

  The best place is a Riscy place
Never meddle in the affairs of Wizards:
it makes them soggy and hard to light.

More information about the bbc-micro mailing list