Memory Allocations - prefixed

[Yaron Nir]

so,

while programming a game i found that there are common capabilities that a developer is using from the A8 almost all the time.

they are (most of them):

- Player MIssile Graphics

- Display List

- Screen Memory

- Display List / Vertical Blank interrupts

- Sounds (Music/SFX)

- other?

 

considering the A8 memory laylout (attached image),

i found it is very useful to place the capabilities above in fixed memory addreses. and that is to avoid conflicts, overlaps, memory overwritten and other problems.

 

so, if free ram starts at address 0x2000, this could be 1 option to allocate the memory of the above:

 

1) PMG at address location 0x2000 - it is either 1K or 2K boundary size depending on the singe/double chosen mode (let's assume here it is single line and it takes 2K (0x0800)

2) Display List at address location 0x2800 - has a normal of 1K boundary (0x0400)

3) Screen Memory at address location 0x2C00 - let's take for this example Antic mode 4 a 40 by 25 chars 40*25 = 1000 Bytes (0x3EB)

4) Display List Interrupt - normally located at page 6 (0x0600) should be very small common 256 bytes (0x0100)

 

as for RMT would like to understand where it can be placed in memory with no issues and what is the boundary.

 

after that i can set the code starting address to be right after RMT or if RMT is set really high then code can start at 3000 (right after the screen memory and align

 

from your experience, working like that is recommended? are you doing it differently? if yes how?

 

Cheers,

Yaron

Edited May 1, 2019 by Yaron Nir

[phaeron]

One thing to keep in mind is that the alignment requirement for a piece of data is not the same as the memory required for that data. In particular, while single-line P/M graphics requires a 2K block aligned to a 2K boundary, it doesn't use all of that 2K. Only the last five pages (1.25K) are used, with the lowest three pages completely free.

 

For that reason, it's not necessarily a good idea to place the P/M graphics at the bottom, because that leaves an awkward 768 byte hole. You could always fill it in with some code, display lists, etc., but an alternative is to place it at the top of memory instead, where it packs more nicely. This works best when you are setting up the display manually, since there are complications if you are still using the OS display routines (E:/S:). But those are slow and inflexible anyway, so you might as well bypass them. It would also work to set PMBASE=$00, as long as you only need players 0-2 ($0400-06FF).

 

The display list has a stricter alignment requirement (1K) than the playfield (4K), so often the playfield can just be placed right after the display list. For the 40x25 ANTIC 4 screen above, this would put the display list at $2800-2820 and the playfield at $2821-2C08.

 

There are even more bytes to be squeezed out if you look closely enough. A character set for modes 2-5 takes 1K of memory, but that's only if you use all 128 characters. The space can be reused for any characters you don't need. P/M graphics technically don't need 128 or 256 bytes per player either as ANTIC only fetches 240 lines (8-247), so there are some little bits between the players that can also be used for small tables or groups of variables.

 

Typically there are more issues with memory conflicts during a program load than after the program starts running, especially if you take over the machine (don't use or return to DOS). Many of my test programs load at $2000 and above only, but once they start running, use a bunch of memory below that. Thus, it's convenient to prioritize low memory for uninitialized buffers (BSS) and higher memory for initialized data that loads with the EXE.

[Yaron Nir]

Thanks for the response phaeron.

 

Can you share an example on how you would fix the memory location I named above in your game the whole items I named above from start to end ?

[phaeron]

Can you share an example on how you would fix the memory location I named above in your game the whole items I named above from start to end ?

 

• $2000-22FF: Misc code or data, especially page-aligned tables
• $2300-27FF: Single-line P/M graphics (PMBASE=$20)
• $2800-2820: Display list
• $2821-2C08: Playfield
• $2C09 and up: Code and initialized data

-or-

• $2000-2020: Display list
• $2021-2408: Playfield
• $2409 and up: Code and initialized data
• $BB00-BFFF: Single-line P/M graphics (PMBASE=$B8)

[Yaron Nir]

display list is only $20 (32 bytes) size?

 

and where would you place RMT ?

Edited May 2, 2019 by Yaron Nir

[Wrathchild]

RMT is basically some code and data so can be mixed into your own code/data.

You can align it to a page boundary if you like - and within its own sources it does.

If you want it in its own segment then code might be around $A00 bytes and so in phaeron's example this could be at $B000.

You have then missed out the tune itself, so again need to reserve space for the size of that, so maybe subtract from $B000.

 

Overall though, there are no fixed rules, you can put what you like wherever you like.

If you have 64K or expanded memory then data can be loaded and then moved there.

If you use a cartridge code/data can be in banks and then copied or switched into RAM as needed, e.g. handy with RMT.

[Yaron Nir]

RMT is basically some code and data so can be mixed into your own code/data.

You can align it to a page boundary if you like - and within its own sources it does.

If you want it in its own segment then code might be around $A00 bytes and so in phaeron's example this could be at $B000.

You have then missed out the tune itself, so again need to reserve space for the size of that, so maybe subtract from $B000.

 

Overall though, there are no fixed rules, you can put what you like wherever you like.

If you have 64K or expanded memory then data can be loaded and then moved there.

If you use a cartridge code/data can be in banks and then copied or switched into RAM as needed, e.g. handy with RMT.

 

thanks wrathchild!

[phaeron]

display list is only $20 (32 bytes) size?

 

and where would you place RMT ?

 

Display list is 33 bytes: 3 bytes for blank lines, 3 bytes for LMS ANTIC 4, 24 bytes for the other ANTIC 4 rows, 3 bytes for JVB. You do not need 1K of memory for the display list, it just needs to not cross a 1K boundary.

 

No experience with RMT, I'm afraid.

[baktra]

RMT music is a binary load file, so when exported from the tracker, you choose its "base" address. The same is for the RMT player routine. You can also choose its address as needed. See rmtplayr.a65 in RMT's asm_src directory.

 

I am not following any set in stone memory layout. For every program I write, I use memory layout as needed. LD65 is flexible enough to allow that.

 

I only follow three rules:

0. Ensure there are no graphical glitches during the loading that could cause crash (like loading into live display list or screen memory)

1. If not necessary, do not prevent loading from DOS 2.5 (not necessarily exit back to DOS 2.5)

2. If not necessary, do not cut off the users of the 48 KB machines (400/800)

Edited May 2, 2019 by baktra

[Yaron Nir]

Thanks Baktra

[Rybags]

Consider what memory config is to be the minimum.

 

Consider inconvenience if using 64K or more, of swapping out the OS or switching which 16K windows appears @ $4000.

 

Under the OS is good for infrequent stuff like level data that might be depacked, or possibly speech samples. Or if you dispense of the OS altogether, use it to hold your interrupt routines and even screen and/or PMG data.

 

Consider the results of a warmstart and if your program is to survive it and run again - the screen will erase 1K of RAM either around $9C00 or $BC00 and there's nothing you can do about it other than choose between the two dependent on if Basic is enabled or not.

 

Choose whether your program is to be launchable from Dos - in such cases you'll probably want to leave memory under ~ $3000 well alone until your program load is complete.

[Yaron Nir]

There is one thing o didnt take into account and looking st Rybags response it raises couple of questions :

- why do I beed the O.S. area?

- I not needed how do I disable it ? Via code ?

- if disabled I can use the mem area ?

[baktra]

There is one thing o didnt take into account and looking st Rybags response it raises couple of questions :

- why do I beed the O.S. area?

- I not needed how do I disable it ? Via code ?

- if disabled I can use the mem area ?

 

Why you might need the O.S area (RAM under ROM)? Extra 16 KB of RAM!

 

The address space of XL/XE computers is 64 KB.

 

The last 16 KB of the address space is normally routed to ROMs with firmware (operating system), so you cannot use it for your program. But in the computer, there is still 64 KB of RAM.

Your software can disconnect the ROM (by flipping one bit) and route the last 16 KB of the address space to RAM. This RAM is often called "RAM under ROM."

 

The only problem is that interrupt handlers are pointing to routines in ROM, so when using RAM under ROM, a common (but not only) strategy is the following:

 

1. Disable interrupts

2. Disable OS ROM

2. Access data in the "RAM under ROM"

3. Enable OS ROM

4. Enable interrupts

 

P.S. This is not exactly accurate, as the area between $D000 to $D7FF is dedicated as I/O area and the RAM below the area never can be accessed.

Edited May 2, 2019 by baktra

[Wrathchild]

Switching in and out is controlled via PORTB

 

A usual strategy, when the O/S memory is swapped out and RAM visible, is to set the NMI & IRQ interrupts vectored through $FFFA & $FFFE respectively.

 

This is typically referred to as a 'minimal O/S', I'll PM you some details

[Yaron Nir]

Thanks both ?