Jewel, XB256 and Stack Space

[SteveB]

UPDATE: Found out that it is CPU RAM missing ... Works when compiled with runtime in low memory!

---------------------

 

Hi,

 

I am writing a game and it works fine in XB256, but when compiled I get a "memory full" error. I suspect that is stack memory. I use 16 strings with 168 chars each, 2688 bytes to hold graphics data to be written with "VWRITE".  

 

I might be able to optimize my program if I only understood how much free space I have initially and what uses this memory. Right now I was optimizing for speed. I have plenty of CALL CHAR, I have lots of DATA statements ... 

 

How can I optimize ? When I load my program in XB, SIZE give me 8056 Bytes of Stack Free and it runs. When I interrupt then program it gives me 4411 Bytes of Stack Free, 3645 bytes less. That is almost 1 kb more than my graphics strings use.

 

Any hint appreciated!

 

Steve

Edited February 3, 2022 by SteveB

[senior_falcon]

When compiled, both the compiled program and any strings created live within the 32K memory. No strings or variables are kept in the VDP memory. Keeping them in CPU ram is much faster. But, as you found out, if you have a lot of strings a program can have enough memory when running in XB, but run out of memory when compiled.

 

If your program does something like this:

READ A$,B$,C$,D$ all four strings require space in the CPU ram.  If your program only needs them one at a time, instead of:

100 READ A$,B$,C$,D$

110 do something with a$

120 do something with b$

130 do something with c$

140 do something with d$

you could:

100 READ A$::do something with the 1st a$

110 READ A$::do something with the 2nd a$

120 READ A$::do something with the 3rd a$

130 READ A$::do something with the 4th a$

This way the compiled program only needs to reserve room for one string instead of all four.

[SteveB]

5 hours ago, senior_falcon said:

When compiled, both the compiled program and any strings created live within the 32K memory. No strings or variables are kept in the VDP memory. Keeping them in CPU ram is much faster. But, as you found out, if you have a lot of strings a program can have enough memory when running in XB, but run out of memory when compiled.

Now I understand why VWRITE is soooo much faster when compiled! Interpreted it is VRAM to VRAM, compiled it is CPU RAM to VRAM.

 

My game does a fast switch of patterns of up to 42 chars at once. I did a small benchmark program which resulted in:

 

	CHAR2	VWRITE
Interpreted XB	572	624
Compiled	3.623	22.210

 

It is the number of executions of a 7 char CALL LINK("CHAR"...) vs. CALL LINK("VWRITE"...) until a sprite has slowly moved across the screen.

 

Yes, it explains why I am running out of CPU RAM when compiled, using 2688 bytes as superfast *) pattern-buffer. And it finally explains, why I didn't find the word 'stack' in the compiler docu (but in the XB256 docu, which led me to believe I was out of stack memory).

 

Thank your for this insight! The whole VWRITE offers unseen opportunities...

 

Steve

 

*) I never ever used the word "superfast" when talking about the TI before using your tools!

[+Lee Stewart]

3 minutes ago, SteveB said:

Now I understand why VWRITE is soooo much faster when compiled! Interpreted it is VRAM to VRAM, compiled it is CPU RAM to VRAM.

 

That is not the only problem that slows XB down when writing to VRAM. The main problem is that XB sets the VRAM address for each VRAM byte written (at least, in most cases I have seen), even when the bytes are contiguous. To be fair, XB does not assume that it has expansion RAM so block copies are necessarily limited and it would have taken a lot more cartridge space to code it both ways for all contingencies.

 

...lee