Date : Mon, 30 Nov 2009 12:42:20 +0100
From : kortink@... (John Kortink)
Subject: Tube - I/O processor memory questions
On Mon, 30 Nov 2009 02:30:56 +0000, Kevin Bracey
<kevin@...> wrote:
>John Kortink wrote:
>> On Sun, 29 Nov 2009 23:42:06 +0000, Kevin Bracey
>> <kevin@...> wrote:
>>
>>[...]
>>
>> It sounds very much like reverse engineering to me.
>>
>What's the difference between this and any other official documentation
>though? This is *the* manual for the product.
I agree that there is no immediate reason to mistrust
it. But looking even a little beyond the docs, clearly
it should be.
>If the manuals say that 00..8F are available for languages on the I/O
>processor, why should we believe that?
Because it's always been true, and has been confirmed
by a lot of other documentation (which may be why it
remained true ...).
>[...]
>
>I've not seen any document suggesting what Acorn's thoughts were about
>future 6502 copro compatibility. The closest thing I've found is this
>line in App Note 004 about general things likely to make code non-Tube
>compatible:
>
>"Other invalid actions include:"
>"Peeking/Poking memory unless the location is guaranteed to be the same
>in both memory maps."
Exactly. That's the main rule to follow. Use only what
you would use on a single processor system as workspace.
>That rules out 8000-F7FF as much as 90-EE.
If you want the maximum software-machine compatibility,
yes. But obviously the former range is only there to
support larger programs, and has no contention issues.
>[...]
>
>I've not found anything suggesting that they ever had second thoughts
>about the layout documented in the original documentation. Did the
>Master Turbo copro Tube OS change anything at all from the original?
Only two minute details : a slightly different boot/help
message, and OSWORD 5 sending all 4 address bytes instead
of just 2.
>> Not least because at this moment I happen to be right
>> in the middle of heavily tweaking Tube OS 1.10 for my
>> own creation ReCo6502, which is why I know that those
>> allocations are not entirely correct. In reality, error
>> messages are copied to &236-&2FF, i.e. there is no user
>> memory in page 2. And page 3 is not used at all ...
>>
>Hmm, looks like something changed after the docs were written (whether
>from specs, or reverse-engineering). Evidence that people weren't
>thinking that hard about what was "legal" or not.
Exactly.
>Odd, in a product based around the Tube, where legality and use of
>documented APIs were so much of a focus. Wonder if that changed
>between public versions. Do you have info on versions of the Tube OS?
I only ever saw 1.10. I think that the 2p I bought back
then ran that version too (circa 1984).
>[...]
>option to use all of 200-3FF. Unless we find that something really
>important like Tube Elite is making assumptions about
>undocumented/incorrectly documented behaviour.
It doesn't seem to. It runs fine (and much faster :-)
on ReCo6502. But then I'm only using a couple more
high zero page locations than Tube OS 1.10.
John Kortink
--
Email : kortink@...
Homepage : http://www.inter.nl.net/users/J.Kortink
GoMMC, the ultimate BBC B/Master/Electron storage system :
http://web.inter.nl.net/users/J.Kortink/home/hardware/gommc
ReCo6502, the Acorn 6502 Second Processor on steroids :
http://web.inter.nl.net/users/J.Kortink/home/hardware/reco6502