Date : Mon, 28 Sep 2009 19:15:35 +0100
From : dl.harper@... (David Harper)
Subject: Couple of Tube operation queries
Michael Firth wrote:
> 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
Thanks for this.
> 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
I have noticed that they are named also in Watford's "Advanced Reference
Manual for the BBC Master", but that doesn't mention T.
It would not be possible to read this bit, of course, because the space it
occupies in the memory map is taken up by the "write" status bit for
Register 1.
It may well work as suggested in this App Note. During the Beeb's reset
sequence, and assuming "Notube" is not set in the Master's configuration
RAM, the system writes values to all of the control bits, writing a couple
of bytes to location &FEE0. This has two functions: (a) the system can check
whether it has succeeded in altering the values, and this tells it whether a
co-processor is attached; (b) it resets the co-processor, if one exists. The
setting of bit 5 (P) resets the coprocessor CPU; probably writing to bit 6
(T) is resetting the Tube ULA at the same time.
> 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.
I have just looked again at the 512 co-pro's circuit diagram, and it looks
like it is not connected on this either. (There is an open link marked in
the connection.) I hadn't noticed this before.
>> 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.
See above.
>> 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.
It is things like this that made me feel it was better to speak of 8
registers (4 in each direction between Host and Parasite). The H-to-P
registers really are quite separate from the P-to-H ones.
> 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.
Yes, the 512 has a very different use for NMI, which I have documented
elsewhere in my pages (under DOS Interrupt 2). There was a very specific
problem that had to be coped with by the 512, and the use of the NMI to do
so was really quite an ingenious solution. And using the DMA is a more
natural way of handling Tube transfers with an 80186.
David Harper