08-10-2022, 07:39 PM
(08-10-2022, 11:07 AM)boriel Wrote: The ramtop here does not make much sense: you're compiling your program to *machine code*! hence your program is already over the ramtop!
This is a difficult question as, for the moment, I'm still developing a linker to deal with memory allocation. The heap space starts at the very beginning of your program along with your variables. This is done to make SAVE "" DATA to work and preserve the heap and the program state (i.e. if you want to implement the feature of saving the game and resume it later).
The ramtop is, by default 32768 (non-contended RAM). Your program starts at 32768 with a jump (JP) over the HEAP. You can generate the assembly with--asmand see the resulting ASM listing.
Have you read this thread?
https://www.boriel.com/forum/showthread.php?tid=368 ("Using Beepola with ZX BASIC")
I used the term ramtop incorrectly, my mistake. What I meant to say was up to the memory limit, ie, 65535. I believe the ugds I use (including the bin files at a location defined by the compiler) should not be placed in the upper ram limit, therefore my music routines should be able to be placed between the hardcoded address and 65535. Is this correct?
From my understanding, using the contended RAM "only" results in slower code running at that location. So far my tests produce proper speed in gameplay (I actually had to slow the game down with a few "halts") to I think the memory for speed trade is favorable in this case. I may also probably move the basic code for the menus to the begining (at this point it's at the end) assuming it will compile in that order, therefore placing the pseudo-sprite routines above the contended memory limit.
I read the Beepola thread, and actually the last replies are mine. My workaround to joining the tap files is to hardcode the music bin file into basic, which supposedly should also prevent it from overwritting any other code or data when loading separate files.
For some reason I haven't figured out yet, when I tried to hardcode the 1162bytes long music bin @63800 it produced a tzx that would not work (can´t remember the error exactly, I'll try again and post it). I included the music routine @54200 and it's working now, but I'm not sure if it's restricting my available space in some way (my incomplete game is at the moment saved with org 24100, heap-size 2000, and is 36880 bytes long, so it's saving data after the music routine - I am not sure wheter it's the other bins - a few character/ udg sets and 1 1/3 monochrome screen images), or actual code.