8

Sinclair BASIC doesn't have a FRE() function, which on other systems typically returns the number of memory bytes currently unused by BASIC. I'm looking for a way to find that value.

The system variables suggest some potential candidates. Variables such as PROG (=PEEK 23635+256*PEEK 23636), however, don't change as the size of the program changes.

There doesn't seem to be a way to do this in ZX80 BASIC, but maybe things changed with the expanded interpreter.

1
  • 1
    There is a FREE function in Timex BASIC, but that's not what I'm asking about.
    – scruss
    Commented 2 days ago

3 Answers 3

12

There's no value which you can obtain from BASIC alone, but if you inspect the memory map in Chapter 24 of the ZX Spectrum manual, you'll see a memory region marked "Spare" which starts at STKEND (at addresses 23653 and 23654) and ends at the Z80 stack pointer. If you are not too worried about the size of the CPU and GOSUB stack, you can pretend the top is RAMTOP (23730 and 23731) and from there get a reasonable estimate from BASIC. Untested but likely to work:

DEF FN f() = PEEK 23730 - PEEK 23653 + 256 * (PEEK 23731 - PEEK 23654)

[Edited to correct silly error pointed out by @the-busybee.]

0
1

The ZX Spectrum has no dedicated command to display the free memory still available to BASIC.

If you happen do have a ZX Interface 1, you can extend the ZX Spectrum's BASIC with user-defined commands - here (page 135) is a link to an article describing that. A listing is provided.

Once executed, the ZX Spectrum will know a new command "PRINT *" that prints the amount of free memory.

Obviously, that will only work on a ZX Spectrum in 16 or 48K mode. For later 128k models with bank switching, the definition of "free memory" is not exactly definite (some of the memory will simply not be usable for BASIC, but definitely "free").

2
  • 1
    looks like it's doing the same calculation as @pndc's RAMTOP - SPARE
    – scruss
    Commented yesterday
  • @scruss Yes, it does. But it's a BASIC command getting rid of the convoluted PEEKs ;)
    – tofro
    Commented 21 hours ago
0

That -41384 looks to me like a 16-bit unsigned number mis-interpreted as signed and hence the negative outcome of increasing a string length. BASIC peek() returns raw byte data (0..255) without interpretation. A 16-bit number like e.g. 0x8107 looks negative but things like memory addresses, memory amounts, stack pointer values are unsigned by nature.

New contributor
Ulrich Roos is a new contributor to this site. Take care in asking for clarification, commenting, and answering. Check out our Code of Conduct.
5
  • 1
    As it’s currently written, your answer is unclear. Please edit to add additional details that will help others understand how this addresses the question asked. You can find more information on how to write good answers in the help center.
    – Community Bot
    Commented yesterday
  • 1
    thanks! I'm not used to BASIC that get the sign conversion wrong. @Community - it's unclear because someone has deleted the comments that add context. I wish people wouldn't do this, but I'm sure I'll get sour looks from the pointsmaxxing crowd.
    – scruss
    Commented yesterday
  • A 16-bit signed integer has a range of -32,768 to 32,767. So -41384 can't be as you say. Why did you you choose to discuss that number anyway? Commented 17 hours ago
  • @scruss relevant details should be added to the question itself. Commented 17 hours ago
  • 1
    @WeatherVane - the -41384 came from my comment to pndc's (initially incorrect, now corrected) answer. It does not belong in my question, thank you. Confusion now exists because comments have been cleared away by someone (who? why?)
    – scruss
    Commented 16 hours ago

You must log in to answer this question.

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.