Link Roundup

For the most part, I use this blog as a way to talk about the stuff I’ve been working on. I’ll take a break from that today to link to things that other people have done that’s interesting or relevant.

I learned about some of these from Vintage Computer Festival West XII last week—other had come up as I was looking for information or materials for various projects.

RISC OS Stuff

Back when I started Project Mehitabel, one of the justifications for doing it was that a Raspberry Pi is a nice modern equivalent of old machines such as the Archimedes, which were modern enough to look like a modern architecture, but old enough that writing for them was very restricted anyway.

If your goal really was to build a “Super-Archie”, though, with the games to boot, but on modern hardware and a modern version of RISC OS, then The Archimedes Software Preservation Project is the forefront of that goal. This project negotiates redistribution rights to the old games, and then does binary transforms of them so they run on modern systems.

I’ve spot-checked a few of them and they do work, as long as you’ve got AnyMode properly configured. I haven’t, however, gone full into working with them because the filesystem module that it requires lists amongst its requirements…

RISC OS 5.23 Jun 9th 2016 or newer (must be High Vector, use a Nightly beta build. Do not use RC15)

That makes me think that I’d need to nuke-and-pave to get this going truly properly, but I’m not interested enough to do that. I’m also not completely sure what they mean by “high-vector” here, but I imagine it’s something to do with where, exactly, in memory software interrupt processors are mapped.

Apple II stuff

The chiptune music group 8-Bit Weapon has a new album out called Class Apples. There are some new techniques being demonstrated in this album: “Thanks to a breakthrough in Apple II audio technology from legendary coder Mr. Michael J Mahon we are able to push 8 bit instrument samples though the Apple II’s 1 bit audio output!”

That’s pretty interesting. I’ve discussed programming the Apple’s 1-bit audio output before, but that can’t make sound like this. I am pretty sure that the technique Mr. Mahon used was cycle-counting to achieve pulse-width modulation, in a manner not unlike the PIT technique I used in DOS. Some back of the envelope calculation suggests that if you can time your cycle writes perfectly you’d end up with 6-bit audio at best, but as we saw that’s still plenty good.

The album itself is arrangements of various baroque and classical-era songs, and I liked it. Give it a listen.

ZX81 stuff

Back when I was discussing assembly language programming on the ZX81, I had mentioned that the I, IX, and A’F’ registers were sacred to the graphics routines. There are several advanced techniques for exploiting this where the font patterns can be replaced on each scanline, sort of like Flexible Line Interpretation. Depending on exactly how you do it, you get different shapes available to you. (It seems that while you can remap the character data, you can never get it to actually point into RAM, so you’re stuck with graphical interpretation of whatever the ROM happens to hold. As a result, these techniques are generally called “Pseudo Hi Res.”)

Paul Farrow has managed to replicate these techniques to produce a full-scale game called Against the Elements, and then combined and enhanced the two techniques to produce a brand-new display system that let him actually replicate a bunch of iconic characters from ZX Spectrum games. (The Spectrum, unlike the ZX81, actually had full pixel-level control.) The technique is demonstrated and explained in his demo Celebration. The EightyOne emulator is the only one that seems to be able to make this work—sz81’s graphics emulation is not sophisticated enough to handle the new driver properly (or, for that matter, the pseudo-hi-res system Z-Xtricator uses).

That’s the kind of thing that you can get when you push the system as hard as it can go, far beyond its intended capabilities. The ZX81’s “graphics”, as originally designed, were just character displays that divided each character set into four squares and had enough font going on that they could represent all 16 combinations.

You can still do an impressive amount with that.

Bob’s Stuff has an extensive ZX81 page of the projects he had done over the years, and they are mostly demakes to the ZX81, with a few original games as well. They run at very satisfactory speeds and manage things like full-screen scrolling isometric graphic animations.

There really isn’t any substitute for careful design, and with that handy, you can work some real magic.

Commodore 64 Stuff

The first graphical MMO was a game published by Lucasfilm for QuantumLink (now AOL) called Habitat. Various editions of the game were released under various names in North America and Japan, with the other main name apparently being Worlds Apart. The code for the game had been recovered, and the two prime movers on the project—Randy Farmer and Chip Morningstar—spearheaded a community effort to get a world running again.

This project has now basically succeeded. A complete world exists and the community is live. As described at VCF West XII, “it will never leave beta” because as an open-source project it doesn’t have the kind of direct community management and engagement that the original project had, but it exists and it works and it even works on the original hardware.

Project Mehitabel: UnixLib and SDL

So far in Project Mehitabel we’ve been treating RISC OS as an isolated platform, with no real contact with the rest of the computing world.

That hasn’t really been the modus operandi of modern users of the system, though. A POSIX compliance layer called UnixLib has been in use for many years, and the community surrounding the OS has generated a reasonably comprehensive set of UNIX ports, of both apps and libraries. That’s usually not very interesting to me—that does really end up bringing us back into the world where we’re dealing with something that’s basically the modern world but less powerful and less convenient—but bridging the gap to that endpoint makes a nice endpoint for my RISC OS experiments.

As I had mentioned much earlier, the usual practice for RISC OS seems to be to rely on a cross-compilation system, but my attempts to set that up were unusually fragile, requiring a VM with a specially selected version of GCC installed to get the cross-compiler—and thus anything at all—to build. Even after that, I ran into issues with building the dependencies that I would need for some of the projects I wanted to try to compile.

So we’ll do it natively. One of the libraries that has a RISC OS port is the Simple DirectMedia Layer, aka “SDL1”. A number of now-open-sourced classic games used it for the graphics backend, and some of them have RISC OS ports as a result. Ultima IV is probably the most famous one that’s part of the standard packages right now, and it’s also the backend we used for framebuffer operations in The Ur-Quan Masters, and indeed it seems like it should be possible to get it running there. However, UQM is a very large project with a ton of files and wrangling everything necessary to get it to build natively on RISC OS isn’t very appealing.

So I will instead use “Target Acquired”, the SDL program I used as part of my portfolio pre-UQM:

This actually started out as a DOS game I wrote as a highschooler back in 1995, with some assistance with tooling and graphics from other folks on a local BBS. I do still have the original DOS code, but it was fairly obviously written at a point where my grasp of C was extremely basic. Some of the things I’d done were so silly they don’t even count as “wrong”—I clearly hadn’t worked out how Turbo C did separate compilation, so I #included all my source files into one giant main.c. Still, it did work, and the SDL port refactored away the most aggressively embarrassing parts of it.

After installing the development libraries for SDL, I took my original (UNIX/Windows) source and reorganized it so that the source code was all in c and h directories as the compiler demanded. I then needed to alter the Makefile so that it would be able to find the libraries, which uses a similar but kind of weird syntax:

CFLAGS = -O2 -c -ISDL:
LFLAGS = -LSDL: -lSDL -static

Static linking, followed by processing the result with elf2aif, would result in a binary that can run even on the old RISC PCs with 90s-vintage ARM chips—but that’s not actually the tricky part.

The issue here is that this old program assumed that it would be run from its own directory and had several data files it needed to be able to read and update in order to work right. As we’ve seen before, RISC OS isn’t really OK with this, and indeed the whole system only can have one “current directory” at a time, and the end user can change it at will. RISC OS applications were expected to be bundled, and to behave in certain ways in order to coexist peacefully with the rest of the system.

Below the fold, we’ll do just that.

Project Mehitabel: Graphics

The last three Mehitabel posts have just been about getting programs to run at all. Now that we’ve mastered that, let’s start actually accomplishing something. In this post, we’ll make a simple program that changes into a dedicated graphics mode and then uses every color in the old, dedicated 256-color palette.

Unsurprisingly, BBC BASIC has a great many useful primitives to do just that:

MODE 28
FOR i%=0 TO 63
  FOR t%=0 TO 3
    GCOL i% TINT t%*64
    RECTANGLE FILL (i%*4+t%)*5,0,5,960
  NEXT t%
NEXT i%

This produces a nice, if tightly-packed, color bar display:

Let’s step through this code a line at a time.

• MODE 28 sets the graphics mode that we want. This is roughly a low-grade Super VGA screen; the physical resolution is 640×480 and it supports 256 colors at once.
• The next two lines set up a pair of loops, an outer loop with 64 iterations and an inner one with four iterations. That will add up to 256 internal iterations.
• We then set the color we will be drawing with, based on our two loop indices. GCOL accepts a base graphics color from 0 to 63, and then an optional TINT from 0 to 255. However, only the top two bits of the tint value actually matter, so we multiply by 64 to get a useful value. The 6-bit GCOL value encodes the color BBGGRR, which each end up being the most significant two bits of each color in a 12-bit RGB color value. The tint’s top two bits are then the least significant two bits of all three color elements. The effect of increasing the tint is thus to add a bit of white to the color, but it’s always just a small modification and never overwhelms the actual 6-bit color specified.
• We then draw a 5 by 960 filled rectangle at the appropriate location.
• The last two lines just close the loops above.

There are two oddities in the BBC BASIC graphics modes here worth noting. The first is that each screen pixel actually has four logical subpixels within it. That’s why, despite being drawn on a 640×480 screen, our code seems to think its drawing to a 1280×960 one. That’s fine, though, because it means that 256 divides the logical space cleanly. The second, though this isn’t relevant to this display, is that the location (0, 0) is in the lower left, and the Y coordinate increases going up. This matches mathematical displays more closely, but it’s probably not what you’re used to if you’ve ever done framebuffer programming before.

Below the fold, we’ll start breaking this program down into more primitive operations and then translate it to C and Assembly language. Along the way, we’ll see how RISC OS compiler intrinsics work for system calls in C, and we’ll both exploit and struggle with some of the quirks of 32-bit ARM assembly language.

4th of July Special: Type-In Programs

One of the other things I’ve been doing lately is fiddling around a bit with old type-in programs. This has been amusing mostly because it’s a major part of how I learned to program in the first place. It instilled, by accident, much of the discipline that modern tutorials like Learn Python the Hard Way hope to instill on purpose: patience, precision in typing and reading, and a certain sense that inexplicable commands we echoed would at some point make sense.

But there’s a certain art that the modern courses lack, because the modern courses are explicitly instructional. Old type-ins needed to do something cool or useful to be worth the effort of typing in. The needed to be simple enough to type in that you either would not make errors, or the errors would become clear quickly. And, of course, they had to be actually correct. I must admit that a distressing number of actual published listings failed this last criterion, and that this is a major part of how I learned to debug.

The gold standard for type-in software on the Commodore 64, now that we can look over the era, is Compute!’s Gazette, collected in full on the Internet Archive. Sufficiently so, in fact, that I consider it to be very nearly out of scope; many programs published here could compete with full commercial offerings, and the BASIC listings were accompanied by a program that would compute a checksum of every line you typed in. It also included a program called “MLX”, which was a program for entering machine code programs as a raw series of bytes, with a checksum byte of every line you typed in. Compute! was very confident indeed in the correctness of what was printed. Those who learned programming techniques from Compute! learned it more from the articles surrounding the programs they typed in rather than the programs themselves.

I didn’t have the Gazette as a kid, though. Scholastic, Inc. published its own computer magazine with type-ins and article about games and hardware called Family Computing and offered subscriptions as part of its book club for elementary school students. Its programs were often simpler, since it was targeting a younger audience with many fewer needs, and also because it supported many different home systems. Most programs had to have six or more editions, so that cut heavily into the size of any individual program. It did not include any automatic typing checkers like Compute! did, though, so it often had to rely on other mechanisms. Usually there weren’t any, but programs with very large sequences of DATA statements often would compute checksums along the way and have the program error out if there were problems. (This is sound practice—Compute! itself used it to make sure that the proofreader program was properly entered.) For the most part, though, you just had to have sharp eyes and fingers as a young typist.

When I was young, I mostly skipped over the programs that were 90% DATA statements by weight. But I’m a faster and more accurate typist these days, and so when this issue caught my eye, I decided to enter in its flagship program:

The flagship program in this issue was a program that would draw a rendering of the Statue of Liberty and then play The Star-Spangled Banner. Unusually for Family Computing, this program actually shared most of its source code across all platforms. (This shared code was a gigantic block of DATA statements that stored vector information about its image of the Statue of Liberty in a platform-independent manner.) Then each platform had its own code for interpreting the vector information and then playing the music. For the C64, this was another enormous block of DATA statements. Most of that was sound data for the SID chip, but there was also a small machine language routine that it used to clear the bitmap display in a reasonable amount of time, POKEd into memory and then SYSed at program start.

Everything else was handled in BASIC, including this particularly impressive little block of code:

   80 X=A:Y=B:GOSUB 3000
   90 F=0:V1=ABS(C-A):V2=ABS(D-B):S1=SGN(C-A):S2=SGN(D-B)
  100 IF X=C AND Y=D THEN 150
  110 F1=F+V1:F2=F-V2
  120 IF ABS(F1)>=ABS(F2) THEN F=F2:X=X+S1:GOTO 140
  130 F=F1:Y=Y+S2
  140 GOSUB 3000:GOTO 100

The subroutine at line 3000 plots a single point on the bitmap display. That detail aside, this handful of lines is a complete implementation of Bresenham’s line algorithm. That is a very impressive feat of compact and effective code.

Well.

“Effective” might be too strong a term. The screen clears nice and fast, but the full display takes over ten minutes to actually draw, and it looks awful:

To add insult to injury, the rendititon of The Star Spangled Banner only uses one of the SID’s three voices.

Perusing the code for the other platforms, it becomes clear that the IBM PCjr edition was actually the one with the highest production values. It—like all BASICs that supported it—supplemented the vector graphics with three strategically chosen flood fills. It picked better colors for the display—green on grey instead of white on blue. And uniquely amongst the implementations, it provided a three-voice arrangement of the anthem.

There’s nothing here the C64 couldn’t do, if only we had a decent bitmap library and a minimally acceptable 3-voice music driver. Fortunately, we have just that. All I need to do is convert the string-based PCjr music code into numerical commands for my music driver, and implement the flood fill. The rest is just minor details.

The difference flood fill makes, though, is absolutely night and day. The garbled mess we saw above conceals an incredibly effective chiaroscuro-like effect:

That’s much more like it. Below the fold, I discuss what went into making the port.

Project Mehitabel: Assembly Language, ELF, and the binutils

Last time we got a C toolchain working on RISC OS on a Raspberry Pi 3. That worked, but it also produced a Hello World that was 3 whole kilobytes. That’s awfully excessive for the kinds of programs we’ve written around here. We should be able to do better with assembly language and tighter integration with the OS’s executable formats.

ARM Assembly language written for RISC OS was traditionally written with a number of tools, but the clone of those tools in the GCC SDK is called asasm. Its syntax more or less matches the syntax described by ARM’s own reference material. Here’s a RISC OS Hello World in that format:

        AREA    |.text|,CODE,READONLY

        ENTRY
_start
        GLOBAL  _start
        SWI     &01                     ; OS_WriteS
        DCB     "Hello, world!",10,0
        ALIGN
        SWI     &11                     ; OS_Exit
        
        END

System calls in RISC OS turn out to be very much like the ones in MS-DOS or Linux. Replacing the x86’s INT instruction is called SWI (SoftWare Interrupt) or SVC (SuperVisor Call). Unlike MS-DOS and Linux, though, where one register traditionally identified which call was being made and the actual interrupt vector itself was fixed, RISC OS has a ton of different SWIs exposed, and they provide a huge amount of capability. These SWIs command not merely I/O and the filesystem, but the entire GUI (which originally lived in the ROM chip). It’s a very different world.

Anyway, Hello World is tremendously simple on this platform. There’s a SWI for printing out a zero-terminated string. That string, for this call, lives in the code, just after that call, and then once it hits the zero it stops printing, advances to the next 4-byte word boundary, and resumes your program execution at that point. We do that to print out Hello World and then follow it up with another SWI that ends the program.

Each instruction is 4 bytes long, so the code we’ve written here matches our previous record for Hello World on MS-DOS: this is 24 bytes, 8 of which are code.

We save this listing as a file named hello2 in a directory named s, much like how we handled our C source. We can then build, link, and run it with no special configuration (the linker expects a symbol named _start by default, and that’s what we provided):

*asasm hello2.s hello2.o
*ld -o hello2 hello2.o
*hello2
Hello, world!
*

Very simple. However, the resulting binary won’t work by default on non-Pi RISC OS machines. The reason is apparent in our output window:

The linker is actually producing its binary in the Unix-standard ELF format. RISC OS Pi include a kernel module for reading and interpreting ELF binaries, but that’s a later addition. The native executable format was called the Acorn Image Format, or AIF for short.

Furthermore, this ELF binary is 754 bytes, bigger than our Linux example, even.

We’ll address all this below the fold. Along the way, we’ll make use of some of the dustier corenrs of the UNIX utilities for working with binary files—the binutils.

Project Mehitabel: C Defying UNIX

Last time on Project Mehitabel, we wrote some programs in BBC BASIC and ran them out of the Filer or in the ShellCLI mode that lives outside of the desktop. This time, we’ll make some programs that run as machine code, and run them in the final type of text interface RISC OS provides: the task window. There’s nothing fancy here in terms of code; we’ll just be writing Hello World

What you’re really here for this time is to laugh at my suffering.

The design decisions RISC OS made long ago, and the ways that the community around it addressed those decisions to interoperate with the broader world, all have very ugly sharp corners. We’re going to make things work here, but this will also largely serve as a demonstration as to why what development there is for this platform is normally done with cross-compilers.

Step 1: Prep work

The first thing we need to do is run the !GCC app. (App bundles in RISC OS are directories with exclamation points as the first character in their names. There’s stuff that needs to be in the directory too, but the general mechanism is not unlike app bundles in the UNIX-based macOS versions.) We navigate to it through the Filer first by clicking the SD Card image in the icon bar and then navigating through to the appropriate directory:

As a collection of compilers and ancillary data, of course, gcc is not really an app; running it does nothing obvious and leaves no processes running. What this has done is extended the execution environment so that when we go into command-line mode it will be able to find the programs we need, and those programs will be able to find the data they need. RISC OS is notionally a co-operative multitasking system like Classic Mac OS or Windows 3.1, but there’s a very large amount of shared OS state across all applications. By setting environment variables, every program will see those changes immediately. That will include our command line.

But we aren’t ready to fire up the command line yet. As you may recall from last time, when we were playing with BASIC, we were handed a chunk of 640KB of RAM to work with. This was not a quirk of BASIC; it was the OS that allocated that memory to us. We won’t be able to run gcc in 640KB. To address this, we’ll left-click the little Raspberry Pi logo in the lower right. This calls up the Tasks Window:

This gives us a nice breakdown of memory usage in the system, including the two applications that are already running. (“Pinboard” is the application that manages the desktop icons, and “Snapper” is the screen-capture utility I’ve been using to illustrate these posts.) The green bars are fixed. The red ones are not. We can grab the “Next” bar with the mouse and drag it out to give the next program we start a bunch more memory. 64MB should do.

That done, we then middle-click the Raspberry Pi icon to open its context menu:

Most things in RISC OS can be middle-clicked to pop up a context menu, and you’ll need to do that in most apps to get anything done. As you’ve seen, it’s not like there are menu bars in these windows. As the menu shows, we could also hit Ctrl-F12 to open a new Task Window instead. That makes sense, because F12 alone is what suspends the desktop to put us into a CLI. Task Windows are text-only CLIs that live in a text editor window and are fully integrated with the CLI. If you aren’t working with non-GUI graphics modes, this is usually the way you’re going to interact with command-line applications.

Cynical and/or paranoid readers will notice that Shift Control F12 does nothing at all related to command lines and in fact powers down the system as immediately as possible. Don’t fat-finger that control-key, kids!

Anyway, with the Task Window created, we can dial back down the “Next” bar, and confirm that BASIC is getting allocated way more memory than it was before, and that we can run gcc inside the Task Window:

Everything that we have done to this point has just been so that we can get the compiler to run at all. A lot of Unix ports fit uneasily into RISC OS’s operational model, but this is enough to make you long for the simplicity of EDIT.COM and the Turbo C command-line build tools on DOS.

But that work is done! Let’s write some actual code. This part is also incredibly alien to anyone that’s used pretty much any other GUI-based OS, including that one X11 window manager written and configured in Haskell that doesn’t believe in the desktop metaphor.

Strap in, folks. This is the part that isn’t supposed to be wonky and weird.

Demo Release: Coast to Coast

I recently collaborated with the musician Nick Vivid on a Commodore 64 demo named “Coast to Coast” that was presented at @-Party 2017. It seems to be traditional to do writeups of one’s demos after the fact, but even if it weren’t, I’d be doing one. I’ve held off until the actual first presentation, though.

The Effects Used

The core techniques used here will start out looking pretty straightforward. There’s some text scrolling at the bottom of the screen, and the main part of the screen is consumed by text scrolling down at one pixel per frame. Then the 8 sprites are being used to cover the top of the screen with an additional marquee of scrolling text. (It take all 8 sprites to do this while keeping each letter static within the sprite; X-expanded sprites are 48 pixels wide, and the screen is 320 pixels across. So you need 368 pixels of space to scroll over the screen, but 7 only gives you 336.)

There’s nothing at all exciting about the visuals on this effect if you’ve been following this blog, but if you’ve been following this blog you also know that single-line splitscreen is a bit harder than it looks. Back in 2015 I didn’t really deal with the problem of scrolling the color RAM, either. I don’t address that here, either; I was just careful about my choices of colors.

Things get more fun about 20 seconds in, when I reveal that I wasn’t actually using the technique I just linked:

At this point I begin scrolling graphics up the screen as well as a down-scrolling background. Part of the reason I stuck to the simple sprite text scrolling was to show that I wasn’t doing this the easy way with sprites; this is a purely textual effect. The trick here is that while it looks like I’m scrolling one scanline down each frame, I’m actually using a much simpler technique to scroll up two lines every frame. The downscroll effect is created by combining that with rotating the character graphics down three lines each frame.

Of course, to get the objects that move up to actually move up, I also had to “coarse scroll” the screen up by one character row every four frames. This was handled via the traditional C64 technique of double-buffering the screen, spending the intervening four frames copying over all the characters, and then updating the video-matrix pointer as needed. I had a little jump table that would let me generate the map I was scrolling through a line at a time, and threading values through that jump table turned into a little miniature scripting language. So that was fun.

I did end up being a little more clever than I perhaps needed to be there. I was writing this while Nick Vivid was working on his music, and I didn’t know how expensive the music update would be each frame. I thus ended up restricting my coarse-scroll effects to the bottom line and then a selected (and variable) column of characters on the screen itself. In the end, I think this probably was overkill, but better to do the work and not need it than the other way around.

Speaking of the music, I had very little to do with that at all. He worked on his own with his musicmaking tools, produced a very nice piece, and I asked him if he could export it so that it would run only using RAM over location $3FFF. (The graphics and logic all live completely within the first 16KB, even uncompressed, even at runtime.) That was easily arranged and all I needed to do from there on out was copy it into place and then call into it at appropriate times.

With all the pieces together, all I did after that was run it through the PuCrunch system. This essentially turns a C64 binary into a self-decompressing, self-running archive. The home page has been gone for awhile, and while the code is still out there on the Internet, The Wayback Machine is the only way I can link the original site. PuCrunch was unreasonably effective at compressing this program; it dropped in size from about 12KB to less than 6.

Challenges, Compromises, and Goofs

Graphically, the biggest issue that I had was that I really, really did not want to have to wrangle color memory with things scrolling in three directions at once. I set multicolor text mode once, filled the entire screen with a single color, and then designed everything else around that. This meant that my scrolltext color also had to be in the range 8-15, and also had to be exactly the color 8 above whichever color I used for the text’s per-cell color. I wasn’t allowing myself any slack in the display, so that means (as we saw in the original vertical scrolling articles) that the scroll text’s color values would be shared with the last row of displayed graphical cells. Our change in scroll values would force a re-read, but the badline would come too quickly for us to do any reassignment. So I stuck with solid colors, and red/pink produced a reasonably nice display.

Conceptually the biggest problem that I had was that just scrolling stuff is kind of boring. Since one of the other goals of the demo was to be the invite for SynchroNY 2018, and that particular party takes place on a train that runs from NYC to Montreal, the train theme was set in pretty early. Discussions with Nick Vivid while we were talking about progress sort of developed the idea of it being about traveling in general, and once “remote entry to @-Party” was decided upon as the best venue to release in, that also brought in the notion of travel as a theme. The demo was being written, roughly, between SF and NYC, and about an event that would travel from NYC to Montreal. That’s when I got the idea of running the city names as extra text from, and it wasn’t too hard to hit enough major cities on one route to fill the time the music took up.

Unfortunately, those cities aren’t on an actual train route. If you want to take a train from the West Coast to NYC, you need to start in Los Angeles. I used Interstate 80’s route to select my interstitial cities.

An additional goof, which fortunately was caught before release, was that I ended up bungling the copying of the music code into place, and as a result a full third of it was originally missing. I think the three most devastating bugs that emerged during development and testing all ultimately were single-byte errors.

Reception

At the actual compo, the demo placed second, coming in behind an extremely elaborate demo for the Intellivision that is the most impressive work I’ve seen on the platform. Comments on it after the fact can be summarized as “not bad for a first effort”, which is about where it belongs. I’m not using any incredibly advanced techniques here and I’m not particularly talented as a graphician, either—the part of this project I like the most is that with only one extremely arguable exception, I’m getting an “impossible”-looking effect out of this without actually pushing the system’s limits. (The exception is that I do have to compensate for some of the VIC-II’s slightly inconsistent behavior surrounding vertical split-scrolling. I think that can count as “compensating for a quirk” rather than “pushing the envelope.”) This also let me put a lot of the small, independent routines I’d developed over the years into a single coherent program, and that was nice too.

Downloads

Here is the disk image that was sent to the competition.