Date : Tue, 26 Jul 2005 21:23:43 +0200 (BST)
From : Johan Heuseveldt <johan@...>
Subject: Re: ARM copros, speech cartridges, real timeclocks, etc
Hi Rob,
On Tue 26 Jul, Rob wrote:
> At 13:34 26/07/2005, Johan Heuseveldt wrote:
> > Not only the Tube code can't, but as the Tube code has no knowledge
> > about CoPro specifics in the rest of the Beeb, this not possible,
> > unless you write a lot yourself.
>
> From the sounds of it, any use of multiple co-processors is going to
> require some new software support;
Quite an understatement! :-)
> if only so there's actually a USE for having them!
In normal use I don't see any use for it, as normal use (I do hope
I see the full context here) implies desktop use, not really the proper
term for these home systems. :-)
The Beeb (itself) is just a single-user, single-tasking and
single-processor system. So, for a start, every CoPro just assumes he's
the only 'owner' of the Beeb, just by design!
But you could have the desire, lets say, to do some heavy calculations,
and think of it as fun to let that be done by a Beeb and some extra CoPro,
and specificly don't want that to be done on a modern machine with at
least multi tasking on it, for whatever reason you can come up with! :-)
Then indeed you have something to think about! It begins with putting all
your ideas in, directly followed, by a lot of efforts and other kinds of
'blood, sweat 'n tears'! :-)
Just to put it in perspective!
If that is something you like/want, then a start is some hardware that
allows the following:
* without damaging the electronics, connecting several CoPro's in
parallel on the Tube connector
* make a selecting system, so that the Beeb is always seeing a single
Tube ULA at the time, so that reading/writing from/to a single
ULA is taken care off.
* allowing the Beeb to switch between CoPro's at well defined points,
which is clearly a software issue
These are pretty basic, and an absolute must on the hardware side.
Before going to the software, you need to think about hardware in
conjunction with software. That is, in the current sitation the Beeb is
polling the Tube ULA in a software loop, and watches flags to know when
actions are requested from the other side. It also means that the Beeb
cannot do something useful at the same time. [*]
It would be nice though that the Beeb gets informed by these requests by
interrupts, instead of using a polling loop. So in this context of brain
teasing thoughts about these multiple CoPro's, this is not the most obvious
issue to think about. Such an interrupt system is not used at all. The
beeb is normally polling, remember! So, why coming up with this now!?
The point is, although never used, the facility for interrupting the
Beeb from the CoPro side, IS available in the ULA design! So, when
thinking about the things we are now thinking of, this is the moment to
think about it, uh.. sorry (couldn't resist), take that into account, as
real concurrent processing is then possible!
(without waisting precious processor time by polling)
BTW I have always wondered if every Tube ULA used in a CoPro has
indeed this function fully working. That is, if it is not working
because of production failures, there is no real need to withdraw
such a Tube ULA, as it is never ever used, to my knowledge.
Would Acorn rejected the faulty device, or still put it in?
Were there other designs or real machines that DID use this function?
I hope this further explains some ideas/issues...
greetings,
Johan
[*] Most texts that talks about concurrent processing when referring
to the Beeb with a running CoPro, are in fact wrong. If that
needs further explanation, let me know, and I'll certainly try
to explain (further).
That is, if my recent writings here on the list are indeed in some
way easy to crasp. TBH, I'm far from sure.
--
Johan Heuseveldt <johan@... >
aka waarland
The best place is a Riscy place
A man can be happy with any woman as long
as he does not love her. - Oscar Wilde