What page zero can I use?

[Preppie]

I'm using MADS and was confirming the page zero I can use.  According to memory maps the top half of the page should be available but if I store anything in 219/220 the system crashes, and this also makes me question the other 4 bytes in this area:

 

Quote

218-223 DA-DF FRE

FP extra register (?)

 

Memory maps seem to be a bit uncertain on this, anyone know what it is?

 

 

[zbyti]

36 minutes ago, Preppie said:

if I store anything in 219/220 the system crashes, and this also makes me question the other 4 bytes in this area.

I don't know but system not crash, quick test, everything works fine.

 

[Preppie]

Sorry, I'm a fool.  Was using a ZP myself in a loop - d'ho!

 

 

[R0ger]

You can also turn off ROM and use everything ?

[+JAC!]

On 7/25/2020 at 8:58 PM, Preppie said:

I'm using MADS and was confirming the page zero I can use.  According to memory maps the top half of the page should be available but if I store anything in 219/220 the system crashes, and this also makes me question the other 4 bytes in this area:

 

 

Memory maps seem to be a bit uncertain on this, anyone know what it is?

 

 

If you do not use BASIC or the FP ROM, $80-$ff is free for use by application program. You should not touch $00-$7f, except for regular use of the documented locations (set/get cursor, screeen pointer, attract mode, ...).

[E474]

Hi,

 

   I was thinking about turning off/not using the OS ROM, and that probably would make a lot of sense for a (graphically oriented) game. You could start the code from $200, use all of page zero, and handle keyboard input by reading from hardware directly. If you needed disk I/O you could use @HiassofT's routines (assuming GPL 2 compliance - I don't think there is a library version), or write your own. Not sure how you would handle PBI I/O, given the PBI handlers might use O/S calls (probably @flashjazzcat has some insight on this)? I think as long as you are handling all the interrupts it would be quite practical to do this. 

[flashjazzcat]

45 minutes ago, E474 said:

probably @flashjazzcat has some insight on this

There are a couple of instances in which PBI handlers may call the OS; most notably if they are registering an entry in HATABS (in which case they will call NEWDEV). The problem is, the handler will probably assume the OS database is present in low RAM, and potentially wipe out any locations you've overloaded for other purposes (hard disk drivers will typically interact with the zero page DCB variables). The most practical means of using RAM under the OS is to simply re-enable the ROM every time you call the OS and then disable it again afterwards, but doing so won't increase the amount of zero page memory you can use.

 

I was faced with the same dilemma when writing the graphical OS. If the OS has any hope of working well with PBI handlers (including U1MB/SIDE hard disks and PBI-accelerated SIO using Hias' driver), having the stock OS code and variables where they are supposed to be is probably a good idea.

[ggn]

How about turning off interrupts, saving page 0 and disable ROM? Then when/if you require i/o then restore page 0 and enable ROM again. The o/s in theory wouldn't know what happened during the time it was off.

 

(Never tested this kind of thing on the Atari 800 hardware but on the ST it's not an uncommon practice if we want to take advantage of low ram addressing)

[flashjazzcat]

Just now, ggn said:

How about turning off interrupts, saving page 0 and disable ROM? Then when/if you require i/o then restore page 0 and enable ROM again. The o/s in theory wouldn't know what happened during the time it was off.

Indeed. Only the OS RTC at would be off, but you could always update that via your own interrupt handler if this were a concern.

[E474]

Hi,

 

    Presumably you could leave the page zero DCB alone, and just call the loaded PBI driver code (that is pointed to by the updated HATABS entries, not sure of the details as I am not at a PC). I guess by the time a program is loaded the PBI driver would be installed already (if at all). If the PBI driver is calling into the OS during disk I/O, this is obviously not going to work, but I don't know enough about this to say if it's likely or not (driver code should be well behaved, and only use official/published vectors, and I can't think of any that would apply, off the top of my head). 

 

   What I'm getting at is having SIO disk I/O handled by @HiassofT's code, and PBI I/O handled by the device drivers. If you can call the PBI driver directly (using the info added to HATABS), and the drivers don't call in to the OS, then you can use all of page zero (apart from 16 bytes for the DCB), and have code from $200 onwards. You have to give up on using OS calls, but in a gaming environment I think that's quite reasonable. I think the only thing you might want the ROM for would be standard font data (and you're probably using a customised font anyway, so that's not really an issue). If you move away from using the OS at all, the ROM is going to be switched off, and never called.

 

   I've always thought that a lot of page zero values didn't really belong in page zero, but on the other hand, if they had been moved up, it would have been Page 7 Magazine instead.

 

   Probably the best solution would be moving/restoring the page zero DCB as necessary, as calling disk I/O would be done by the game anyway, and then you could use all of page zero. I remember reading about a DLI routine that was stored in page zero just to make it a little faster, presumably a lot of graphics code could end up there too?