Reserving low memory by a TPA program

[ivop]

Hi,

I have been working on the Atari XL port, and it's working now. BIOS, BDOS and CCP are "under" the ROM so to speak, and there's over 49kB of TPA RAM for user programs now.

But there's a problem with loading fonts. I used to load them at the end of the TPA, lower the upper limit and be done with it. That won't work if that part of RAM is under the ROM. Used to be $bc00, now it'll be $cc00. But everytime the ROM is switched on for CIO or SIO calls the font will disappear and garbage is displayed.

I have already moved the screen memory to low RAM, but that's setup before the rest is run. Now if I want SETFNT.COM to load a font, 1 kilobyte aligned (requirement of the hardware), in low memory, it will overwrite itself while it's running. Is there a way to avoid that? I could reload myself (i.e. setfnt.com loads setfnt.com somewhere higher, relocate it and run again), but I was hoping for something more elegant :)

Regards,
Ivo

[davidgiven]

It is doable without relocation, but it's ugly. The bottom of your binary contains the font, plus 1kB of padding. The actual code starts above this. On startup, you move the font data so it's aligned; the padding allows this without interfering with the code. Before exiting you adjust the TPA to discard the code.

The downside is that you're wasting up to a kilobyte of memory for the padding.

[ivop]

I see. As in my case the font is to be loaded from disk and not part of the COM file, it means I have to pad with 7 pages to be prepared for the worst case of non-alignment with 1kB boundaries. That's 14 sectors on disk, which is quite substantial as setfnt.com now is only 4 sectors. Reloading itself and relocating and copying over the fcb might be an option. The second copy needs to check TPA lowmem with its own lowmem to know it has been called before.

I was also thinking of creating a small wrapper that has setfnt.com included as an array or block of bytes. The wrapper copies that array to the top of the memory (perhaps minus one extra page in case the fcb would spillover), calls relocate, copies over the fcb to its pblock (offset is in the header) and then jumps to it. That might need less sectors read from disk and could be reused for other programs that need to allocate memory at the bottom of the TPA. Would that be acceptable?

[davidgiven]

Anything's acceptable!

How big is the ROM? Could you split the memory map into MAIN and EXTRA, with the boundary at the bottom of the ROM, with the BIOS loading right at the top of memory and the CCP and BDOS under the ROM? That way setfnt could claim an aligned block from the top of TPA, and (assuming I've understood the Atari memory map) because the BIOS isn't in low memory any more you should even get some TPA back?

[ivop]

I chose to implement no hack. On a <= 48kB machine, it loads the font at the top of the TPA. On a 64+kB machine, the first run reserves memory, and after that you can change fonts at will.

The ROM is 16kB (c000-ffff). I have split the memory into MAIN and EXTRA already. MAIN is from 0500-cfff (where c000-cffff is under the ROM). d000-d7ff are the hardware registers, d800-dfff is the BIOS, e000-e3ff is a copy of the ROM font for when the ROM is disabled (same location as in the ROM), e400-ffff is the EXTRA bank that contains BDOS, CCP and some free memory. BIOS is basically not in any bank :) And MAIN only contains two small interrupt routines for when the ROM is disabled and two wrappers to call CIO (keyboard) and SIO (serial or PBI disk access). By using SIO you get PBI devices like flashcarts, IDE interfaces, etc., for free. Or alternate OS's with high speed SIO code, up to 127k baud serial.

[davidgiven]

Closing for cleanup.