Date   : Sat, 01 Sep 2007 00:57:12 +0100
From   : splodge@... (Richard Gellman)
Subject: Watford Electronics Adder Eprom Programmer

Alex Taylor wrote:
> On 31 Aug 2007 01:02:01 +0100, Jonathan Graham Harston
> <jgh@...> wrote:
>
>   
>> It doesn't emulate an Arc doing anything. It emulates a 6502
>> second processor. What it is plugged into (virtual or otherwise)
>> is irrelevant.
>>     
>
> Now this is probably my ignorance caused by never having had the
> luxury of owning any kind of Tube hardware, but can you explain this
> further?
>
> As in, I was thinking of my description as being what I think of as
> the result of running the program. For example, if I start !65Tube on
> one of my A3000s, it's then as if I'd plugged a 6502 copro into that
> same A3000. Is this thinking wrong?
>   
Yes and no.

The TUBE is in defintion an abstract interface. At the electronic level 
its a bridge between two processing systems wherein data is passed 
between them via a series of registers accessible by both systems.

What is actually *on* each side, or an emulation of each side could 
really be anything. An emulation of a second processor system can simply 
respond to data being passed from the second processor by passing back 
the expected data. In this case there would be no I/O processor 
emulation as such, more a translation of what the code in the second 
processor is expecting to work into native processing.

The effect would appear that the emulated system is a second processor 
connected to an Arc, but it is only the second processor system that is 
emulated.

In case my blatherings still make little sense, a wee example:

Consider a program in a 6502 second processor emulation that wants to go 
to Mode 7. It sends the VDU sequence of 22,7 to the OSWRCH routine at 
&FFEE. This routine is a "wrapper" of sorts, and sends the VDU sequence 
to the TUBE. The emulation sees this happening, looks at the sequence 
thats been sent, and sees a request for Mode 7. It doesn't emulate an 
I/O processor going to mode 7, but rather switches the native hardware 
instead (or to the Arc's poor approximation of teletext). It then places 
data in the TUBE for the second processor to read back that equates to 
"job done".

If you look at the BeebEm emulator, it emulates both sides of the TUBE, 
so both a BBC Micro and a second processor are emulated and pass data 
between each other. This makes less "native" work for the emulator (as 
far as TUBE emulation is concerned) and makes for a fuller emulation.

I would also like to comment on the suggestion that "What it is plugged 
into is irrelevant". This is not necessarily true. While the standard 
implementation of the TUBE is for passing operating system calls, 
anything that expects to be able to drop code into the I/O processor for 
execution will fail completely on a "call emulator" that has no memory 
or code emulation (does the copro version of Elite do this?).

I was myself always under the imrpession that !65Tube emulates both 
sides. If the I/O processor is indeed a call emulator, then does this 
mean there are programs that will not work correctly in !65Tube? (I 
anticipate a yes here given !65Host's abilities....)

-- Richard