So, it can work only with the trick of converting alphanumeric values because as i said above an hexa value cannot be directly interpreted as a no signed value. We therefore remain on the problem that I pointed out: we need to do calculation or conversion tips to resolve it.
@gdx, an hexadecimal number on MSX-BASIC is always an integer. Integer numbers in MSX-BASIC range from -32768 to 32767 (or &H8000 to &H7FFF, if you prefer). Statements like POKE and functions like PEEK accept any number in the range from -32768 to 65535, so naturally if you want to use numbers larger than 32767 with those statements and functions you must use another number type. If you mix and match number types you are bound to stumble on unpredicted behaviour.
For example, the VARPTR function is used, among other things, to find out the memory address of a variable. It returns an integer, and if that variable is stored on RAM (which is to be expected), then it will return a negative value.
When you simply multiply MEMSIZ+1 by 256 and add it to MEMSIZ you're actually converting it to an unsigned number. The solution presented by @pizzapower does exactly what you want: reads MEMSIZ and treats it as a signed integer, as it should since you want to use an hexadecimal number (also a signed integer) in line 20.
You are trying to have your cake and eat it too. You shouldn't have mismatched number types in lines 10 and 20.
So, it can work only with the trick of converting alphanumeric values because as i said above an hexa value cannot be directly interpreted as a no signed value. We therefore remain on the problem that I pointed out: we need to do calculation or conversion tips to resolve it.
No, we don't. There is no actual problem here just because you think that an address must only be represented by hexadecimal numbers. That's what's wrong. Take Commodore 64 for instance: it doesn't even allow hexadecimal notation in BASIC, so you'd just use decimal and move on.
Your previous problem was again of data type: 8-bit machines don't work with large 32-bit integers, but there is nothing new about that. What you are doing is mixing double precision numbers with integers but you cannot write single or double precision numbers with hexadecimal notation because they are of different data types.
