Hi everyone,

I would like to use the --debug-array option to check I have not used out-of-range array indices in my program. However, it appears that I need to give the compiler more information, to use the option in a program that passes arrays as function arguments.

For example, the following simple program appears to compile/ run correctly:

Hi

I have been trying to use the SAVE command to save the data whilst the program is running, i.e. SAVE "GAME" DATA
which I though would save all of the variables in the program?  *Save to Virtual Cassette tape*

And then I thought "All I need to do next is " LOAD "GAME" DATA 
and it would restore the entire game's data but it just crashes after it says "Bytes: GAME" 

I am sure there is something else that needs doing but can't recall this (80's memory is not as good as it should :-)  )

thanks in advance

Hi everyone,

I am relatively new to ZXBASIC, though think I have mostly got the hang of things and am using it to write a new game.

I am seeing intermittent Out of Memory issues (when compiling with --debug-memory), which I believe means I am running out of heap space. However, I've tried increasing the heap quite significantly (e.g., up to 8 kb) with little effect. I've also tried reducing the dependence on string arrays/ variables, in case this was the problem.

If I see an intermittent Out of Memory error mid-way through a program, long after most variables should have been defined, will it be heap-related or could it be something else?

Any suggestions for debugging my code, or properly sizing the heap, would be much appreciated.

Thanks in advance,
Georgeo.

Hi,

I wonder if someone could help me?

I have started writing a game but it uses a lot of String arrays.
The problem is I am compiling okay but on the screen things are missing where text should be.

I have compiled it using :-

Hi, I am looking at how to store a string of descriptions into an array.
Sounds straight forward enough, so should be something like

If you compile the following code 

FUNCTION A(text as STRING)

Print B("Test")

RETURN 0
END FUNCTION


FUNCTION C(text as STRING)
Print B("Test")
RETURN 0
END FUNCTION

FUNCTION B(text as STRING)
Print ("Test")
RETURN 0
END FUNCTION


you will get
inputmud.bas:137: error: 'B' is neither an array nor a function.
inputmud.bas:135: warning: [W150] Parameter 'text' is never used
inputmud.bas:144: warning: [W100] Using default implicit type 'float' for 'C'
inputmud.bas:144: error: 'B' is neither an array nor a function.
inputmud.bas:143: warning: [W150] Parameter 'text' is never used
inputmud.bas:149: warning: [W100] Using default implicit type 'float' for 'B'
inputmud.bas:148: warning: [W150] Parameter 'text' is never used


but moving function B above like below compiles okay

So I guess it's a TOP Down design where the functions in the same .BAS should be ordered

FUNCTION B(text as STRING)
Print ("Test")
RETURN 0
END FUNCTION
FUNCTION A(text as STRING)

Print B("Test")

RETURN 0
END FUNCTION


FUNCTION C(text as STRING)
Print B("Test")
RETURN 0
END FUNCTION



Great tool

Thanks
Ken

I have seen a problem where if you call a function without a RETURN 0 with no return value in FUNCTION declaration e.g.

FUNCTION UFNprintText(printText$ AS STRING )

Sometimes the function will just crash the ZX Spectrum emulator

Adding a RETURN 0 makes it work.

Just thought you might know this?

Hi, 

I have been developing a game and one of thing things I wanted to is build up a string and print it out but the issue I have is that I can't do the following code in zxbc :-

Is the FastPlot library really going to be faster than a compiled PLOT instruction? Since you've optimised your own PRINT implementation, I would assume that PLOT and DRAW compile to pretty lean machine code do they not? I did some very basic testing comparison of filling using DRAW commands versus looping through FastPlots instead and it seemed roughly the same. Is it perhaps that some libraries are old, and now the compiler is as good with native commands in terms of performance?

Is it normal that the entire screen scrolls every time I print at line 22 - not even filling the line? Surely it should behave like the other lines, no? Or else it's not much of an improvement over Sinclair BASIC's PRINT #0; AT 1,0;