Free HiMem after compiling XB?

[SteveB]

Hi 99ers,

 

we ran out of memory on our latest compiled XB game. We switched to "put runtime into low memory" and were fine. We filled the memory to almost the last byte. When we compile, we get a "4962 bytes remaining", as the compiled code is more compact than the tokenized, interpreted one.

 

How can we use these bytes? I could load additional level data with CALL PEEK from this memory, but I am not quite sure, which AORG I need to use on the assebler to put it there. Where do these almost 5kB reside exactly?

 

I know that RXB has an enhanced SIZE command:

 

I would think, that >A040 to >B3A1 is unused? The difference is exactly the value given by the compiler.

 

It doesn't look unused in the debugger ... or the values are relicts from previous usage.

 

Did I miss something or could we just AORG >A040, define the levels with 4962 BYTEs until we reach >B3A1, assemble and CALL LOAD? 

 

Any thoughts, hints and warnings welcome ...

 

Thank you

Steve

 

 

 

 

[RXB]

RXB has CALL PRAM(start-RAM-address,end-RAM-address) so you can tell XB to use.

 

>A000 TO >FFFF if you use CALL PRAM(-1,-24576) would use >FFFF (-1) down to >A000 (-24576)

 

This is part of RXB memory management routines and there is a command to move the VDP Stack to other locations.

CALL VDPSTACK(address) tells XB where to place the VDP Stack to a location in VDP normally at >0958

For example using TML you could do this before loading TML with CALL VDPSTACK(6176) would move the VDP STACK to >1820

Or CALL VDPSTACK(4096) would move the VDP >1000 from normal location >0958 to >1000 

Edited March 8 by RXB
missing text

[Cheung]

21 hours ago, SteveB said:

we ran out of memory on our latest compiled XB game

Any info on this game? Has it been released already or is it upcoming?

[SteveB]

It's coming up .. we hope to be ready by Eastern ... another eighties classic not yet on the TI ... now with some extensions. 

[senior_falcon]

On 3/8/2024 at 4:57 PM, SteveB said:

Hi 99ers,

we ran out of memory on our latest compiled XB game. We switched to "put runtime into low memory" and were fine. We filled the memory to almost the last byte. When we compile, we get a "4962 bytes remaining", as the compiled code is more compact than the tokenized, interpreted one.

How can we use these bytes? I could load additional level data with CALL PEEK from this memory, but I am not quite sure, which AORG I need to use on the assebler to put it there. Where do these almost 5kB reside exactly?

 

I would think, that >A040 to >B3A1 is unused? The difference is exactly the value given by the compiler.

I finally have an answer for you. You don't want to mess around with that area of memory. It is used for stack pointers, string variables, etc. much like the way XB uses the VDP memory.

But there is a way to add a block of memory that can be accessed by compiled code.

In the source code file created by the compiler (the file with the .TXT extension), you can add a block of code right after the ENDCC. Below is my test example, and this method works whether the runtime is in high memory or low memory, or if the program is loaded via XB or as EA5. You can find the beginning of the block in the compiled code by subtracting the length from >FF9E. In this case the block is 10+256+6 for a total of 272 bytes. >FF9E->110 is >FE8E and that is where the B in BEGINNING is. You can preload this block any way you want. CALL MOVE from XB2.9 is supported by the compiler, so you can move character patterns or screens directly to the VDP.

You want to be careful not to use too much memory and leave enough room for the stack to function.

 

Once you have added the block to the source code and it should be assembled and loaded as usual. The program can then be saved as an XB loader, EA5 or a cartridge and the data will be included as part of the program.

 

FRSTDT
LASTDT
       EVEN
       COPY "DSK1.RUNTIME5.TXT"
       COPY "DSK1.RUNTIME9.TXT"       
       COPY "DSK1.RUNTIME10.TXT"
ENDCC
    TEXT 'BEGINNING '  \
    BSS 256                            or        COPY "DSK1.YOURCODE.TXT"   
    TEXT 'ENDING'          /

 

       AORG >2008
       COPY "DSK1.RUNTIME1.TXT"
       COPY "DSK1.RUNTIME2.TXT"
       COPY "DSK1.RUNTIME3.TXT"
       COPY "DSK1.RUNTIME4.TXT"
       COPY "DSK1.RUNTIME6.TXT"
       COPY "DSK1.RUNTIME7.TXT"
EORT
       AORG >3FFE
       DATA EORT

 

 

(edited 3/10 for a simpler method)

Edited March 11 by senior_falcon

[SteveB]

Thank you!

 

I will play around with this and see, what I can do .. I will post a summary when done.

[SteveB]

So here are my findings ...

 

I wanted to have a static address, which I can rely on in my program and reserve 4 kB for my levels:

 

       BSS >1000                reserve 4kB space for level
       AORG >FF9E->1000         point to the beginning of the reserved space
       COPY "S:\classic99\DSK4\LEVELS.TXT" and include the levels

 

This way I could have an XB line

  adr=-4194  ! >EF9E base memory adress for levels

 

An encoded levels look like this in the LEVELS.TXT

       TEXT '0020d58Jk2P5cF5Ci8Ea79,'
       TEXT '1000jF5Ch4N5iWe9CbBPe9M,'
       BYTE 44

 

Then I have a "READ" replacement, to read a string from this area:

sub memread(adr,s$)
  s$=""
  call peek(adr,a) :: adr=adr+1
  while a<>44
    s$=s$&chr$(a)
    call peek(adr,a) :: adr=adr+1
  wend
subend

 

or if you are old-school XB:

31010 sub memread(adr,s$)
31020 s$=""
31030 call peek(adr,a) :: adr=adr+1
31040 GOTO 31070
31050 s$=s$&chr$(a)
31060 call peek(adr,a) :: adr=adr+1
31070 IF a<>44 THEN 31050
31080 subend

 

This whole approach has multiple advantages

• I can add new levels without rearranging memory until I filled the reserved 4kB
• I can use memory otherwise inaccessable when compiling XB

The disadvantage is, you can't really test this in interpreted mode. So the approach to do READ/DATA first and when everything works, replace the READ with the CALL MEMREAD above, seems to be a good mitigation.

 

Edited March 16 by SteveB