Gigatron Hackers

That means you have run out of RAM.

If you un-comment line 5616 at the end of compiler.cpp and re-compile, it will give you a free RAM report at the end of the compile: What ROM version are you building for? You will save a substantial amount of memory if you build for ROMv5a like this: This leverages the CALLI instruction from ROMv5a/DEVROM to reduce the thunk that stitches code chunks together from 8 bytes per thunk to 3 bytes per thunk and reduces the GOSUB/GOTO overhead from 5 bytes to 3 bytes.

If you do this you should rename your file to include _ROMv5a in the filename, (and the same for 64k RAM, _64k), so a 64k RAM and ROMv5a specific .gt1 file would be named 'Something_ROMv5a_64k.gt1'; this allows users to know if it will run on their hardware.

Arrays by default are defined as signed 16bit, use % in the var name to declare arrays as byte only, (if you only need bytes).

Constant strings and constant arrays of strings should use the const statement, otherwise each individual string will allocate 96 bytes per string, (to allow it to grow in size, max string size is 94, 1 byte for length and 1 byte for delimiter): P.S. If all else fails, then you will have to start looking at the & and && optimisation modifiers, (start with & and work your way up to &&).

I was using V3
V5a reduced that warning to 1 item.

_runtimePath_ "../../runtime"
_runtimeStart_ &hFFFF
_arraysStart_ &hFFFF
_codeRomType_ ROMv3

'free string work area, (better not use any of the string runtime!)
free STRINGWORKAREA

You are still running out of RAM :/ Try printing out the free RAM list.

It says there is a block of 6408 free
I subsequently got the free ram block up to 11480 bytes by using const string arrays but still have the same address for those 2 variables

The code allocater has somehow gotten confused, can you send me your source code?

If so I should be able to work out the problem pretty quickly.

The other thing you can try doing is this: This will force the code entry point to begin at 0x8000; depending on how much code you have this may be good or bad. It will save memory as there will be less thunks, but if you have large data structures then code will run into data sooner rather than later, (compared to starting at 0x0200).

Beware, the code is very messy at moment as I just did a quick and dirty translation from asm to basic so far.
How do I send it ?

Sent you a PM.

Here it is zipped.
The fault move to L_NUMBYTES and Y in subroutine MODDLST in this version from me moving things around.

It doesn't compile to the stage where it runs out of memory over here, did you send me the correct version? There are many missing sprite .tga files, wrong constant names, loop label syntax errors etc.

Do you you have access to discord? You can run it in a browser and there is no need for a mic or headphones, it's just much easier to type and share files:
https://discord.gg/XywGzy5K88

I compiled it for ROMvX0, it still has the same 5 warnings, but now the bad memory allocation does not occur; also there is 17244 bytes free, almost 6kbytes more than ROMv5a.

Once I work out what the issue is with the compiler with ROMv5a, I'll let you know.