The case of the missing 4th Commodore BASIC variable (and the 5th byte) | Hacker News Reader

The case of the missing 4th Commodore BASIC variable (and the 5th byte)

masswerk.at

33 pointsmasswerk21 comments

The style is in the way of the content.

Which poses the question, what is the content? Compare the postscript.

I find it amazing just how hard Commodore crippled the integer type in their BASIC interpreter. Not only does it take 5(!!) bytes to store a 16 bit value, but it is often slower than the floating point version of common operations.

The standard length of 5 bytes has some advantages when it comes to looking up variables. But, I agree, integer is really more like a clamped float in Commodore BASIC. (However, integer array values are stored in just 2 bytes, each, hinting at it's really about traversal time.)

Commodore's software story was indeed a mess, going all the way back to the PET. The BASIC in question was essentially a development snapshot of Microsoft BASIC on the 6502. It's the same code base that would go on to become Applesoft about a year later. But where Apple was able to drag MS along via comparison to the (less featureful but FAR more elegant) Integer BASIC interpreter, Commodore just took what they got and shipped it. Then patched it as needed as they kept shipping new hardware.

You'd think this would have hurt them more than it did. But in fact the idea of an "Operating System" had limited real utility in devices this small. There just wasn't enough space to do much useful for the user, and all "real" apps and games ended up rolling their own versions of everything anyway.

The C64's primary interface to the software developer was a hardware interface. And as it happened that mostly worked just great (disk I/O excepted, of course).

Microsoft /did/ go back, once, for an updated version of BASIC-65.

https://www.pagetable.com/?p=46

Do you mean Commodore went back?

Oops, yes!

I wouldn't really put the blame for this on Commodore. The integer code for BASIC-65 is common across all the platforms that licensed it from Microsoft.

You might be interested in checking this out: https://github.com/mist64/msbasic

> So let’s have a closer look at her (blush) anatomy…

This is cringe and creepy. Although the subject is interesting, I really couldn’t read past that.

Sorry: a text in its actualization is the product of the cooperation of the reader and the text as written. (This is basic text theory.) So, I guess, in-memory structures are not for you, as this is a/the common term. It's true, the text highlights creepiness, both in a genre and the terminology, but don't shoot the messenger. Why is tech referring to such things as "anatomy" or "build"? (The apparent overlap just highlights an already existing semantic disposition. Also, you should have stopped long before this, when the male narrator was portrayed as without any empathy or interest but cold curiosity.)

This article’s technical content is excellent, but it’s ruined by the creepy analogy between DEFFN’s internals and a woman’s body.

ChatGPT agrees that some might see it as creepy.

I only read a bit of it myself, but I pasted the whole contents of the story to ChatGPT and then I asked simply:

> Is the above text creepy? Why or why not?

Quoth ChatGPT:

> […] The use of gendered language and the description of the "damsel in distress" could be seen as objectifying or stereotypical. However, it's also possible that the author was trying to use a playful or nostalgic tone that is common in tech writing. Ultimately, whether or not the text is creepy is subjective and depends on the individual reader's interpretation and personal values.

Please don't

The entire trope is creepy, the usual portrait of the male private eye detective as is the portrayal of his object, the "damsel in distress". (Mind that the "damsel in distress" is commonly an excess signifier in the setup hinting at something not being as presented, thus initiating the core story.) You can't have one without the other, and still stay true with cultural history of ephemeral narration. This is here further motivated by us encountering a phenomenon of distress in code, namely, in the anatomy (a common term for this) of a unified storage format for variables and an artefact found in this. Moreover, this is really a 1970s story (as is the PET 2001).

(I find it rather creepy that the portrayal of the male narrator, who is without empathy but for the curiosity for his object, should be ok and go without any notice. On the other hand, note the absence of any notion of violence, untruthful or untrustworthy behavior, etc, otherwise common to the genre. Which would probably also have passed the filter, which is again creepy in its own right. — In defense of the genre, these are really paper-cut, mechanical figures to enable the progress of the story and not human figures, at all.)

I found the whole start of the article very difficult to read. In the end I gave up trying to understand your words and instead looked at the data to find out what you actually meant. This article would be much better if you removed the whole Noir detective story bits.

"Specifically, Floats comes with a clean baby face, with no marks at all, fresh ASCII strings all over. Integer, however, is yet another character, marked by signs on both cheeks, and ol‘ Strings is known by a single sign mark on the second, right-hand side of his signature grin."

???

Mind that this builds on a previous article (linked), detailing the storage formats of Commodore BASIC, which readers of the blog will be already familiar with. It recapitulates that variables are two ASCII characters with the type encoded in the sign-bits of this byte-signature, in order to establish a common ground for filling a gap in this account.

Also, it's meant to advertise the respective tools of the emulator (something I'm not aware of having been done like this before) and to stimulate interest in the reader to conduct further investigations of their own. Hence, the "wrapping" (which, BTW, emphasizes that jargon is not that innocent.)

Well you did make me ask how the interpreter works in this area. So in a way your article did work.

Happy that it worked, somehow. ;-)

(Also, I've to emphasize, the apparent scandal is not related to gender. Just as a thought experiment: Humans tend to anthropomorphize objects they are interacting with. At this point, it becomes nearly impossible to relate to structure, if there is even the least resemblance, regardless of alleged gender. "He had a mark on the left of his two…", is equally scandalous as is, "she had a mark on the left of her two…". The scandal is more fundamental than this. Meaning, we can't express care for and/or interest in an object and address its structure at the same time, and still avoid this kind of scandal. Anthropomorphic terminology or jargon doesn't help.)

Understanding how DEFFN works is not the same as disrobing a blushing, helpless woman.

My objection is specifically about these three things in combination:

1) equating a code function to ‘damsel’, a gendered stereotype for a helpless women;

2) using phrasing that would most commonly be referencing disrobing and viewing someone; and,

3) having the characterization blush when doing so.

These three components taken together are not fundamental to all characterizations. They are specific, gendered, and offensive.

You are missing the fact that the scandal would be equally so, if this objectified any other gender and that objectification is the game of that trope/genre. And it's effectively not the only case of objectification in this text.

Reply on news.ycombinator.com