Date   : Mon, 30 Nov 2009 02:30:56 +0000
From   : kevin@... (Kevin Bracey)
Subject: Tube - I/O processor memory questions

John Kortink wrote:
> On Sun, 29 Nov 2009 23:42:06 +0000, Kevin Bracey
> <kevin@...> wrote:
>
>   
>> John Kortink wrote:
>>     
>>> On Sun, 29 Nov 2009 22:06:25 +0000, Kevin Bracey
>>> <kevin@...> wrote:
>>>
>>>       
>> Well, they are explicitly documented as being available to languages in 
>> the original 6502 Second Processor User Guide:
>>
>>    Page 0 to &EE is available
>>  
>>
>> That's sounds like official documentation, not just some bit of 
>> reverse-engineering.
>>     
>
> 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.

If the manuals say that 00..8F are available for languages on the I/O 
processor, why should we believe that? They didn't leave themselves that 
much room there either - should we be keeping 80-8F clear just in case 
they want it back?

And the same for F800 - am I wrong to build my "HI" language versions 
assuming that?

You've still not persuaded me not to believe Acorn.  Clearly you're free 
to claim extra workspace for your copro, but it would be a minor 
backwards compatibility niggle. Certainly less serious than lowering 
HIMEM from F800, but it could upset Tube-tuned software that's expecting 
the standard, documented 6502 copro memory layout.

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."

That rules out 8000-F7FF as much as 90-EE. But that section's thinking 
more about stuff like trying to find your command line from &F2.

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?

> 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. 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?

It looks like someone had the bright idea of squidging memory up further 
to give more language space; leaving 300-7FF free, but that didn't reach 
the docs. If there's a documentation vs reality conflict like that, then 
you've clearly got a lot more leeway - effectively that gives you the 
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.

Kevin