Why does the FRE() function in CBM BASIC v2 return negative values?

Question

On Commodore machines featuring CBM BASIC v2, the FRE() function to query the amount of memory available to BASIC returns a negative number when the result exceeds 32767 bytes:

This quirk does not exist on machines with CBM BASIC v4, v3.5, or v7.

I already understand, on a purely technical level, why a negative value is returned: the free memory is calculated as an unsigned 16-bit integer, but the FRE() routine interprets the result of this calculation as a signed 16-bit integer (which it goes on to convert to floating point). My question is whether this behaviour is by design or a bug. I don't recall any contemporary programming guides claiming it is a bug, and Commodore's own documenation doesn't refer to it as such. (The Commodore 64 User Guide, for example, simply says, "Note that FRE(X) will read out n negative numbers [sic] if the number of unused bytes is over 32K."

If this behaviour is by design, what benefit does it bring? Was it simply more expedient for the CBM BASIC interpreter programmers to have implemented it that way, or did they have some benefit for the end user in mind?

Answer 1

Whether that's a bug or just sloppy programming is hard to decide.

Maybe the designers needed to save some ROM space and simply decided that the main use case for FRE(0) i.e., you want to know how much memory is left, is when memory becomes tighter than 32k, which happens quickly even with smaller programs (so, "when you really need FRE(0), it will work"). On the other hand, it's pretty straightforward to convert the value into an unsigned integer, even from BASIC.

While initially it obviously is not working correctly and might be called a bug, over time it has transformed into an "accepted quirk".

Answer 2

I already understand, on a purely technical level, why a negative value is returned: the free memory is calculated as an unsigned 16-bit integer, but the FRE() routine interprets the result of this calculation as a signed 16-bit integer (which it goes on to convert to floating point).

Exactly. That's the way it operates.

My question is whether this behaviour is by design or a bug.

That might be up to interpretation. I might go with neither.

• It's not a bug, as the result is, as you know, a 16 bit unsigned integer.
• But, as you as well mention, all return value in (MS-)BASIC are float
• But (MS-)BASIC does not know unsigned integer, only signed.
• Thus, all conversion from integer views a given 16 bit value as signed
• Which results in all values above 32768 being converted into their negative counterpart

So while one can argue it's by design, as the language's function result handling is designed that way, I would rather classify it as accepted side effect.

(The Commodore 64 User Guide, for example, simply says, "Note that FRE(X) will read out n negative numbers [sic] if the number of unused bytes is over 32K."

Which supports that they simply did go along with that side effect.

If this behaviour is by design, what benefit does it bring?

Was it simply more expedient for the CBM BASIC interpreter programmers to have implemented it that way, or did they have some benefit for the end user in mind?

• No need for a special handling in conversion.
• No need for a function to do unsigned integer

and last:

• Consistency.

I wouldn't go that far to say they thought about it in an explicit way - MS BASIC development at that point was simply chaotic and Special-to-Type - but not adding a special conversion kept the value within the range of further processing.

This is especially important when comparing with other values originally thought to be integer, as in float -1 is not equal 65535, while in integer it is.