Date : Mon, 28 Sep 2009 20:09:47 +0100
From : mfirth@... (Michael Firth)
Subject: Couple of Tube operation queries
David Harper wrote:
> 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.
>
Interesting. The Watford book is the only (semi) official documentation
that
doesn't make a differentiation between reading and writing the status
register.
Both the AppNote, and the 6502 Second Processor Service manual (one other
source that describes the Tube ULA operation) talk about the behaviour being
different for reading and writing.
That said, there are several obvious clangers in the Watford book -
referring
to the Tube as "", which plainly isn't true, for example.
I had heard that this book was actually written by Acorn, and just
published by
Watford - if that's true, it seems like it needed another proof-read
before publishing!
> 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.
>
Indeed. The App Note confirms that this bit is "Write Only", which means
that
it isn't even possible to see how it really behaves on a real Co-Pro.
I think I won't worry about it for now, as I'm not sure its used by the
software,
and if the only place it might be used is after a Host reset, then it
probably doesn't
matter, as that action causes a Tube chip reset anyway.
> 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.
>
Have you got a reference of where this initialisation code is in the Master
MOS ROM?
I tried looking on a BBC B, but haven't had time to decode the DNFS ROM
enough yet to work out which bit of it is the Tube Host (assuming its
all in a
block), or what it does on reset.
It does seem to have the strange feature that the run-time host code is
one of
the few things I've seen that executes code in zero page, usually its
mostly used
for storing variables.
> > 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.
>
Indeed true, and probably sloppy wording on my part. Its more that the
aforementioned "Register 3" section of the App Note talks about the
operation
being the same in both directions, which doesn't correspond with your
findings.
> > 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.
I'll have a browse through that later.
Is there still interesting things that can be done with a Master 512
that can't be
done more easily with a modern PC?
I'm in the slightly odd position that the only time I had any experience
with the
Master 512 was far enough removed in time from my first standard PC
experiences
to really appreciate how closely the two appeared, or what could be done
on one that
you couldn't on the other.
(Our school had a couple of Master 512 boards, which I managed to
borrow one of
in around 1989, but I didn't use anything PC like again until about 1992)
Regards
Michael