earliest address to assemble to ?

[Wall_Axe]

whats the earliest address you can start a program on the spectrum?

with the assembler im using I was only able to go as low as 6000 in hex or 24576 in decimal. Giving about 40k for the program.
Anything below that gave a RAMTOP error.

a webpage online says the free memory starts at 23755


admittedly its only 1k difference but just curious

[NEO SPECTRUMAN]

16384

[ParadigmShifter]

It depends if you use the system variables (so, most ROM calls i.e. calls to below #4000, or any RST instruction) or not (and if you don't change interrupt mode, the ROM interrupt tries to use them, changing interrupt mode wastes 257 bytes of RAM usually). Also depends on the size of the basic loader that loads and runs the code.

Just use #6000 until you run out of memory, then worry about it.

EDIT: Using #8000 on 48K models until you run out of memory is a better plan since #6000-#7FFF is contended memory which is slower

[zup]

16384

Some games even had code there (i.e.: Skool Daze / Back to Skool while doing the countdown).

[TomD]

Worth noting if you use any peripherals like the Interface 1 so you can load from Microdrive you have even less room and may need to raise it further depending on the size of the basic program as mentioned by @ParadigmShifter.

The best and safest is to use 0x6000 and then use the area below for buffers with either a custom interrupt routine or disabled interrupts. I've also had compressed code in a higher memory location and then decompressed into this area post loading with interrupts disabled to get around needing the ROM for loading. You could also write a custom loader which doesn't need the ROM but that isn't helpful for modern loading from SD Card.

TomD

[ketmar]

changing interrupt mode wastes 257 bytes of RAM usually

commercial games used ROM as interrupt table, so could we! ;-) this way we only waste several bytes from #FFF4. ;-)

[Ralf]

16384

Or 0 if you are using Zx Spectrum +3

In practice, a standard game or other program has usually a short loader in Basic which runs proper machine code later so the first free space for your block of machine code will be around 23900 or 24000, after the Basic code.

You can reuse and overwrite the system variables area and Basic area later if you are never going to return to Basic but it will give you only about 600 bytes or so.

[1024MAK]

TLDR…
Assuming you need to maintain the area used by BASIC, what they said above

If you disable interrupts, or use your own interrupt code, and don’t make use of any of the ROM routines, you can use ALL the RAM. Even the screen memory if you really want to. On some of the later Amstrad models, that includes the entire Z80A address space, 0x0000 to 0xFFFF.

Mark

[catmeows]

Practical address Is 25600, that gives plenty room for disk system, microdrive etc. Many tape only games started on address 24200.
If you do not plan to use any mass storage or Basic, then you can go as low as low 23296.

[Seven.FFF]

Even if you want to use BASIC and/or printing early on in your loading process, once you have called into your machine code entry point with USR, you can reclaim the remaining space by disabling interrupts and calling LD-BYTES directly from machine code, to load one final headerless block over the top of the address range BASIC, sysvars and channel handlers were using. I am pretty sure this routine does not use IY, sysvars or printing.

LD-BYTES is compatible with divMMCs and flashloading emulators (but not, of course, with microdrives or third-party disk systems). It's a low level tape routine but it does everything you need and is hooked by everything that flashloads. The high-level SAVE_ETC routine is a lot closer to the BASIC LOAD "" and LOAD "" CODE routines, but that does use IY, sysvars and printing.

[Dr beep]

Up to 256 bytes the printerbuffer is a nice place to use.

[Seven.FFF]

On some models of Spectrums the printer buffer doesn’t exist and has been replaced with additional sysvars. Amstrad did not care much about backward compatibility with the ZX Printer. If devs are going to the trouble to play nicely with BASIC it’s worth making programs play nicely on all models.

This is starting to diverge from the OP's original question, but I think it's useful info. If you want to cooperate with BASIC and need some space, a safer option than the printer buffer can be calling BC-SPACES. You ask for a buffer of the size you want, and the ROM will allocate it and tell you the address to use. It can be called more than once if necessary, and after you return to BASIC the ROM will automatically deallocate it without you needing to do anything.

The editor and interpreter make extensive use of BC-SPACES while they are running. The workspace buffer sits just before the floating point calculator stack. The workspace buffer and calculator stack grow upwards and the machine stack grows downwards, into the same free space. So allocating space with BC-SPACES is a fairly cheap process that at worst only involves updating pointers and moving any data already on the calculator stack.

[SamC]

16384

0x2000 for an esxDOS dot-command