Re: Himem with prodos basic?

[dempson@actrix.gen.nz (David Empson)]

Chad Choi Lin <chadlin@nyetcom.com> wrote:

> 1.)  Move TXTTAB up to a higher address
>      The start-of-program pointer is normally set to $801 (right after
> page 1 of text video memory) but can be changed to a higher address.

[snip]

>      10  POKE 103,1 : POKE 104,12 : REM Change TXTTAB
>      20  POKE 3072,0 : REM Store zero at TXTTAB - 1
>      30  PRINT CHR$(4);"RUN MY.PROGRAM" : REM Load and execute the main
> BASIC code

I've seen programs that do this without requiring two programs: your
program simply PEEKs TXTTAB to see whether it is set to $0801; if so, it
is modified to the desired value and the program runs itself again (from
disk - a simple RUN is not sufficient).

> 3.)  Move MEMSIZ to a lower address

>      (b)  Lower the value of MEMSIZ high (hex $74, dec 116) by the
> number of pages required, *plus* the four pages needed for the temporary
> ProDOS disk buffer (so if your assembly code uses three pages, you
> should lower MEMSIZ by seven)

According to the ProDOS-8 technical reference, BASIC.SYSTEM uses the 1K
above HIMEM as its working buffer.  This means that you should reduce
HIMEM by the number of pages you need, but skip four pages to locate the
area you can use safely.


There is another technique, which is easier to deal with than playing
with HIMEM.  BASIC.SYSTEM provides a routine called GETBUFR that can be
used to reserve one or more 256 byte pages.  These pages are inserted
between BASIC.SYSTEM and its buffers, and everything else is moved down
accordingly.  (Strings and open file buffers are preserved.)

To use it, load the accumulator with the number of pages and JSR $BEF5.
On return, carry is clear if the allocation was successful, and A
contains the high byte of the buffer address.  (You could POKE in a
small machine code routine at $0300 to do this.)

There is also a FREEBUFR routine at $BEF8, which frees _all_ buffers
allocated via GETBUFR, so watch out if you might be running other
programs that patch themselves in somehow and which might be using
GETBUFR.  (There is no official way to free individual buffers, but I
have a feeling that someone came up with a method to do this.)


For any of these techniques, there is the disadvantage that your
assembly code must be either fully relocatable or at least page
relocatable.  If this is difficult, then you may need to make use of the
monitor's disassembly subroutines to assist in relocating the assembly
code to its actual runtime address.  (Boy, that brings back some old
memories.  When did I last do this?  Must have been 1984 or
thereabouts.)

If the size of the BASIC program is reasonably well known, I usually
find that setting LOMEM is the easiest solution (if the code won't fit
at $0300).

-- 
David Empson
dempson@actrix.gen.nz
Snail mail: P.O. Box 27-103, Wellington, New Zealand