QB compiled code uses rollover variables.

[Agamemnus]

...or whatever it's called.

I was reading this:

http://faq.qbasicnews.com/?blast=Plottin...enThirteen

...and decided to test it with this little program:

Code:

a% = 256
b% = 256
c% = a% * b%
PRINT c%
SLEEP

It rolls back to -32768 after it gets to 32767 and then forward to.. zero.

This code, then:

Code:

DEF SEG=&HA000
address% = x% + 320 * y%
POKE address%, value%

shouldn't work properly, since the address could be 0 or negative. I think it will work properly if DEF SEG is moved down a bit (or up a bit?), though.

[Plasma]

It works fine when your program is compiled because it is just treated as an unsigned integer. (Your "rollover" variables are called "signed" variables by everybody else.)

In fact, the signed value of A000h is also negative.

[Agamemnus]

ah. but then it wouldn't work with the LONG example, correct?

[Plasma]

why wouldn't it work...?

[Agamemnus]

because:

Suppose address is a LONG:


DEF SEG=&HA000
address = x + 320 * y = 319 + 320 * 199 = 63999
POKE address, value

Suppose address is an INTEGER:

DEF SEG=&HA000
address = x + 320 * y = 319 + 320 * 199 = 63999 = -1537
POKE address, value

----------

Hm... well, anyways, what does the signed value of A000h have to do with it?

----------

One of them must be wrong, and I say it has to be the integer one, because it doesn't make sense for the upper part to go first and then everything else:

5
6
7
8
9
0
1
2
3
4

Not very logical IMHO.

Now, this should produce the desired result, then:
DEF SEG=&HA000
address = x + 320 * y - 32768
POKE address, value

[Plasma]

63999 stored in a short integer, represented in binary: 1111100111111111

63999 stored in a long integer, represented in binary: 00000000000000001111100111111111

Both numbers have the same value when the short integer is treated as an unsigned value.

I don't know what you're babbling about...obviously you can try it for yourself and see that it works.

[Agamemnus]

However it's not 63999 it is, in fact, -1537 and 63999.

Isn't -1537 equal to 31231 as an unsigned integer?

[Plasma]

As a signed value, 1111100111111111 represents -1537. As an unsigned value, 1111100111111111 represents 63999. Since you can't have negative segments or offsets, QB uses the unsigned value.

(I don't know where you got 31231 from...)

[Agamemnus]

Hm..... ok. (I did 32768 - 1537). Screwy way it's all represented though..

So let me get this straight again: 0 signed is actually zero if it was converted to unsigned?

[Plasma]

It's not really that screwey...the msb is always the sign bit. Any 16-bit integer from 0 to 32767 has the same value no matter if it's treated as signed or unsigned, because the 16th bit is 0.