Date   : Mon, 28 Sep 2009 07:55:56 -0500
From   : mfirth@... (Michael Firth)
Subject: Couple of Tube operation queries

On Mon, 28 Sep 2009 08:49:02 +0100, "David Harper"
<dl.harper@...> wrote:
> I don't have the App Note you are referring to, so I cannot tell which
bits
> you are referring to by "T", "V", "M", etc. However some years ago I did
a
> lot of practical experimenting with the low-level operation of the Tube
on
> the Master 512. A summary of what I found is at:
>    
http://www.cowsarenotpurple.co.uk/bbccomputer/master512/tube.html#tubeula
> 
I got the App Note from the Ex-Acorn FTP site, and unfortunatey it was a 
PostScript file, which makes reading it a bit awkward, especially on
Windows systems.

I've just found that the same document is available as a PDF from Sprow's
site, at:
http://www.sprow.co.uk/bbc/hardware/armcopro/004.pdf

The correlation between Acorn's definitions and yours is:

Acorn Bit Name   Your Definition
Q                control bit 0
I                control bit 1
K                control bit 2
M                control bit 3
V                control bit 4
P                control bit 5
T                not defined - would be control bit 6

For info, certainly on the Acorn 6502 Co-Pro, the Host IRQ line is normally
not
connected (apparently because otherwise the host ceases to work if the
Co-Pro is
powered down), so the Q bit (control bit 0) function isn't available.

> At this level the Tube operation is a little untidy, though it works
> perfectly well in practice.
>   A couple of specific technical questions about the operation of the
Tube
>   ULA, which aren't clear in App Note 04 (and indeed some of which are
>   contradictory in it):
> 
>   The Tube "T" bit (sort of a soft reset):
>   1) Is it used by the actual software implementation? - the BeebEm code
>   for emulating this bit looks very broken, so I think that if it was
used
>   by the Tube host code implemented by Acorn then it wouldn't work
>   properly.
>   2) Is this bit a set / reset flag (as implied by page 13 of the App
>   Note), or is it self-clearing (as implied by page 12 of the App note)?
> Not sure which bit you are referring to here (see above), but most bits
are
> given default values by the Beeb reset sequence (unless the host is a
> Master configured "Notube").

As you haven't defined the existence of this bit (see above), I suspect
that confirms
its not actually used in practice.

>   Register 3 operation:
>   Does this register operate exactly as per the "Register 3" section of
>   page 13 of the App Note? - this section is contradicted by other areas
of
>   the App Note - e.g.:
>   1) The register 3 section says "In two byte mode the data available
flag
>   will only be asserted when two bytes have been entered", while the
>   Control and Status Flags section earlier on the same page says "In the
>   case of the FIFO registers, data is available when there is one or more
>   valid byte in the register"
>   2) The register 3 section says "Not full ... will remain active until
>   both bytes have been entered", while the reset operation says "register
3
>   has one valid but insignificant byte in the parasite to host FIFO to
>   prevent an immediate PNMI state" - If the register 3 section is true,
>   then when the V bit is set it should be needed to have two bytes in the
>   FIFO to prevent an NMI.
> This operation is messy, and I have tried to explain it on the web page
> above. In short, the status bits do not exactly represent the true
register
> state, and the two No.3 registers (host-to-parasite and parasite-to-host)
> do not operate in quite the same way. 

That's interesting, and the first time I've heard of register 3 being
asymmetric.

I think I need to look at the BeebEm code for that more closely, to see
exactly
what they've done there - If anyone can point me at another reference for
an
Open Source implementation of the Tube ULA, I'd happily look there too, but
the
BeebEm code is what I have now.

>   The latter case probably becomes a non-issue if the "T" bit isn't used,
>   as for a hard reset the V bit will be cleared (as indeed will the M
bit,
>   preventing the problem NMI from happening), making the number of bytes
in
>   the parasite to host R3 irrelevant.
> 
>   Thanks for any advice that anyone can give on this, and apologies to
>   everyone who hasn't read App Note 4, to which most of this will seem to
>   be gibberish!
> HTH

Thanks, its good to have another reference for the ULA operation, and one
that's
been produced from analysing what it does, not how its documented.

The Master 512 does seem to be a bit different from my main area of
interest (which
is the 6502 Co-Pros), as it uses the DMA features, which they don't, and
doesn't
use the NMI signal, which they do.

Thanks

Michael