Date   : Wed, 07 Jul 2010 13:04:19 +0100
From   : jgh@... (J.G.Harston)
Subject: Second processors and OSBYTE &84/85

Steven Flintham wrote:
> 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
>
> 65C02 second processor and BASIC II, in screen mode 0:
> >A%=&84:P. ~USR&FFF4      > > B1800084
> >A%=&85:X%=0:P. ~USR&FFF4 > > 73300085
>
> 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

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.

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

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

OSBYTE &84.

> 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.
> (But the NAUG says OSBYTE always preserves A...) I also assume this

The return meaning of OSBYTE &82/3/4 was extended when the 32016 CoPro
and 6502Turbo emulator came around. As OSBYTE &82/3/4 are always
processed in the application processor they can fiddle with the A
register.

> 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

Correct, *if* you are running in the I/O processor. OSBYTE &85 tells you
where the bottom of screen memory will be, *not* where the top of
usable application memory will be. The bottom of screen memory will only
ever conflict with the top of application memory if the current program
is running on the same processor as the screen memory. If the current
application is running in a second processor, then the screen will not
interfer with it.

6502 BASIC uses the following code:
   Call OSBYTE &82 to see what processor I'm running on
   If result=&FFFF THEN
     Call OSBYTE &85 to see what changing MODE would do
     If result<current HIMEM THEN Error Bad Mode
   ENDIF
   Change mode

If you're not running 6502 code, then by definition you're not running
in the I/O processor, so you can skip the check and go straight to
changing screen mode.

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

OSBYTE &84

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

If you're running on the I/O processor (as determined by OSBYTE &82
returning &FFFF) then it's the result of OSBYTE &85,X
else, it's the result of OSBYTE &84.

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

On a 6502 the upper bound of usable memory will always be the bottom
of the currently running application (eg 8000 for an unrelocated
language, B800 for HiBASIC, about C100 for HiView).

-- 
J.G.Harston - jgh@...