Date   : Tue, 25 May 2004 14:54:40 +0200 (BST)
From   : Johan Heuseveldt <johan@...>
Subject: Re: Tube / Master Coprocessor question

Hi Chris,

On Sun 23 May, Chris Smith wrote:

> Not sure if this is possible...   

> Is it possible to run "application code" on both processors at once? 
> Preferably interrupt driven on the IO processor (via 1MHz bus).  I wish
> to implement a simple protocol handler which is called from the language
> processor.

In principle yes, but you have to rewrite the Tube code. ATM it is polling
the TUBE ULA, and reacts on that.
If there is nothing to be done, then the I/O processor isn't doing anything,
except waisting time, while err... polling.

The only partial double processing is the VDU handling. The 2nd Porcessor
gives the VDU bytes to the Tube ULA, and continues its task. The I/O
Processor handles the VDU in parallel with the language processor.
Well, hopefully:

But, if directly after the VDU output, the 2ndP wants to do other I/O like
disc access, it still have to wait for the I/O Proc, finishing its VDU task,
or whatever I/O task it was busy with.


BUT
~~~
Don't know if Acorn had any plans for parallel processing, but the
TUBE ULA has an interrupt provision: it can interrupt the I/O proceesor
with the IRQ-line. So instead of polling the TUBE chip, it can do whatever
the user wants it to do, provided het writes the software for it.
And, please note, interrupt is from is single register pair (pair 4).

Of course you have to rewrite the TUBE code in the I/O processor
from poll-driven to interrupt-driven.
Not sure (yet) about the TUBE OS in the language procesor.


OR
~~
The other way is as you suggested: doing the interrupt from I/O events, and
leave the polling as it is. The disadvantage is the time consumed by
interrupt driven tasks in the I/O Proc. During that time, the TUBE is not
polled, and therby ignoring all requests from it. This would make the
response very sluggish.

If you want to deal with that, you have to make provisions for timing you
interrupt code yourself, with the use of a timer interrupt.
A way to do this is using the ticker/100MHz event, counting a few of them
(configurable), use your own code to poll the TUBE ULA for pending tasks. If
something waiting is found, a semaphore is set.
Interrupt-started-polling now ends.
(this code should obviously be short, very short!)

In your interrupt driven software, this semaphore is checked reguraly, and
should be responded on. Dealing with the flag is difficult. You must use a
single opcode to set or reset that flag. And probably with interrupts
disabled as well, not sure though, as I haven't done any rearch that deep.
Using the same way as the TUBE code in the I/O Proc claims the TUBE, is a
good start though!


I've never seen remarks on the possible interrupt of the TUBE ULA: Is it
always there and fully functioning, or is it possible that malfunctioning
chips concerning this interrupt possibility, but otherwise pass all other
tests, are just being used?

Also, documentation is not 100% available. There are some issues about
clearing the interrupt. And there is more to investigate.


Hope this gives you a clue somehow.

greetings,
Johan

-- 
Johan Heuseveldt <johan@...              >
  aka  waarland

  The best place is a Riscy place
 
"Flight by machines heavier than air is unpractical and
insignificant, if not utterly impossible". - Simon Newcomb.