Fixing Display List in RAM

[+therealbountybob]

OK I'm stuck (again) was looking at fixing my display list to start on a specific page:

 

I wondered why Gwobby Strikes Back didn't run on altirra without switching the BASIC ROM to the official one - It seems that altirra has more free RAM available so the display list is shifted by 32 bytes... someone else had problems running one of my games on their Atari with a memory upgrade... so again this has a different default address for the display list...

 

So I'm trying to fix a custom display list to a set page - I lower ramtop (106) by 16 pages for my fonts, and then want to fix the display list to below this. I've tried setting the 4th and 5th bytes of my display list to a new page in RAM and the last two bytes to the location of my DList. (GR.28) I've tried poking 560/561 and 88/89 with what I think are the correct values but no joy.

 

Please can someone detail the steps

thanks

[Rybags]

For any given value of the top of RAM, the DList should be placed in the same location for the same graphics mode with the same text window status, ie - Graphics 8 will have a different DList location than Graphics 24.

 

The OS will always put the DList below the screen RAM and there will always be extra RAM reserved for the text window whether you've requested it or not.

 

One possible pitfall - the screen pointer (88,89) is also used when I/O is performed to the text window so you've got to be careful about that. Generally it shouldn't be a problem in Basic but it's not a good idea for Assembly based interrupt routines to rely on it.

 

Pitfall #2 - if you don't set RAMTOP to a multiple of 4K then the hires 8K graphics modes won't work properly because of the 4K boundary crossing. You can also run into problems with other modes especially if RAMTOP is set to just above a 4K boundary.

 

 

Best practice is to not rely on anything being placed in a particular location by the OS insofar as the screen goes. If you're dealing with this stuff from Basic, then you're probably using variables anyway, so instead of going something like SCREEN=40000, do SCREEN=PEEK(88)+PEEK(89)*256

[Synthpopalooza]

For any given value of the top of RAM, the DList should be placed in the same location for the same graphics mode with the same text window status, ie - Graphics 8 will have a different DList location than Graphics 24.

 

The OS will always put the DList below the screen RAM and there will always be extra RAM reserved for the text window whether you've requested it or not.

 

One possible pitfall - the screen pointer (88,89) is also used when I/O is performed to the text window so you've got to be careful about that. Generally it shouldn't be a problem in Basic but it's not a good idea for Assembly based interrupt routines to rely on it.

 

Pitfall #2 - if you don't set RAMTOP to a multiple of 4K then the hires 8K graphics modes won't work properly because of the 4K boundary crossing. You can also run into problems with other modes especially if RAMTOP is set to just above a 4K boundary.

 

 

Best practice is to not rely on anything being placed in a particular location by the OS insofar as the screen goes. If you're dealing with this stuff from Basic, then you're probably using variables anyway, so instead of going something like SCREEN=40000, do SCREEN=PEEK(88)+PEEK(89)*256

 

One possible solution, if this is a small display list for a text mode (say ANTIC 4 or Graphics 0) might be to just store the display list somewhere on the end of page 6, assuming you are not using it for anything else ...

 

 

 

[Alphasys]

I kinda fail to see the problem here. Since Turbo Basic demands at least 64k in the machine, you don't really need RAMTOP to tell you what the top of memory is. It should always give 192.

 

New RAMTOP value would therefor always be 176. This is a 4k boundary condition, so none of the common pitfalls should occur. Just setting RAMTOP to 176, then doing a graphics command, should be enough to put the display list and screen memory in check (and it should even always be on the same exact spot too) and freeing up the 16 pages for your fonts.

 

If that won't help, could you maybe elaborate on what the issues are with Altirra or that memory upgrade? Does either of them change the memory map in any significant way? The 32 byte shift is puzzling me. Does the screen handler in the Altirra Basic rom not create the same screens as the Atari Basic rom?

[+therealbountybob]

I kinda fail to see the problem here. Since Turbo Basic demands at least 64k in the machine, you don't really need RAMTOP to tell you what the top of memory is. It should always give 192.

 

New RAMTOP value would therefor always be 176. This is a 4k boundary condition, so none of the common pitfalls should occur. Just setting RAMTOP to 176, then doing a graphics command, should be enough to put the display list and screen memory in check (and it should even always be on the same exact spot too) and freeing up the 16 pages for your fonts.

 

If that won't help, could you maybe elaborate on what the issues are with Altirra or that memory upgrade? Does either of them change the memory map in any significant way? The 32 byte shift is puzzling me. Does the screen handler in the Altirra Basic rom not create the same screens as the Atari Basic rom?

Seems Altirra default kernel mode and someones RAM upgrade give different default values for peek 88 & 89 than a standard XL/XE. I was trying to correct my display lists which 'worked' but I hadn't done things properly. Altirra has more free bytes unless you use XL/XE Rom. Looks like the altirra one I can't sort only a minor thing, not tested on the ram upgrade one yet, but have at least I've learned a bit more

 

Thanks guys

[phaeron]

There is a bug in Altirra 1.8 where the "Default" kernel option chooses the built-in kernel instead of the XL/XE kernel, even if you have the latter. It's a bug I accidentally introduced when I was adding the configurable ROM paths. The built-in kernel doesn't place the display list at exactly the same address.

 

My advice is that if you need the display list at a specific location, you're better off building it yourself rather than trying to convince the OS to do it.