Look at the sample code on my previous post.

Look at my previous post. (I just added a remark about the wiki)

*gdx*wrote:

No and yes it depends on what point you focus. It not work when I use also integer or single/double precision.

Anyway thank for CVI. So the explanation from de wiki is wrong.

Where is it wrong exactly?

It's not wrong. I missed the CHR$() in your code. It's weird that this is the value that is returned.

L%=PEEK(&HF673)*256+PEEK(&HF672): PRINT L% return an overflow error. So it's not possible without use CVI. You should have said that from the start.

It was just an example putting the data types in evidence (because `CVI()`

guarantees to return an integer). Here, this will work anywhere:

10 L%=VAL("&H"+HEX$(PEEK(&HF673))+RIGHT$("0"+HEX$(PEEK(&HF672)),2)): PRINT HEX$(L%) 20 FOR M=&HC000 TO L%: PRINT HEX$(M): NEXT

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.

*gdx*wrote:

No and yes it depends on what point you focus. It not work when I use also integer or single/double

Yes, it works. It can either be two integers:

`20 FOR M%=A% TO B%`

or two floats:

`20 FOR M#=A# TO B#`

But you are doing this:

`20 FOR M#=A% TO B#`

Where your `B#`

is positive and doesn't follow the rules you laid out with `A%`

.

*gdx*wrote:

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.

The wiki's wording was pretty misleading. I've edited it.

Also, note that CVI() only works on Disk BASIC.