So maybe is not what you want if your environment is not BASIC. The map can vary if you use binary (ASM) program, with 4000-7fffh available (in that picture is shown as used by BASIC interpreter), or DOS, with also 100-3fffh available.
But, concerning the question, MEMSIZ could not have the highest one to use if not using BASIC. It would be good if someone knows about this.
If you are outside the BASIC environment, I guess that the highest address would then be HIMEM.
EDIT : indeed it is, according to MSX2 Technical Handbook
The lowest address of the user's area was different in the MSX1 machine whose amount of RAM was 8K, 16K, 32K, or 64K; in MSX2, it is always 8000H, because MSX2 machines have at least 64K of RAM. It can be obtained from the content of BOTTOM (FC48H). The highest address of the user's area when no disk drives are connected is F380H; when disk drives are connected (using DISK-BASIC), it depends on the number of disk drives or on the disk capacity. It can be obtained from the content of HIMEM (FC4AH) after reset and before executing CLEAR statement.
the easy tidy way
the interpreter works between BOTTOM and HIMEM.
move BOTTOM up to get a BLOAD zone.
10 poke &hf677,&hc4 : poke &hf676,&h01 : poke &hc400,0 20 run"loader.bas"
the pokes dont move things, need to RUN loader.bas, then in loader.bas you face the moved BASIC.
and then, after all BASIC action is finished, ld sp,(HIMEM).
note that the byte at HIMEM itself is owned by the system.
it is the habit of SP that the next push will touch bytes below that initial address told in sp.
similar BOTTOM is funny, it asks to be set to 8001 when BASIC is at 8000, and still it asks a 0 poked at 8000 else says error.
the interpreter works between BOTTOM and HIMEM.
means it randomly peeks pokes there.
if the interpreter is running, using any byte in that zone = one day comes the random crash.
if the interpreter is not running, available RAM goes from HIMEM downwards.
MEMSIZ it is one of the dozens unknown arytabs bells and whistles between himem and bottom.
but it seems to have a reputation, why.
because if you ignore that the SP is in a random unknown location, then MEMSIZ works better.
at the cost of loosing some random amount of bytes! "BASIC variables", who knows how much that is.
just one instruction, ld sp,(HIMEM) and the MEMSIZ story is gone.
and at that point you can think about how much stack you gonna use, instead having another unknown size "what BASIC happened to say in memsiz".
clear 200, address.
what this does is blindly poke HIMEM to that address. loosing the information about how far the disk area goes, no good.
with interpreter
-------------------- 8000 available RAM -------------------- BOTTOM ld hl,(bottom) : dec hl : dec hl is usable byte death zone :) -------------------- FFFF
without interpreter
------------------- 8000 available RAM <- SP hanging around somewhere, fix it ------------------- HIMEM ld hl,(himem) : dec hl is usable byte system ------------------- FFFF
I was wondering, how to return to Basic if you move SP to HIMEM, when executing from Basic or as a ROM?