There is something wonderful about having a poor memory. Whether I knew something before or not, I do not remember it now, so I get the pleasure of “learning something new” even if I previously knew the new thing.

In a reply to my Color BASIC and octal post, Juan Castro mentioned another quirk about how BASIC sees numbers represented as decimals versus hex or octal.

AND, OR, AND NOT demand signed 16-bit integers as input, whereas the &H/&O expressions (and consequantly my &B extension) return UNsigneded integers. That is VERY annoying:

PRINT &H8001 AND &H0007
?FC ERROR
OK

Come the %#&*£ ON!

– Juan Castro

I am unsure about this, since after the parser reads through the code, it turns any hex or octal or decimal value intothe internal 5-byte floating point representation of the value. “A=65535” turns into exactly the same type of variable as “A=&HFFFF”.

AND and OR should deal with them exactly the same way. In Juan’s example, decimal values will generate the same ?FC ERROR. But there is a workaround…

I stumbled upon this when playing around with using AND and OR to set or test bits. My Color BASIC and 16-bits and AND and OR and NOT article explains what I was trying to do, and how I ultimately ended up achieving it.

In Juan’s example, &H8001 is 32769 in decimal. &H0007 is 7. Having the “high bit” (bit 15) set of the first value effectively makes it a negative number:

1000000000000001 = &H8001 (32769)
^              ^
bit15          bit0

Any value with that bit set will not work with AND or OR, regardless if you represented it in decimal, hex or octal. You can go up to &H7FFF (32767) using AND or OR, but past that, you get the ?FC ERROR:

Juan has been working on some BASIC enhancements, adding new features (like a method of representing values in binary — which I would find quite useful). But seeing numbers in binary not work would be even more frustrating:

PRINT &B100000000000000 AND &H1
?FC ERROR

…at least, that is my assumption about what is “&B” binary representation would do.

Here is how to make Juan’s code work:

PRINT (&H8007-65536) AND &H0007
1

Any value that has that high bit set needs to have 65536 subtracted from it, then you get the results you would expect.

But unfortunately, you cannot use AND to test for that high bit to be set ;-) so instead you have to do silly things like this:

V=&H8007
IF V>&H7FFF THEN V=V-65536
PRINT V AND &H0001

And it’s just that easy!

Though, if you print V, you will see it is a negative number, as you might have guessed. If you don’t need to PRINT V, doing something as simple as this will let you AND and/or OR on values that have the high bit set.

Yuck.

“Come the %#&*£ ON!” is right.

Until next time…