What does readable memory mean here - is it in fact the same as dynamic memory?
The terminology is confusing, I’m afraid.
“Dynamic memory” or “RAM” is addresses that the game can write to. “Readable memory” or “ROM” is addresses that the game can read from directly (with
@loadb opcodes) (or, if you’re reading I6 code, the
X-->Y operators). Beyond readable memory is code-and-string storage, which is only intended to be accessed by the VM when it executes code and prints strings.
If you give the I6 compiler both the
-z arguments, you can see more memory map information.
I should be more specific. In that output, the “readable memory” value is total of RAM and ROM. (Because you can read both, obviously). So in that compile, 3944 is the address where readable memory ends and code-and-string storage begins. If you look at the I6 compiler code, it’s literally printing a variable called
Just to add one note: the reason for the “readable memory” versus “high memory” distinction is that the Z-machine has a very limited address space (16-bit byte-addresses), and later versions of the machine couldn’t expand this space without changing some very fundamental properties of the machine, at which point you’d have to rebuild quite a lot of it from scratch.
The Implementors’ solution was to create a second address space, the “packed address space”, which is used only by the routine-call and string-printing opcodes. So you have 65535 bytes for all your addressable-data needs, and then a whole separate space to store your code and strings.
In the end, this didn’t work forever: the 16-bit address space limitation is too strict for most modern I7 projects, for example. So the bottom-up redesign of the Z-machine eventually happened, giving us Glulx, which uses 32-bit addresses (and nobody’s yet come close to hitting that limit).