Date   : Fri, 04 Dec 2009 21:34:38 +0000
From   : kevin@... (Kevin Bracey)
Subject: Tube - I/O processor memory questions

Jonathan Graham Harston wrote:
>> Message-ID: <4B1480AC.5060800@...>
>>     
>  
> No, a language is only allowed to use memory in the **LANGUAGE**
> processor, that's why it's called the language processor.
>  
Not a terribly water-tight argument :)  There's no documentation 
assigning ownership of the spare memory to anyone. We equally know that 
service code isn't allowed to use the area between OSHWM and HIMEM.

And neither of the 6502 second processor manuals say it's reserved by 
the system (it's usually left blank in the charts), and they imply it's 
available by going to such pains to specify what IS reserved. Third 
party manuals seem unanimous that it's free.

So that leaves it something of a no-man's land. Much like the sideways 
RAM, or the BBC+'s odd 12K. It's extra RAM that's specific to a 
particular type of system, may not be there on other types of system, 
and there's no proper protocol for claiming it.

Which means that all sorts of smart-alec people may try to use it, for 
all sorts of purposes. So any usage should to be well documented, and 
ideally have an option to not use it. (Maybe like Exile's polite "May I 
use your Sideways RAM?" prompt). But it's definitely not reserved for 
present or future system use, at least in the 6502 case. Maybe the other 
copro systems' OSes might well use it - we can't extend a declaration in 
the 6502 manuals to them, obviously.

But you're not going to convince me that my language using it is more of 
a sin, than say, BAS128 doing what it does, being compiled to run at 
1900, having an enhanced Sideways RAM version of a game, or using &70-7F 
of the reserved Tube workspace. On the scale of dodgy things done a BBC 
micro, it's got to be well near the bottom of the list...

>   
> Yes, and what else is OSWORD &FF? It's Tube transfer code that
> extends the Tube functionality, and when a CoPro is active, the
> Tube system is the "current language" on the I/O processor.
>   
Ha! Nice try. It's user code that calls the Tube API. The hint is that 
you're on USERV, and have claimed a user OSWORD number. I'm sure you've 
established that the current Tube code isn't using the reserved 
locations &70-&7F, otherwise you wouldn't have done it, but you'd be 
theoretically vulnerable to a future version of the Tube code deciding 
to claim it - it's down as reserved for OS/Tube use. And you're not the 
OS, and you're not the Tube support code.

>  
> http://beebwiki.jonripley.com/Reading_command_line
>   
That's not terribly useful, it ignores all the issues I've hit and 
described here. Good enough for disc-based transient utilities, but not 
for languages.

I think the upshot of all of this is that I'm going to give up, and go 
with the flow. Do what the OS wants me to.

EDIT seems to be the only language that attempts command line parsing, 
it goes to great trouble to do it, and to some extent only gets away 
with it because the command line is in HAZEL on a Master (is it copied 
up by the OS?). On a BBC B, you're going to be parsing a string held in 
the workspace of the previous language, which you're in the process of 
replacing with your own workspace.

So I'll just have a prompt, and people can type the filename at the 
prompt. No big deal - it just means pressing RETURN instead of SPACE in 
the middle, and it's still fine for auto-booting discs, as I'll just 
EXEC !BOOT.

Putting my ROM into an Electron emulator convinced me - the cartridge 
slots are higher priority than BASIC, so I've got to make damned sure 
I'm nice; I don't want to attempt anything that might lead to an error. 
There's no supervisor prompt to fall back to if I fail (see below).

But then I had a happy half hour choosing and implementing my Electron 
firm keys definitions...

> Once the
> language has been entered, the language is responsible for handling
> all and every error ganerated.
>   
The Master actually appears to cope elegantly if you do throw an error - 
its default BRK handler shows the message, and drops out to the 
Supervisor prompt. I think it also reselects the configured language for 
the next Break, so it doesn't keep happening.

That's probably more useful than putting your break handler immediately 
in some circumstances - if for some reason your language can't start (no 
system disc?), or doesn't want to start, it gives you an opportunity to 
bail out to the system with a BRK.
>>> Entry is with C=0 for reset triggered start (hard/soft/power on).      
>>>       
>> I think we can count that as a cunning hack, rather than a proper
>> API. Not found it in my manuals either.
>>     
>  
> It's not a hack, it's documented, and the MOS code has specific
> SEC/CLC instructions to explicity set the state.
>   
Haven't found the documentation in contemporary manuals. Pointer? 
Looking at the disassembly I do agree it was probably the intent, but in 
practice, the 6502 Tube OS fails to maintain the distinction. So it's 
not legal in the commonly-used sense of "works when running over the Tube".

Kevin