Thread Rating:
  • 0 Vote(s) - 0 Average
  • 1
  • 2
  • 3
  • 4
  • 5
Error "4 Out of memory, 0:1"
#1
Hi to all,
I've completed a program which I'd like to fit into a 16K Spectrum using the lastest 1.8.9 ZXB version. After a long play, the program crashes returing an annoying "4 Out of memory, 0:1", this happens in 48K mode too.

I incuded a couple of libraries: attr.bas and screen.bas, got no string variables (all the strings are included directly in PRINT commands), so i set a low value for the heap: --heap=256.

The program starts at --org=24000 and the generated memory_map.txt file says that the heap starts at "7337: .ZXBASIC_MEM_HEAP" (29495).
The rest of my custom machine code starts at 30.000 and ends at 32767... so all seems at the right place!

Any idea about the cause of the damned crash, which happens after some minutes of normal and working play?! It seems something like an accumulation of data in memory which goes out of bounds, needing some kind of reset :-(
Reply
#2
The program should not crash that way if you don't use memory check flag.
Anyway it seems it's getting out of memory. If you're using strings, 256 might be too short for your program.
The other thing might be it's a bug in the compiler.

Please, send me your code privately if you want me to examine it. Perhaps I can help.
Reply
#3
...thanks Boriel, just sent a private message. No strings variables as you can see... just let me know if you need the menu asm and the rest of machine code (anyway this is the only file to be compiled at org 24000, the code from 30000 was written directly in assembly for menu, graphics and sounds).
Reply
#4
Just one thing: by default ZX BASIC does not crash by "out of memory" unless you're using the flag --debug-memory (use it only during testing phase before final release, to check for memory leaks o check for out of memory).

When ZX BASIC gets out of memory it silently starts to do weird things, even crash o reset, and not necessarily stop with "Out of Memory".
Are you sure your ASM calls are doing the right thing? (i.e. don't modify the IX register).

Also, you're using strings (SCREEN$, CHR$, STR$) along the program, but has tested them here, and they're all stable.
If you include the library <alloc.bas> you can get the free memory available calling the maxavail() function.
Reply
#5
...well the ASM calls inside the program are simple sound effects and a tiny custom "clear window" routine between the levels. Separately, there's an assembly intro menu including a couple of variables to change some item colours along the screen (but it's outside and detached from the main game).
I'll try to exclude the various ASM calls one by one to trace the problem, thanks pal.
Reply
#6
If possible use the function maxavail() and print the free heap memory while playing. This way you can check the free memory almost in real time.
Also, two more things: IX register is important for ZX Basic, so if you're not sure your ASM routines modifies it, better do:
Code:
ASM
PUSH IX
CALL YOUR_ASM_ROUTINE
POP IX
END ASM
on every ASM call

The other thing is that setting the ORG to low (i.e. 24000) leaves very very little stack space, and ASM calls, functions, SUBs, GOSUBS, etc might produce a silent stack overflow and the program might do those weirds things.
Perhaps this helps... :roll:

If you manage to solve, please tell us!
Reply
#7
Ok, consider that the IX register isn't a problem in my case, because the routines don't use it.
Instead, it's highly probable that the problem is about the low org address: I had the feeling that it was a STACK-related issue (there're many GOSUBs), that's why at the beginning all goes ok, and after reaching a certain score/level, it crashes (both in 16K and 48K modes)...

* * * SOLVED! * * *
Yes, my org address was too low! I pushed my routines a little further and I've nested some of them inside the character-set, finally I gained 710 bytes.
Now, starting at org 24710 the game works, no more memory issues :-)
Reply


Forum Jump:


Users browsing this thread: 1 Guest(s)