<< Previous Message Main Index Next Message >>
<< Previous Message in Thread This Month Next Message in Thread >>
Date   : Wed, 07 Jul 2010 13:37:14 +0100
From   : mlist@... (Steven Flintham)
Subject: Second processors and OSBYTE &84/85

On 07/07/10 13:04, J.G.Harston wrote:
> In what way are you confused? In all those examples OSBYTE&84 gave the
> top of the memory available for the running application, in all those
> examples, BASIC, and in all those examples OSBYTE&85 gave the bottom
> address the selected screen would use in the I/O processor.

I was expecting more of a relationship between the two. I suspect I 
would never have been confused if I hadn't considered OSBYTE &85. I 
think it didn't help that the original AUG describes the calls as "Read 
bottom of display RAM address (HIMEM)" and "Read bottom of display RAM 
address for a specified mode" respectively.

>> The New Advanced User Guide says the result of OSBYTE&84 is not the
>> equivalent of HIMEM in a second processor. The above suggests it is
>
> OSBYTE&84 is never the equivalent of HIMEM. BASIC initialises HIMEM
> to the result of OSBYTE&84 on startup, running programs are free to
> then subsequently change HIMEM to whatever they want.

That makes sense, I wish the NAUG had been clearer. (In fact, I still 
think the NAUG is confusing at best. Why qualify the statement that the 
result of OSBYTE &84 and HIMEM are not equivalent with mentions of the 
second processor? Your explanation above shows this is equally true on a 
normal machine. And it labels the call "Read top of user memory 
(HIMEM)", so it seems to say "HIMEM is not equivalent to HIMEM". (I 
assume one is the OS sense and the other is the BASIC sense. I wonder 
why there's no equivalent of the OSHWM/PAGE distinction here?)

> See http://beebwiki.jonripley.com/MODE

Nice one, wish I'd thought to look there before.

Thanks for the info.

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