Date   : Sat, 20 Aug 2011 23:21:06 GMT
From   : jgh@... (J.G.Harston)
Subject: Tube ROM

Rob wrote:
> (Interesting though just occurred to me - was there anything other
> than BBC Micros that acted as a tube /host/ ? )

A PC with the Springboard interface, though (I haven't looked
through the code in enough detail) I think it doesn't use the Tube
API.

Also, SerialHost on a PC or RISC OS will host a SerilTube client
(http://mdfs.net/tube/Serial)

I believe that Acorn's VAX HostFS server used the Tube API, but not
the Tube hardware, in a similar manner to SerialTube.

Rob wrote:
> It would be interesting to hang a 6502 second processor off a ZX
> spectrum, say. Somebody was writing a Beeb emulator on one; that could
> act as host... :-)

With SerialTube I've run a ZXSpectrum as a client off a BBC host ;)
I did my initial work on porting BBC BASIC to the Spectrum with it.

Rick Murray wrote:
> > It would be interesting to hang a 6502 second processor off a ZX
> > spectrum, say.
> ;-) I think the problems are twofold. Firstly, the Tube chip is a
> dedicated specific purpose chip. That's not to say they could not be

The Tube system consists of three things, the concept, the API and
the hardware.  You don't need a Tube chip to implement a Tube
interface, you can implement the API via different hardware. That
hardware can "look like" a Tube chip, or it can look different.
SerialTube implements the Tube API via a single byte-wide channel
compared to the hardware Tube using four byte-wide channels.

> We'd have more luck bunging a Tube chip onto something like a PC or a
> RISC OS machine, something with enough processing grunt to fake the API

Initial builds of RISC OS had modules to allow it to act as both a
Tube client and a Tube host! With a SerialTube client running a BBC
and SerialTube host running on a PC I've had a BBC running as a
Tube client. It's slightly weird typing on a PC keyboard, seeing
output on a PC display, and knowing that the enviroment you're
working in is a BBC. Type *CAT and the disk drive over there
(points) lights up! ;)

Alan Williams wrote:
> The point about RAM being faster than ROM is certainly an important one.

The main reason clients copy themselves from ROM into RAM is that
it is easier to then page RAM into the whole memory map than to
have 2K of RAM lost underneath a ROM. It also allows the client to
use areas of memory within the "ROM" area as workspace.

-- 
J.G.Harston - jgh@...      - mdfs.net/jgh
NOBODY expects the MACRO ARGUMENT INQUISITION!  Our chief weapon is
unexpected addressing modes... unexpected addressing modes and local
branches out of range.  Our two weapons are unexpected addressing modes and
local branches out of range and quoted argument lists.  Our *three* weapons
are unexpected addressing modes, local branches out of range, quoted
argument lists, and an almost fanatical devotion to the pope.  *Amongst* our
weapons are such elements as unexpected addressing modes, local branches out
of range... I'll come in again.