Why was it common to reference memory locations using negative numbers on some BASICs?

Question

If you had an Apple II, it was common in BASIC to reference memory locations above the 32K point by using a negative number. For example, if you wanted to click the speaker you would PEEK/POKE -16336 or if you wanted to enter the Apple II monitor, a CALL -768. Respectively, those would be 49200 ($C030) and 64568 ($FC38).

On the Commodore 64 by contrast, it was common to reference similar memory locations by their absolute value, e.g. the background color could be retrieved with a PEEK(53281) and many SYS calls were documented with non-negative numbers.

Given that many of the 8-bit BASIC implementations were derived from a common Microsoft code base, it is curious why the two conventions were used. I would have thought that it was perhaps something as simple as that a few cycles would be saved by specifying the negative number (or not, depending on who was right), but then again the negative sign introduces an additional character to process and also that big about common heritage.

What was the reason for the two conventions?

Answer 1

The difference between Applesoft BASIC and the other Microsoft 6502 BASIC derivatives can be explained by the fact that Applesoft BASIC was not the first BASIC for the Apple II; the first was Apple II Integer BASIC, in turn derived from Apple I BASIC, which had been independently created by The Woz. Integer BASIC supported only 16-Bit signed integers as a numeric data type, so no positive numbers beyond 2¹⁵-1 = 32767 decimal = $7FFF hex were available, necessitating the use of negative numbers for higher addresses.

When Apple adapted the Microsoft 6502 BASIC core to their machines to quickly meet the demand for a floating-point capable BASIC, they did some changes to the code base to somewhat increase source code compatibility with the (very different) Integer BASIC core. One of them was that they allowed (but no longer required) the use of negative numbers to represent addresses beyond 32767. It was probably just inertia that kept people using the old notation with negative numbers, that and the fact that e.g. CALL -151 for entering the monitor was easier to remember than the now equally valid CALL 65385.

Commodore, on the other hand, used the Microsoft 6502 BASIC code pretty much as-is for their early PET models and also for the VIC-20 and the C64.

Answer 2

In some BASICs integers were signed 16-bit values, so there was no integer higher than 32767. Thus, if you wanted a 16-bit value of $FFFF in an integer variable,you'd have to specify it as -1. You can see this in Commodore 64 BASIC V2:

X%=32767

READY
X%=32768

?ILLEGAL QUANTITY ERROR

That said, the C64 SYS didn't actually take an integer parameter; it appears to have taken a positive floating point number and done some conversion on it. (Or perhaps it didn't use the internal integer or FP formats at all.) Thus, not only can you call it with positive values higher than 32767, such as SYS 64738 to reset the machine, but you can't call it with negative numbers, such as SYS -798, as you could with CALL on the Apple II.

I very much doubt any of this was much about saving a few processing cycles; BASIC was so slow that anybody that concerned about performance would be moving at least part of his code to machine language, anyway. But especially without modern tooling a BASIC was a large program that was difficult to write, so developers would often take whatever convenient shortcuts came to hand based on what routines were available elsewhere in the code.

Answer 3

Long story short: some BASICs have "two-byte signed integers" all around, so they can work only with numbers between -32768 and +32767. Other BASICs have their own format of numbers (e.g. Sinclair's ZX Spectrum BASIC - it uses 5 bytes to store a simple integer, so it can be -65535..65535).

In the second case, it is up to the BASIC interpreter developer, which kind of number allows for PEEK, POKE and similar commands (e.g. SYS). There are some design decisions: convert FP to INT, or use only two-byte INT? Convert the negative number to 65536+x, or let it be? The reasons were quite subtle: shorter code, easy manipulating, lazy developer, human error, deadline upcoming, etc.

Answer 4

Because Microsoft BASIC didn't support hexadecimal constants until Revision 5 in 1981, and so early derivatives (Commodore, Applesoft, …) didn't either . It would have been more convenient and clearer to use the &h notation (or &, as used in BBC and Locomotive BASICs) had it been available.