Looking Back: PopFuncs

28 March, 2007. 1,275 words.

I thought it might be fun to review some of my earlier programming projects on this blog.

One of the first “major” applications I wrote for the Amiga was a utility program called PopFuncs, some time around 1988 (amazingly, I had just graduated from high school a year earlier). All this program did was sit in the background waiting for you to press a function key, at which time it would run a macro that performed some kind of action, like run a program or type some characters on the screen or minimize a window or something like that. It also had a built-in screen blanker. It was not the first of its kind for the Amiga, but I felt it had a uniquely easy user interface.

Version 1.0 of PopFuncs was initially written in C. At some point, however, the floppy disk (you read that right) on which the source code was stored became corrupt, and I lost the entire program. I then decided to re-write the program from scratch in 68000 assembly language and call it Version 2. (Early on, I jokingly referred to version 2 as “Lazarus Funky,” because it was a function key program that had come back from the dead.) I chose assembly language because I had not been happy with the speed and size of the first version of PopFuncs. Here is what I wrote back then on the subject:

“I was shooting for about 7K when I started this thing, but it quickly grew when I started adding additional features. The entire thing is written in Assembly, so it’s not as big as it could be. (Actually, my first version was written with Lattice C, and with only half the features it was 29K. Fortunately, the disk it was on corrupted and I had to rewrite the thing in assembly. That’s why this is 2.1 instead of 1.1)”

It should be noted that when I wrote “it quickly grew,” I meant that the PopFuncs 2.1 executable size grew to a whopping 16K. ("Lattice," by the way, was the name of the company that wrote the Amiga’s most popular C compiler. The company was later bought by SAS Institute.)

Young programmers are probably wondering why the obsession with executable size. Grizzled veterans already know this, but back in 1988, most home computers did not have hard drives, and an Amiga floppy disk only held around 800K of data (or something ridiculously small like that). Anyway, since there was no hard drive, most of the operating system software (not including the 512K Kickstart ROM) had to be stored on the floppy disk! Of course, back in those days, an operating system was actually an operating system, not an operating system with a thousand extra built-in applications. The point being that you could actually fit an operating system onto a floppy disk, with room to spare. But space was still obviously at a premium, so if you wanted a user to put your software on his boot floppy, it needed to have a pretty small footprint.

When I looked into the assembly source code for PopFuncs 2, I fully expected to find hideously ugly code written by an ignorant teenaged programmer. I was pleasantly surprised to find that it wasn’t all that bad-I actually documented what each function did, more or less, and I inserted useful comments throughout the code. The following is a verbatim copy of one function:

* Move the current active window to the back (as if user had clicked the
* window to back gadget).  This only works if the window has a window to
* back gadget.

window_to_back:
                push    d0/a0

                bsr     open_int

                bsr     get_active_window
                bcs     wtb_exit

* Got window address in a0, find out if it has a window to back gadget.

                move.l  wd_Flags(a0),d0
                andi.l  #WINDOWDEPTH,d0         ; depth gadget?
                beq     wtb_exit                ; no, can't depth arrange

* Now simply push the window to the back.

                int     WindowToBack            ; depth arrange it

wtb_exit:       bsr     close_int
                pop     d0/a0
                rts

While not terrible, it could still use some work. The function names (aka. subroutine address labels) are pretty obtuse (“open_int”? Only a former Amiga programmer would know that means “open the Intuition library”), and the “int” macro name is not very good, either. I always try to start functions and methods with a verb now, so it probably should have been “CALLINT,” perhaps in upper case to distinguish it as an assembler macro and not a 68000 instruction.

But if I were assigned to maintain that code, I wouldn’t have too much problem understanding what it does. Maybe I’m a little biased, though, since I did write it in the first place. (But then I’ve seen plenty of my old code that doesn’t make a bit of sense to me now.) I’d have to brush up on the 68000 instruction set again, though.

I was also struck by my program documentation. First of all, it had documentation, which right off the bat is pretty unusual for a rookie programmer. Second, the manual was actually pretty informative. It wasn’t Shakespeare, but it wasn’t bad, either: It was concise but clear (although it turned out I never explained what the program actually did). I noted that my technical writing style has not changed very much in the last fifteen or so years. I’m not sure if that’s good or bad.

Writing small utilities like PopFuncs was widely done by early Amiga programmers. I actually tried to make a little money with it, too. After I declared PopFuncs 2.1 “finished,” I made a stack of install disks with neat, dot-matrix labels, had a bunch of copies of the (again, dot-matrix) manual printed at the local Kinkos, and took them to a local Amiga user group meeting. I sold a handful of them for $10 each I think. That was my first professional programming gig. :) It was sort of like a kid’s lemonade stand. It’s too bad you can’t do that kind of thing any more.

Gosh, I sound old.

Back to the topic at hand. PopFuncs would later evolve into a version 3, but it was never released in that form, if memory serves. A fellow in Florida downloaded PopFuncs from a bulletin board (remember those?) and contacted me about including PopFuncs in a commercial package he was putting together, but that deal never came to fruition, and PopFuncs development stalled. It was my first experience with “business type people” trying to take advantage of my programming talent, a dubious practice which seems almost universal in the technology field. I eventually abandoned PopFuncs and created a whole new program called KeyMax, which was a greatly enhanced and expanded macro utility.

While digging around the PopFuncs development floppy disks (now stored on CD), I was surprised to find out that I had written a fairly comprehensive document laying out my design goals for PopFuncs 3. Today, it’s not at all unusual for me to sit down and spend some time planning out my software before I dive into it, but young programmers (me included) almost never do that. They usually just start coding at some random beginning point and go wherever The Muse takes them. Let that be a lesson to any young programmers reading this: Take some time to make a plan. And no, I don’t mean flowcharts. Personally I’ve always liked the idea of writing the user documentation before writing the program, although I admit I’ve never fully done that. I usually just sketch out the highlights. Trust me, your code will always be better for it.

Overall, I’d give PopFuncs a surprisingly good code review. Good job, young Tom!

Related