Date   : Tue, 06 Jul 2010 23:40:13 +0100
From   : mlist@... (Steven Flintham)
Subject: Second processors and OSBYTE &84/85

Hi all. I am confused...

On 65Tube 1.20 (running emulation OS 0.64) with the built-in HIBASIC, I get:

 >A%=&84:P. ~USR&FFF4
   91B80084
 >A%=&85:X%=0:P. ~USR&FFF4
   91800085

On BeebEm 4.10 in BBC B mode with a 65C02 second processor and BASIC II, 
in screen mode 0:

 >A%=&84:P. ~USR&FFF4
   B1800084
 >A%=&85:X%=0:P. ~USR&FFF4
   73300085

On BeebEm 4.10 in BBC B mode with a 65C02 second processor and HIBASIC 
4.30, in screen mode 0:

 >A%=&84:P. ~USR&FFF4
   B1B80084
 >A%=&85:X%=0:P. ~USR&FFF4
   73300085

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 
though. Is it or not? And if it's not, how can I determine "the upper 
bound of memory which I can use freely if I am running a machine code 
program and don't care about BASIC"?

The BeebWiki page on OSWORD &84 says:

If b7 of A is clear, then A:Y:X holds the 23-bit address of the top of 
user memory, as when running 6502Turbo code on a CoProcessor, which 
returns A=&04, XY=&0000.

I assume this means that to be super-portable I should check A on exit. 
(But the NAUG says OSBYTE always preserves A...) I also assume this 
occurs only on a 65816 co-processor, and perhaps even then only if 
access to >64K is enabled by some software switch. But I am by no means 
confident about these assumptions.

The NAUG doesn't mention second processors in its description of OSBYTE 
&85. The evidence above suggests it ignores the presence of a second 
processor and answers the question for the host.

I had assumed the purpose of OSBYTE &85 was to allow a program to ask 
"if I change to mode X, which areas of RAM will become screen memory, so 
I can decide if doing so would be a bad idea, or so I can get my data 
out of the way first". This doesn't seem to be the case if the program 
is running in a second processor.

I thought "well-behaved" applications didn't need to care if they were 
on a second processor or not. But given the behaviour above, how can I 
answer the two questions:
- what's the upper bound on memory available to me right now?
- what will it be if I change to mode X?
in a way that will work with or without a second processor? Right now I 
suspect the first step is to detect running on a second processor and 
hard-code &B800 as the answer, otherwise use these OSBYTEs.

Any advice or clarification would be much appreciated...

Cheers.

Steve