Date   : Wed, 27 Jul 2005 14:06:16 +0200 (BST)
From   : Johan Heuseveldt <johan@...>
Subject: Re: ARM copros, speech cartridges, real time clocks,etc

Hi Eelco,

On Wed 27 Jul, Eelco Huininga wrote:


> > > I think the most reasonable solution would be to program a FPGA to act
> > > as an Tube/Serial/Video ULA.
> > 
> > There's a misconception here.
> 
> Indeed! :-)
> 
> > Serial and Video ULA's belong to the Beeb as system properties. The
> > Tube ULA belongs to the CoPro, for which the host-side is seen by the
> > Beeb.
> 
> [snip]
> 
> Yes, you're right, but I'm not talking perticulary about the Tube ULA. If
> you'd want to replace one of Acorn custom designed ULA's you'd have to go
> with the FPGA approach IMHO. ULA's are getting scarce, and if you're going
> to design your own second processor hardware, you'd have to come up with
> either a recycled Tube ULA (which means, as Jules pointed out, destroying
> another piece of hardware) or a custom designed chip of your own. The same
> goes for replacing the Serial or Video ULA, so that's why I brought them
> up.
> 
> Not because I thought the Tube ULA was part of the Beeb's hardware :-)

OK, But this is quite a substantional change in the system. For a start,
if you design/build such a Beeb-like, you will not be able to connect a
normal CoPro anymore, unless you preserve a normal Tube connector which
expects the Tube ULA at the other end of the cable inside the CoPro, in
addition to /your/ new Tube2 connector which have the Tube ULA on the
Beeb's board, and expects a CoPro without it.

You didn't make that clear. Well, I didn't see what you meant then! :-)


But there is possible a good reason why the Beeb is without the ULA, and
the CoPro, every CoPro, has the ULA build in. At first this seems strange:
Instead of a single ULA in the Beeb, at which every CoPro can connected
to, seems more logical. As there will be no need for the ULA in such a
CoPro, it saves on parts and money. But besides marketing and/or commercial
issues, there must be something else important as well, and that's a
matter of speed and interference.

Speed of Beeb remains the same, as the product is there! But new CoPro's
can be designed from scratch, very much later in time, with
better/faster/newer processors. Those new processors have to slow down
their speed to read/write the Tube ULA registers at the other end of
the cable, even if the CoPro side of the ULA is able to be addressed
much faster than the Beeb side of it. It's now the cable which is, could
be, the limiting factor. It seems right to put the cable into a known
state, which is the Beeb's end. That way problems will not arise from
new circumstances on the cable, caused by faster designs of the newer
CoPro's. With the Tube ULA always at the CoPro side, the cable status
is always the same and known.

'Knowing' the only 'correct' location for the Tube ULA, anything else
did not cross my mind. Any direction in the way you were thinking of,
I was unaware of, and nothing seems to trigger a more open view on it.
Sorry for that. Sometimes I seem to have a narrow view which don't
allow me to see any further than my own grey cells allows.
Now I understand!

But I sincerely think for speed-reasons/cable-lengths, this is not the
way to go, unless you make a design like the Master with an internal
CoPro, which have no cable lengths on either side! :-)


But as Jonathan had explained - in another post, if you want some I/O
/in/ the CoPro, then a combination of all three ULAs is a valid idea. But
it is then located in the CoPro, and not the Beeb, so is then a different
approach/design as the Video/Serial ULAs of the Beeb are not involved,
but are new ones in the CoPro. That's quite another story! :-)


greetings,
Johan

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

  The best place is a Riscy place
 
Wasting time is an important part of life.