PEEK and POKE

For the time when it got out the machine even had some relatively good capabilities in terms of graphics, sound, and connectivity: the problem was that none of these functionalities was available from BASIC: in order to use sprites, for example, which were supported at the hardware level, you had to manually “PEEK and POKE” (BASIC for what we would call “load and store” now) bytes into memory-mapped registers, explicitly mentioning their numeric addresses. Even many mundane operations, such as changing the background color in text mode, could only be performed that way.

I still remember some addresses by heart. For example, this command changed the text-mode background to white:

POKE 53281, 1

The recommended way of resetting the machine via software was by jumping to a machine language routine in ROM, which happened to begin at the address 64738; from BASIC:

SYS 64738

Switching the screen to graphic mode and drawing wasn’t trivial at all; moreover there was no linear framebuffer letting you address each pixel individually: instead you could address each row in each 8x8 square making up the screen (40x25 squares), and play with bitwise operators to update the desired pixels in the desired row.

The arrangement of squares in memory wasn’t exactly convenient for graphics, either. The first 8x8 square in memory was the topmost leftmost on screen, and contained the eight-pixel rows indexed from 0 to 7; the second square, with rows 8 to 15 was the second from the left in the top row of squares; the third square in the first row of squares had rows 16..23, and so on up to the fortieth square; then started the second row of squares, and the forty-first 8x8 square in memory was the leftmost one of the second row from the top.

In practice you computed the row offset in memory, then you PEEKed the byte at the base address summed to the offset, twiddled some bits in it, and finally POKEd back an updated value.

In two-color mode each square row byte encoded 8 pixels; but in multi-color mode, a square row byte only encoded 4 “wide pixels” (two bits each, four colors), with halved horizontal resolution — Those were the official machine specifications; but as I learned many years later good hackers could push those limits by carefully playing with the CRT scan line timing, changing supposedly global settings at just the right moment to have them apply to a selected area of the screen only.

So, if a BASIC program was easier to read than an assembly listing in terms of arithmetics and control flow, many apparently “fundamental” operations still had to be implemented at a very low level.

If you didn’t know anything else then for you that was just the way things were, and you learned all magic numbers by heart without asking yourself many questions about alternatives. When it was the only way you knew it didn’t even feel inconvenient.

Procedures

One day I hit RUN STOP by mistake when running Halley. I saw BREAK IN and some line number, followed by the usual READY prompt and the blinking cursor. Of course I knew what it meant: apparently, Halley was written in BASIC.

LIST seemed to confirm the hypothesis: indeed there was a big BASIC program, which in theory I could have studied and tried to understand.

But very soon I noticed some strange commands in Halley’s source, whose names all began by the left arrow character “←”, for some reason: my English was still weak at the time but I could understand what “←LINE” and “←CIRCLE” meant: apparently they were graphic commands. I tried to run them interactively, and indeed they seemed to work. Yet I was absolutely sure they were not part of the predefined BASIC. I already knew how to draw a line and it was a much bigger pain than that, with all the square row offset computation and bit twiddling.

The new commands stopped working after a machine reset. This fact confirmed that they were part of Halley, which extended the BASIC language, providing new names for higher-level operations accepting parameters. This much I understood by myself, and for me it was quite a discovery. It was obviously the right way of proceeding: naming operations to be used more than once by a caller who may also supply parameters. I had discovered procedural abstraction.

As I only had two programming books I had read them many times, and I knew for sure that Commodore’s BASIC didn’t provide any way of defining named procedures with parameters; so I was sure that such definitions had to be performed in that fabled “machine language”¹. That day I still couldn’t write my own procedures, but I had been enlightened.

Identified the author

I don’t remember exactly the search query bringing me to the interview with the author Nemo Galletti — but after seeing that name my déjà vu feeling didn’t last long. I had finally found it: [2022: even if the original web site is now dead² the Internet Archive has a copy https://web.archive.org/web/20170613200832/http://www.ready64.it/articoli/leggi/idart/8/intervista-a-nemo-galletti]. It doesn’t look that hard to locate after the fact, and the interview dates back to 2008. Was the last time I looked for Halley really before 2008? I’m still not sure.

From the interview I discovered something interesting: the new primitives to which I owed my enlightening experience were “the famous Toma routines”: Galletti gladly acknowledges that he reused some graphical routines written by a Danilo Toma. Galletti seems very unassuming: he disclaims any particular competence in the field of astronomy, and dismisses the formulas he used as “easily available in specialized magazines”. This surprises me.

Identified the graphic routines’ author

Toma’s routines were published on a paper magazine in at least two versions during the Eighties. His routines, written and assembled manually into machine code (!), were extracted back from memory for publication as a long listing of DATA commands and a “commented disassembly” (!!). At the time there were good technical reasons for such a crude solution: the machine was too small even to host a reasonable assembler, without hardware extensions.

Something I was shocked to learn now after many years was that Toma’s routines actually supported 3D coordinates, and rendered in perspective; and of course Galletti made use of the third coordinate.

Looking at the code when I was young and without any documentation whatsoever for Toma’s routines I couldn’t understand the role of all parameters; anyway now I feel more than a little disappointed in myself for not having suspected at the time something that important. It’s clear now that back then I played a bit with circles, lines and points, but I was fascinated by the concept I had understood for the first time, rather than by that particular set of new primitives.

Some years later at 15 or 16 I also wrote my own procedures for rendering wireframe objects in 3D perspective like, I’ve just learned now, Toma did; my project had some interesting aspects and I should write about it sometime, but I think the thing in the end was slowish. And I used Pascal on a much stronger computer instead of machine language on a Commodore 64. No match.

You can find magazine scans with a long article by Toma including the listings for his routines (starting at page 35), and the software on a disk image: [2022: I replaced the link to the no longer existing ready64.it with a link to local copies]

• The magazine containing Danilo Toma’s article, starting at page 35: routines-di-danilo-toma/
• Halley as a PRG file, fixed by Ian Coog (9KiB): halley--fixed-by-ian-coog.prg

By the way, that is what was considered a “popular” publication at the time, not necessarily for the mathematically inclined; I wouldn’t call it too shallow or dumbed down.

Toma also seemed nice and unassuming; but except for what he wrote in the piece linked above and the occasional mention of “Toma’s routines”, I can’t seem to find anything about him on the Net; there is some information about a table tennis player with the same name and surname, but the athlete looks way too young to be the same person as the hacker.

A reminder for old-timers or an introduction for young spoiled kids: Commodore “BASIC V2”

The lack of primitive operations at a level higher than PEEK and POKE was not the only problem in Commodore’s BASIC.

That BASIC dialect didn’t leave a lot of freedom to the programmer: all variables were global, with names limited to a length of two characters. Since spaces in the source code consumed precious memory it was customary at the time to just leave them out, and for example write

120 FORI=1TO10STEP2:PRINTI:NEXTI

instead of

120 FOR I = 1 TO 10 STEP 2: PRINT I: NEXT I

As was the norm for home computer BASICs at the time, line numbers were mandatory and could not be replaced with symbolic labels.

The only conditional was a simple IF with fall-though control (no “else” branch), and a FOR..TO..STEP..NEXT loop (STEP was optional). As far as “structured programming” goes, that was it: if you wanted any other non-procedural control feature, you had to simulate it with GOTO.

There was support for a kind of crude subroutines, of course identified by line numbers only, which you could enter with GOSUB and exit with RETURN; an implicit call stack for BASIC routines was maintained for return addresses, but there was no mechanism at all to pass parameters or return results. And of course no procedure-local variables.

It was another world. It wouldn’t be fair to look at the programs of that time with our eyes of today.

And in Halley the “difficult” part seems perfectly reasonable, with data about each constellation neatly grouped in their own DATA section; there are comments. Control flow seems hard to follow to my now unaccustomed eyes, but how could it be otherwise? You worked with what you had.

No, I really have nothing negative to say about Halley’s source.

First epilogue

Some months ago, a supermarket in a lower-class suburb of Paris. The guy waiting in the counter line in front of me is a little unkempt, with a beard and a tired expression; around my age, he may resemble me somewhat.

He has only two items to check: a big pack of baby food jars, and a telescope.

(Do they sell telescopes here?)

He’s smiling.

Second epilogue

Here I am, finally again in front of Halley, now running on a virtual Commodore 64 as emulated by VICE, easily many times faster than the real thing even on my YeeLoong. And this is how Halley renders the sky of tonight, 18th September 2011 at 23:59, Paris latitude:

Tags: commodore-64, english, hacking, my-masters, myself, nostalgia, science