<< Previous Message Main Index Next Message >>
<< Previous Message in Thread This Month Next Message in Thread >>
Date   : Tue, 01 Dec 2009 21:53:56 +0000
From   : kevin@... (Kevin Bracey)
Subject: Tube - I/O processor memory questions

John Kortink wrote:
> On Tue, 01 Dec 2009 20:28:57 +0000, Kevin Bracey
> <kevin@...> wrote:
>
>   
>> Really annoying. I guess languages that needed to parse their 
>> command-line were never that common, so not much attention was paid to 
>> making it easy.
>>     
>
> I can't remember it ever being used.
>   
EDIT is indeed the only one I could think of, so that's what I looked at.
> If the language boots from ROM using a *-command, the
> *-command should probably relay any parameters to the
> language in its own specific way. 
But that doesn't work if the language isn't in ROM, and they've just run 
the image from disc on a coprocessor. And conversely, the HI version 
that you might think would normally be loaded on disc, could equally be 
installed in a ROM and started from a service *Command. Pah. The ideal 
is that the same image should work either in sideways ROM or as a disc 
load, so that basically reduces us to doing what EDIT does.

I can think of some mechanisms that involve attempting to make calls to 
my service section, but they'd all be quite complex, and involve quite a 
lot of tests, conditions and state, for no real benefit.  If OSWORD 5 to 
&FFFF00F2 was deemed good enough for Acorn EDIT, it's good enough for me.
> Using &F2/F3 (which
> probably requires re-scanning the commandline to find
> the parameters) sounds like an afterthought to me.
>   
Indeed, you do have to skip past the filename/command to a space again, 
but that's much as a normal service *Command handler. Just with the 
added overhead of the OSWORD 5.  Just a bit silly that you often end up 
repeating work your service handler did.

In my case, the parameter (which is another filename) is critical - 
there's nothing I can do without an input file.

Which has left me pondering how best to handle Break. Not really 
investigated that yet, but I need to try to reacquire the file I was 
originally using. What's the most elegant way to deduce that my language 
has been re-entered after a Break, and that I should try to re-open the 
previous file (and/or assume/check it's still open? Not quite sure what 
different filing systems do to their open file handles across Break). 
Should I look for magic words in my workspace? Or is there some definite 
cue that this is a Break-derived entry?

Maybe I should just pop up an OSWORD 0 prompt and get them to type in a 
filename. Might not be that bad an idea though - by pressing Break, 
they've pretty much lost state - a BASIC-style "OLD" is unlikely in most 
cases. So they may well want to try a different input file.

Hmm, and in the degenerate case, which I can imagine, a BBC B where this 
is the only language, and BASIC's been removed/unplugged to prevent 
hacking, or in a Master where this is the configured language, I am 
going to need some way to select input files. Or indeed to get to 
another language. So, yes, I guess I do need a prompt, and really one 
that accepts *Commands.

Beginning to wander here on a stream of consciousness, but in the Master 
case, if they don't deign to give a proper filename, what's my correct 
response to drop out to a Supervisor prompt? Just do an RTS? Is that 
what provokes "Language?" on a BBC?

Kevin
<< Previous Message Main Index Next Message >>
<< Previous Message in Thread This Month Next Message in Thread >>