Sundry Sunday is our weekly feature of fun gaming culture finds and videos, from across the years and even decades.
A bit of an oldie this time, and in more ways than one, a four minute stop motion animation from Rymdreglage made with Lego bricks, from way back in 2009. It’s still great though! By “8-bit,” in this case, they mean specifically the Commodore 64 end of the swimming pool, especially as concerns the game International Karate+. Even though this video is 16 years old, Ryndreglage is still making videos now! Have a look for yourself if you like.
We’ve linked to Iftkyro’s work before here, he created the mystifying (if you know much about how the C64’s video hardware works) demo Nine, where a system that should only be able to move eight sprites around appeared to display nine. How was that done? As it turns out, with great difficulty, and not a little sleight-of-hand!
Iftkyro’s back with another impossible demo, Quondam Tunneling (4½ minutes, download), which appears to display an animated sequence progressing down a 3D tunnel.
In brief, the tunnel itself only has four frames of animation. The demo keeps multiple fonts throughout most of memory, which are flipped between every eight scan lines, that basically allows it to display arbitrary graphics with each character row. The C64 doesn’t have quite enough memory to do that with all the rows in the full vertical extent of the animation, so another trick is used, taking advantage of palette swapping and the C64’s multicolor mode to store two different possible rows in each font. The horizontal scrolling is done by moving the characters that make up each row left and right in a typical C64 scrolling way; vertical scrolling is done by adjusting which fonts are used as the raster line descends the screen.
Of course nowadays we have computers that can display largely arbitrary graphics throughout the whole screen. Processor power is great enough now that we can even do this in software, but additional to that most desktop hardware has powerful hardware graphics included. Even if you don’t have a bespoke graphics card, major processors from Intel and AMD include substantial graphics capabilities built into the CPU. Such is the power of these chips, it’s easy to forget how difficult these things were in the microcomputer era.
Essentially all of the consumer computers from the C64’s era, and many years before and after it, split the system up into two major parts, the CPU and the graphics hardware. The very earliest home computers, like the Altair and the KIM-1, didn’t have graphics hardware at all without substantial hacks, because they weren’t intended to display their output on a video screen. That was really the innovation that opened computing up to the masses. Until monitor or TV output was possible, home computers were basically little more than glorified calculators to most people.
Having the CPU and graphics chips interact with each other was one of the most difficult parts of the design of these machines. Consoles like the Famicom/NES could give each of these two parts what amounted to its own memory, which simplified system design and helped to make possible its graphics power, but it also meant that programming it was more difficult. You can see this in the glitchiness of some early NES hardware (like in Displaced Gamers’ recent video on the jack of NES Commando, as linked here).
To properly use the NES’s PPU, graphics changes could only be made at a certain time each frame, during “VBLANK,” a time when the PPU wasn’t actively drawing the picture. That limited what changes could be made each frame. There were some tricky ways around this, but they all involved adding extra hardware onto the cartridge, increasing manufacturing costs. Home computers used their tilemaps for text display, meaning tile changes had to be less restricted of timing.
This meant some weird compromises were needed. On the C64, the CPU and the VIC-II operated asynchronously, opening up the potential for bus conflicts if they both tried to access memory at the same time. The VIC-II actually has the ability to put the CPU to sleep when it needs access. The C64’s designers rated the consistency of the video signal as a more important priority than the chip’s processor itself.
Even if the graphics hardware could display arbitrary bitmapped images, manipulating them quickly was difficult. The C64’s bitmap screen takes up 8K of memory. At 1 megahertz, the 6510 doesn’t have nearly enough time to update every byte in one video frame. In the following generation of machines, the Amiga was a lot more capable, but through the use of specialized hardware, its copper with its flexible video modes, and its blitter which could move memory around more rapidly.
That explains why, as Iftkyro states, that Amiga demos can generally do this kind of tunnel effect, but the Commodore 64 requires using a very specific memory layout, and rapid switching between fonts and graphics banks, to do something that superficially resembles it.
People familiar with MS-DOS should be right at home, although some commands are different. (That’s because MS-DOS changed them; it was originally made as a CP/M clone.) One major difference is the absence, in this version, of disk directories. Instead there were up to 16 numbered “user areas,” each its own individual region on the disk, kept separate from the others. CP/M was an amazingly compact system, a single floppy disk could host a half-dozen compilers and have room to spare.
#2: Speeding Up PETSCII
Commodore BASIC was notoriously slow, but also feature-poor. A version of the same Microsoft BASIC that was co-written by Bill Gates himself, and was later ported to MS-DOS as QuickBasic. This page is a collection of different ways to speed up printing PETSCII characters, covering several optimization techniques, one of them, avoiding IF statements, being non-obvious.
Working on the Loadstar Compleat project has taken up a lot of time, so I keep trying to think of ways to use the things I’ve written for it here on Set Side B. This is the introduction I wrote (edited down to the history, mostly), and a shorter piece on the Eras of Loadstar.
A photograph of long-time managing editor Fender Tucker, holding a pipe in his mouth. (Fender is an adherent of J.R. “Bob” Dobbs, of the Church of the Subgenius.)
Loadstar was an incredibly long-lived computer magazine, distributed on disk, for the Commodore 64 and 128 home computers. It began in 1985 and its last issue was distributed in 2007, covering a span of 22 years. It had 250 issues of the main publication, 42 quarterly issues dedicated to the Commodore 128, and numerous side products.
About Loadstar
Loadstar was initially created at Softdisk, Inc. You might have heard of Softdisk as the prior place of work of several employees who left the company, founded id Software, and created Commander Keen, Wolfenstein 3D, DOOM and Quake. It’s possible that some of them might remember the Loadstar guys, but it seems doubtful.
Loadstar was distributed on newsstands up to issue 72, when it switched over entirely to mail-order subscription sales. Despite this reduced exposure, Loadstar soldiered on. Starting with #32, some issues of Loadstar contained two disks of programs and information. These issues became more and more common until, beginning with Issue 43, every Loadstar contained at least two disks until the end of its run.
Loadstar published lots of different kinds of programs! The Video Pro-Titler may still be of use today, if you have need of a simple character generator!
Issue 44 began the reign of Fender Tucker, who would helm Loadstar for the next fifteen years. Fender lent the magazine a distinctive style. He’d write editorials describing the magazine as originating in the “Loadstar Tower,” a wondrous place looming over its home town of Shreveport, Louisiana. (The magazine was actually produced in a basement.) He’d also write up the adventures of his nefarious alter-ego and musician Knees Calhoon, who was listed as the author of some of Fender’s own software. Under Fender Tucker’s guidence Loadstar flourished, and garnered a devoted community of users and contributors.
According to Jeff Jones, attitudes at Softdisk were that the company’s Windows and Mac products were the future of the company, but eventually the internet came along and dashed that dream. Softdisk continued along as an ISP for a time, but around 2006 its services were taken over by another company, and it’s now long defunct. During Softdisk’s later years Loadstar continued to support a large and loyal userbase, and didn’t cost much to produce, so it chugged along well into the internet age.
As Loadstar grew, so did its community, and the technology around it. While the Commodore 64 computer was discontinued in 1994, a thriving market of add-ons and upgrades sprang up to serve its users. Probably the most notable third-party producer of Commodore peripherals was CMD, Creative Micro Designs. While Commodore themselves had made expansion memory modules for the C64, CMD took their ball and sprinted way downfield. CMD made a disk drive accelerator (JiffyDOS), powered memory units that could serve as long-term storage, accelerator boards, and even hard drives compatible with the venerable 8-bit machine. Loadstar’s staff used many of these devices in its later years to help produce their magazine.
Loadstar had a symbiotic relationship for about four years with Commodore’s own publications Commodore Magazine and Power/Play. Some type-in magazines would offer a disk supplement, containing all of the software in an issue on a computer disk and saving users from the need to type them in. Commodore had an arrangement with Loadstar to serve as the disk supplement of their magazines. This deal lasted from around issues 11 to 61, and helped bulk out Loadstar’s issues with interesting software.
Early issues of Loadstar often hosted ports of programs that originally appeared in Softdisk. One notable series of these is the Alfredo animations, a sequence of programs that depicted the travails of a stick man trying to survive a dangerous landscape. See folks, the genre didn’t start with Adobe Flash! Long after its parent Softdisk Magazine closed up shop, Loadstar published two final, original Alfredo adventures, in two of Fender Tucker’s last issues, #197 and #199.
Loadstar never distributed the Commodore versions of GEOS, Berkeley Softworks’ surprisingly successful bid to bring a mouse-driven, icon-based, Mac-like point-and-click interface to 8-bit home computers, but starting with Issue 58 and throughout the rest of its run GEOS programs were a regular fixture on Loadstar’s electronic pages. In retrospect, GEOS was done much wrong. Seeing the way the wind was blowing, Berkeley Softworks attempted to bring their OS to DOS-compatible machines with GeoWorks, only to quickly be dismissed as a budget pretender to Windows’ throne. GEOS was far from the first, and certainly not the last, Windows competitor to be steamrollered beneath Microsoft’s hardball tactics. (See: CP/M, PC-DOS, OS/2.) Judging by quantity, Loadstar may be GEOS’ biggest supporter that wasn’t Berkeley Softworks or Commodore itself.
Another company that formed an arrangement with Loadstar was Quantum Compuer Services, which served the Commodore 64 community with an online service called QuantumLink. Several early Loadstar issues came with the QuantumLink client software included on one of its disk sides. (At least one of our included issues has a copy, now useless.) Quantum eventually released a similar service for MS-DOS-based computers, and renamed themselves to America On-Line.
“AOL,” as everyone called it, become a runaway hit. They would build upon its strategy of distributing their disks far and wide, first as 3 1/2″ floppies, then as CD-ROMs, and eventually DVDs. QuantumLink was left to languish and, after a long period of decay where users complained of unmaintained upload sections and unmoderated forums, AOL unceremoniously shut it down without so much as an archive. The later history of AOL is generally known: they bought out their rival CompuServe, AOL keywords were broadcast during daytime television, it was a popular early choice for a dial-up ISP, it became the most-used ISP in the United States, and they created a hugely popular instant messaging program (AOL Instant Messager, or “AIM”). Then they underwent a disastrous merger with Time-Warner that would be hastily undone, then obscurity encroached as first the internet, and then social media, made most of it services redundant. AIM, once thought unstoppable, faded and died as more people used their cell phone’s text feature. As of this writing AOL still exists, but it’s fallen far from the days when its iconic “You’ve Got Mail!” catchphrase became the title of a Hollywood movie, proving once again, truly: what goes around, comes around. Eventually.
The premise of this movie will certainly age well. BTW, the more you find out about the history of movies, the more you come to realize this happens ALLTHETIME.
The Eras of Loadstar
The Early Issues Loadstar started as a C64 counterpart for Softdisk’s self-titled Apple II magazine. Many of its earliest programs are ports of Softdisk software.
Commodore Magazine With Issue 9, Loadstar became the official disk supplement for both Commodore Magazine and Power/Play. The programs from those periodicals helped to greatly bulk out their offerings. The arrangement lasted until Loadstar issue 61.
The Rise of Fender Loadstar’s longest-serving overseer was Fender Tucker, a kind and genuine person with an engaging writing style. Fender joined up with issue 42, and starting with the next issue, Loadstar moved to two disks a month.
Jeff Jones, Loadstar 128 & Loadstar Letter Associate Editor Jeff Jones joined sometime between issues 49 and 55 and brought some additional technical know-how to Loadstar. In addition to touching up programs and contributing software of his own, Jeff was largely responsible for Loadstar Quarterly 128, their publication catering to Commodore 128 owners, and the Loadstar Letter, a print supplement distributed along with Loadstar.
Puzzle Pages Barbara Schulak’s first program was Jump, published on Loadstar #44, but starting with issue 60 Loadstar published a monthly puzzle section that became the magazine’s most enduring feature. From then, every Loadstar had a Puzzle Page until issue 163, but the feature continued, mostly monthly, until issue 197. Barbara Schulak wasn’t the only contributor to the Puzzle Page, and there were puzzles outside of it, but Barbara was its soul.
The End of the Newsstand Edition Issue 7 was the last issue of Loadstar 128 to be distributed on newsstands, and issue 72 was the last issue of Loadstar 64 to be buyable that way. For most magazines that would have been the end, but Loadstar still had 16 years of life in it, sold entirely through subscriptions, mail order sales, and later via the internet, a testament to the faithfulness of Commodore users.
The European Age At its height around 1991, Loadstar had around 20,000 monthly subscribers. Without the free advertising provided by newsstands, by 1994 that had dropped to around 5,000. As Loadstar reached issue 100 and long years passed, it became harder to find contributions from US subscribers. Meanwhile the C64 was still going fairly strong in Great Britian, and many of the games of Loadstar from this era have a distinct demoscene feel. Loadstar also published demos, and reported on Commodore hacking circles. Loadstar would also embrace the internet, and offer issues for sale by way of their website.
Dave Moorman’s Tenure The writing was on the wall. By 2000 Loadstar had about 1,000 subscribers left, too many to just abandon, but not enough to remain profitable for their then-meager staff. Fender handed the reins off to the worthy Dave Moorman, who kept it going to 2007. Moorman was a dogged manager, and went to lengths to keep the magazine full of items, including frequently reprinting software from the magazine’s glory days. While many of Loadstar’s prior stalwart contributors didn’t switch over, Fender himself still wrote for the magazine, and kept up with it until the end.
The Tornado In 2007 a tornado struck Dave Moorman’s house, and wrecked his Loadstar-making setup. While one more issue, #250, would eke out in 2008, the 22-year run of Loadstar, last remnant of the once-mighty field of computer software periodicals, was over. Loadstar had outlived all of its sister magazines from Softdisk (including its DOS, Windows and Macintosh publications) Softdisk Inc. itself, as well as Compute, Compute’s Gazette, Commodore Magazine, Commodore Power/Play, Ahoy, Run Magazine, Family Computing, Creative Computing, UpTime and DieHard.
(I have been reminded of the value of marketing, so I have to include the $15 Loadstar Compleat package I’ve put together with the permission of J&F Publishing.)
Jed’s Journey is a fun little Zelda-like game for the Commodore 64. If you weren’t a Loadstar subscriber around 1993 or so, you’ve probably never heard of it. It’s one of the many programs from Loadstar’s 22-year run, which I’ve put up for sale (with permission of J&F Publishing’s co-owner Fender Tucker) on itch.io, but the disk can also be found on the Internet Archive. (We talked about making Loadstar available to people back last month, here.)
Jed lost drawing straws with his villager friends, and so it’s up to him to do something about all the monsters infesting his world. The monsters move quickly and randomly, so fighting them is a mix of reflexes, strategy and luck. Clear a screen and you get rewarded with coins, and possibly a potion that you can save for later. The potion colors are green for health, blue for invisibility, yellow to be teleported back to the starting point, and red to clear all the monsters from the screen.
Jed’s world is pretty big. If you explore for a bit, you’ll find treasure rooms with lots of money inside, a place to pay for healing, buyable weapon upgrades and keys for purchase. It’s not known at the moment if there is a way to win at Jed’s Journey, but the fact that the locked doors must be leading somewhere important suggests that there is. To even have a chance of reaching the end, if it exists, you should make a map of the world, and I mean by hand.
Jed’s Journey makes use of a hardware trick, seen in some sprite-based video chips, to get free collision detection. When the C64’s VIC-II is drawing sprites on screen, if two of them would be drawn on the same pixel, it’ll note a collision between them, and note this fact in a register. There are quirks to this system though. On the C64, this is pixel-based collision detection, not using hit boxes, which might mean occasional misses for players used to hitbox detection. Only two of the possible three colors in a multicolor sprite set off the collision detection. And the collisions only register which sprites are colliding, not what they were colliding with, which sometimes means, when you kill one beast, two others that were touching each other onscreen elsewhere will also be considered slain.
Will someone finally finish Jed’s Journey after all these years? Will it be you? If you try it, please let us know!
The Commodore 64 has many great games, but it tends to be best suited for computer-style games. When you compare it to the NES, for instance, it’s usually for Japanese-made action games. In Japan, hundreds of programmers had the Famicom boom to get better at the platform, and the system itself has an entire off-screen area of the screen to use as a scroll buffer. The C64 only had eight pixels of scroll buffer. There were scrolling games on the C64, even fast ones (I point to Andrew Braybrook’s Uridium and Paradroid that show the Commodore at its scrolling best), but it’s just a fact that the Famicom/NES was just better at it, and it was a time when there were lots of scrolling games coming in out of arcades.
I would like to highlight a particular case where the C64 acquits itself fairly well: its version of Konami’s Salamander, a.k.a. Life Force in some territories.
There’s a ton of scrolling C64 games that don’t hold up well. Take Strider, for instance. It tries to be a lot more like the arcade game than the NES version, I’ll give it that, but at the cost of all of its bosses, most of its speed, and it doesn’t even end very well, it just stops, feeding the player a line about having passed a test. Urk! If you want to see what I mean, have a look (11 minutes), but frankly why would you want to?
Here’s C64 Strider, but if you’re played the arcade version it’ll only make you sad.
There are good arcade, and arcade-style, games on the platform, and when they’re done well they can make the platform, quite literally, sing–the C64 has a terrific sound synthesizer chip. Ghosts & Goblins is often held aloft as a good example of a good C64 conversion, but although it has an iconic song, it only has one song, it’s not the classic tune from the arcade game, and it’s only got four levels. It plays a lot more smoothly than the NES version (7 minutes), but c’mon, Micronics made that one.
It runs at a good frame rate, has a great and spooky tune, and it manages to load four levels into the C64’s RAM at once, but it’s missing the last two levels and its two major bosses. And yet, it’s still a technical feat on the C64. BTW, there’s a 2015 port of GnG to the Commie (download) that’s better than the NES version in just about every way.
The C64 version of Life Force also only has four levels, but they’re very remarkable levels, impressively like the arcade game. It has a different tune for each stage! They actually sound like the arcade game! And one of the levels is the “Prominence Stage,” the most eye-catching part of the arcade and NES games, and it holds up (11 minutes), the flaming solar surfaces are animated, and the solar flares are just as deadly as in the other versions. It even exceeds the NES version in a couple of ways: your ship tops out at three Options instead of the NES’s two, and the Ripple and Laser beams are impressively flicker-free, since they’re drawn with background tiles, a feat the NES has trouble duplicating due to its background tile drawing limitations.
Is it equal to the NES version? Well… I can’t say that it is. And the Famicom version lets you have three Options, so the C64 version loses ground there too. But look at it! For the levels it has, the C64 really does its best to match the arcade. (If you’re surprised that the second level is different, the Famicom/NES puts the vertical mountain level there; the C64 sticks more closely to the arcade game, where the second stage is an asteroid belt.)
So even though the C64 port is about as good as you can expect from a 1983 computer with only eight hardware sprites, the Famicom/NES port is also great. Oh well, C64 users can content themselves to having a much better version of M.U.L.E., the NES version stinks.
This is something I’ve been trying to make happen for some time. But then some work I put into it hit an unexpected snag (the maker of a library I had been depending on decided he wanted to be paid a subscription fee to use it or else he was going to put a nag screen on people’s projects), then other things came up, and so the project languished for months.
This isn’t the first time I’ve mentioned LOADSTAR in these pages. The magazine’s name came from the commonly-entered command on Commodore 64 computers LOAD”*”,8,1, to load the first program on disk into memory, and sometimes also to run it. LOAD”(star)”, you see. I packaged one of its programs, Dungeon, for sale on itch.io for $5 some months back and mentioned it here. This is an opportunity to get the collection it was drawn from. I recognize this is a bit self-serving, but I don’t do it very often, and there’s so much on LOADSTAR that the world deserves to know about. The price of $15 is because that’s what Fender has always sold it for. The issues can also be gotten for free elsewhere, yes. This is mostly an opportunity to get them all at once, and with the Fender’s approval: the person most responsible for all of it, the driving force behind it, the one who always believed the most in LOADSTAR, its very heart and soul.
I had been working for an explorer program for getting the contents of issues and searching through them without having to load each issue individually, but it had been stymied by the issue I mentioned in the first paragraph. Something else I’d like to do is supply an emulator that will run the issues directly, with sensible defaults. The version that’s up has an absolutely ancient copy of VICE for Windows with it. It’s so old that I’m not sure if there might be security issues with it; I should probably just remove it. In any case, current versions of VICE are available for many platforms and are free and open source.
To start an issue, you first start up your copy of VICE. The Commodore 64 emulator included is x64, or else x64sc; the Commodore 128 emulator is x128. Under the File menu, choose “Smart Attach…,” then pick the issue from within the LS64 folder for Commodore 64 issues, or LSQ128 for Commodore 128 issues. Make sure to click the Autostart button: it’ll load the Presenter program and run it automatically! You’ll find both 1541 (*.d64) and 1581 (*.d81) disk images. 90% of the time you’ll want to load the 1581 version, because those disks were much larger and a whole issue could fit on one of them! The 1541 versions (which while growing up I had to put up with) are split up into four disk sides, and are a hassle. By the way: the 1541 disk drive was excruciatingly slow. If you press Alt-W, you can toggle “Warp Mode,” which will speed up loading greatly! Just be sure to toggle it back off once your program has loaded!
And something the collection really needs is a list of highlights of interesting things on each issue, and also a directory of the people who made this unbelievable wealth of software. Here’s a few names to watch for: Jeff Jones (Assistant Editor), Barbara Schulak (Puzzle Maven), Ian Adams (Mathematician), Maurice Jones (Card Game Implementor of Great Skill), Jim Weiler (Third in Command), J.C. Hilty (BASIC Game Programmer who never let it get him down), Nick Peck (Creator of A Couple Of Awesome Games), Jon Mattson (General Gamesperson) and Walt Harned (Pixel Artist Extraordinaire). If I could affix all their names in the stars for the world to see forever, I absolutely would.
To construct the itch.io page I needed some screenshots, so I dipped into a few issues to make them, and got the names of their makers along the way. Here you go, but understand this is only a tiny fraction of what’s included.
Zorphon by Nick Peck, from LOADSTAR issue 39. A rather polished space shooter! The aliens are drawn using character mode. I like the classic Astrocade-like font for the text.Pipe’s Peak by Bob Blackmer, from LOADSTAR issue 73. It looks like an action game, but I think it’s more of a timed puzzle?Outpost by Thomas Czarneki, from LOADSTAR issue 60. A fairly blatant Missile Command clone, but it’s well polished. The opening menu asks if you want to play to lose, or play to win. I think the difference is, playing to lose starts you on Wave 7.King’s Ransom by Scott Elder, from LOADSTAR issue 68. An interesting little game, you control a greedy king trying to scoop up coins before they fall into the lava. When a coin falls off the bottom, a gush of lava shoots up! There’s also skulls to avoid. In one of those little touches that you sometimes find in LOADSTAR software, if you wait on the title screen you get to see a hi-res illustration of the gameplay.Quadrilation by Dave Johannsen, from LOADSTAR issue 68. A two-player game, playable against a computer opponent with four difficulty levels. Take turns placing your pieces so they overlap with as many squares of the same color as possible.Stream, hi-res art by prolific Commodore 64 artist Walt Harned and included as part of The Compleat Walt.
(That’s plural for Balatro, a Latin word for buffoon.)
Funny, I thought I had made a post about this, but it doesn’t seem to have saved. Well, I’ll try it again.
Everyone knows Balatro now right? It’s won several awards, and was nominated for a handful of others. It was also developed entirely by one person, LocalThunk, who, gasp and shock, seems to be a decent person. And it was written in Lua for the LÖVE framework.
What’s more, there’s now several ports of Balatro for unexpected platforms. I presume they aren’t all entirely faithful to the original, but it’s fun to see how others iterate upon the theme.
Oh wow, for the Commodore PET, and before you ask, this is the best that system can do, it had no color, only beeps for sound and its graphics were locked in ROM:
The Playstation Vita and Apple Watch also have ports, with varying degrees of fidelity to the original. Note that the PET and Apple Watch versions don’t appear to be public yet, and may never be. The Watch one particularly looks difficult to play.
Grey is what the subject line says: a FPS, running at an acceptable framerate, on a Commodore 64, without a Raspberry Pi or other hardware to help it out. Here is its thread on Lemon64. Have a look (24 minutes):
How is it possible? Well, it’s not running 60fps for one. Updating the whole screen in one frame on a C64 is hugely challenging, but fortunately FPSes can look satisfactory running at slower framerates. It’s not Quake-level graphics, or even Doom, it’s more like Wolfenstein 3D in ability, and it’s confirmed that it uses that style of raycasting. And on top of all of that, it doesn’t use hi-res resolution, which would be really slow on an unmodified C64. It seems to use character tiles to fake a kind of low-res display. But when you’re trying to get a game running on a 1 MHz machine with 64K of RAM, tricks and shortcuts are not only necessary, but rather laudable. What a hack!
This is a work-in-progress, with a demo of the game available in a recent Pateron-available issue of Zzap 64. No source code is available yet. Let’s hope for continued development!
A few weeks back I mentioned Dungeon, a Commodore 64 CRPG system created by David Caruso II and published in 1990 on the disk magazine Loadstar. We’ve made it available through emulation on itch.io for $5. It’s here, and it’s awesome. It’s not just a way to play CRPG adventures but to make them yourself, and it even contains a random dungeon creation feature.
Dungeon’s map editor
I make it available with some trepidation. Dungeon has a few significant bugs. For example, it supports two disk drives throughout, but if you use its Dungeon Maker then you need to set it for single drive mode, or else you’ll encounter a Disk Error just at the worst possible time: when saving your project. Its randomized “Lost Worlds” often create dungeons that strand your character in impossible situations, and while there is a way out of them, it involves loading the Guild menu 15 times.
But I’ve played a lot of these random dungeons, and I think overall David Caruso II made a clever little game system, and I think his ideas are worth building upon. That’s why I’m working on a remake/update of Dungeon, that I’m calling Dungeon DX.
I’m making it in Python using the Pygame library. I’ve tried making a game with Pygame before and had some problems with it (I may bring myself to talk about that experience someday), but using it now I’m pleased to see Pygame 2 has become a lot more performant, and that’s even before trying to compile it into a faster form. I’ve built for Dungeon DX a kind of bespoke terminal emulator, but one with support for loads of cool graphics effects. I’ve made dungeon art and monster images for it using the website Fontstruct, which gives the images a low-tech, but distinctive look.
A collection of monsters, in font form, still being worked on. They’re reminiscent of the monster silhouettes from early editions of Call of Cthulhu!
I’ve been working very hard on it, to the extent that I can feel myself getting my hopes up that a substantial number of people may actually play and enjoy it. Most of the times in the past that I’ve done that I’ve had those hopes get crushed, but hey, maybe the nth+1 time’s the charm?
Besides not having all of its bugs, why do I think this project is worth working on? These are the things I find appealing about the original Dungeon, the reasons that I played so much of it myself, things that I don’t generally see in CRPGs these days:
It’s not a game but a game system. It isn’t a single huge campaign that you play and finish, and it isn’t a single story. Your characters can keep going so long as there are adventures to be had.
In structure it isn’t like a novel, but it’s more like a series of short stories. Each dungeon is a single screen, that fills out as your character explores it. That may sound a bit like a classic roguelike, and there are some elements of that, but the feel is subtly different. Each single-screen dungeon usually has more adventure packed into it than in a single roguelike dungeon level.
It’s like a collection of short stories, but that stars your character as they progress through it. The focus is more on the development of that character as they continue their adventuring career. Like how the Conan the Barbarian novellas are each an episode in the life of a single adventurer.
It features what’s known in some circles as slow character growth. D&D has rapid growth, and it’s gotten even faster as the system has changed through the years. 5th Edition characters advance to second level absurdly quickly, after earning only 300 XP, and that advancement practically doubles their power! 0th-level Dungeon characters (it starts counting at 0) have a lot more durability, but it takes them more time to advance to Level 1, and when they gain it their power only increases a little. In this, a lot more of a Dungeon character’s life is decided at character creation. But it also means, as they increase in power, you know it’s due to your own efforts.
It’s more simulationist that CRPGs have become as of late. A lot of CRPGs have crept towards gamishness, which generally is okay, I mean they are games after all. But I think RPGs work the best when you can imagine them as being the adventures of real people, so as their power has crept up, and their abilities have gotten more abstract and arbitrary, they have come to feel more and more like playing pieces than living people.
While there’s a random dungeon maker, you can also make your own adventures for it, and give them to other people! That’s potentially a very great thing. It reminds me of EAMON, an 80s CRPG game system that people could create their own adventures for. (There are still websites devoted to EAMON! It’s a rabbit hole worth exploring, but that’s something more suited for its own post.)
And finally, it’s hard. Characters die frequently. You can revive them up to three times, and if you don’t mind reloading the guild menu 15 times you can turn the game off to preserve their life, but defeat is frequent without very careful play. You often have to play like a scavenger: take what easy-to-find rewards and successes you can, build your power over time, seek out easy adventures, and don’t take unnecessary risks. Dungeon characters are not heroes, not at first anyway, and if they’re ever to become heroes you’ll have to watch their steps.
The current appearance of the new Dungeon Maker module
Because these are the aspects of Dungeon that I like, they’re the elements that I’m focusing on in making Dungeon DX. My plans aren’t to make it quite as hard, but to still emphasize that these people are not demigods, not yet. A character’s career may be the story of the creation of a demigod, like how Conan, through countless trials, eventually became king of a great nation. It’s kind of a lie that people who rise to greatness frequently do so because of their own efforts, but it’s a pleasing lie, and it makes for a fun saga if you don’t take it too seriously.
My other plans for Dungeon DX, which may change, for while progress has been rapid (because Python is awesome), I’m still iterating over lots of things:
A retro look, kind of akin to how Dungeon looks on a C64, but still with enhancements. It doesn’t use pixel art, instead using vector graphics created in Fontstruct.
Dungeon was all one-on-one fights. Dungeon DX should have parties of three characters, fighting enemy groups that can be larger than that.
Dungeon doesn’t let characters keep items between adventures. For the most part, characters only advance through gaining experience. DX should let characters have a persistent inventory.
Dungeon doesn’t have any money system at all! DX should both have money and a shop where basic necessities and equipment can be obtained.
Dungeon doesn’t simulate much of the basis of exploration. My ideas for DX let characters rest in the dungeon, for example, but they must consume food to do so.
Dungeon has very little graphical splendor. Dungeons themselves are just blocks of green, with black tunnels dug through it, and once in a while a graphic character. That has to change.
Dungeon’s encounter model isn’t scriptable at all, which limits what can be done. It’s a lot more flexible than you might think it would be, given the C64’s memory limitations, but the edges of what’s possible are still easily reached. I want to change that.
Dungeon’s magic system is very interesting for its own sake, a collection of 16 spells that are more useful outside of battle than in it. Only one of those spells that does direct damage to enemies! Magic is much more of general utility. While my design has more damage-doing magic than that, I want to keep that feeling that magic is not primarily for harming monsters.
Dungeon doesn’t let characters learn spells themselves: all magic comes from items that contain it, and depletes with use. There’s interesting things about that system, but it kind of means that high-Intelligence characters aren’t very viable if the dungeon constructor doesn’t give them any magic to use early on.
Clivefrog77 makes these nice gaming dioramas, often based on European Commodore 64 games, and sells them on eBay. He has a page on Google Photos. I’m not sure if all of those are his, but a lot seem to be.
Rags to RichesInternational Karate +Great Giana SistersDan DareBad Dudes vs Dragon Ninja
8-bit microcomputer graphics were, compared to the graphics cards and chips we mostly use today, pretty limited. While machines like the Commodore 64 and Atari 800 allowed for a fully programmable display, not all devices of the age provided for that.
One solution was what I am told is now called semigraphics, which means using generic characters that are pre-defined by the system in combination with each other, piecing together larger images from symbolic building blocks.
ASCII Art, that fading art form created to make imagines on terminal displays, is a form of semigraphic. The IBM PC character set supported semigraphics mostly through its famous Code Page 437, which provided a variety of line-drawing characters , but looking at it it’s evident that it wasn’t intended for general graphic use.
Different platforms from the time varied widely in their support for graphic characters. Let’s take a quick look at what the options were.
Apple
The base Apple II had a very limited character set:
Images in this post taken from Wikipedia
The Apple II’s character offers little opportunity for graphic use. Of course the Apple II is a miracle through and through for being designed almost entirely by one person, Steve Wozniak, and that includes its character set. Note that it doesn’t neglect reverse video, and even has hardware support for flashing characters. Still though, not much you can do with it other than repurpose punctuation and letters.
PETSCII
The PET and successors, by contrast have an excellent character set for makeshift graphics. The image above is of the Commodore 64 version, but the same graphics are used on old PETs, the VIC-20, the Commodore 128, and even the TED-based machines, the Plus-4 and Commodore 16.
While they’re not reflected in the above image, the whole character set can be reversed too. These machines reverse characters by, simply, duplicating the whole set in ROM as negative images.
PETSCII contains:
Four playing card suit glyphs
A decent set of line-drawing characters, with all intersections both sharp-edged and curved corners
Diagonal slopes, diagonal lines and crossed diagonals
Horizontal and vertical lines at different places in the character cells
Frame corners, which combined with the lines can make decent rectangles
Horizontal and vertical bars at several different widths
Half-tone checkerboards and half-character checkerboards (on PET systems these have a single-pixel grain, but on later machines the checkerboard squares are 2×2 blocks)
4×4 blocks in enough combinations that, combined with their reverse versions, can be used to approximate a 80×50 pixel display with plain characters
Symbols for English pound and Pi
PETSCII is one of the most versatile character sets from the time, and you can do a ton with it with some thought and ingenuity. There used to be a Twitter account (in the days before the Muskening) that posted images of robots made out of PETSCII characters. And because the character set is included in ROM, one doesn’t have to create their own character graphics, using up 8K of system RAM to hold them, to have rudimentary graphics. (In fact, the original PET didn’t even support redefining the character set, so PETSCII was all you got.)
ATASCII
Did Atari consciously follow the naming of PETSCII, with their own self-branded ATASCII? Both are riffing off of ASCII, which stands for American Standard Code for Information Interchange. So I guess PETSCII, going by Commodore’s own claimed meaning for PET, means “Personal Electronic Transactor Standard Code for Information Interchange,” which is pretty terrible. But the ATA in ATASCII makes even less sense, since ATA obviously is just the first three letters in Atari.
While it has nowhere near the sheer number of graphic characters that PETSCII has, it had a decent number, including line drawing, slopes and diagonal lines and playing card suits. Of particular note is that the Clubs symbol has the same hole in its middle that it does in PETSCII.
TRS-80
Wikipedia doesn’t offer a screenshot chart of all the symbols of the TRS-80 set, but it does an HTML Table display, which the above is excerpted from. The only graphic characters it has are these off 2×3 cells, which are like the 2×2 blocks in the Commodore set but with an extra row. This gives its screen slightly finer resolution.
The TRS-80 had fairly basic graphics, it seems: those characters appear to have been it as far as graphics goes. The page I saw that described its capabilities even had a name for those blocks: squots. I think that’s a perfectly fine name for these kinds of boxes, whether it’s on a TRS-80, Commodore 64 or other machine.
Sinclair ZX-81
The ZX-81 had a very limited character set. While it has checkerboard and 4×4 block characters, their inclusion comes at the cost of an apostrophe, an at-sign, and even an exclamation point.
The following Spectrum removed the checkerboards, but added the exclamation point and apostrophe, as well as a lowercase alphabet. Still no @ though.
DOS Code Page 437
This is the one that most of you probably already know. It has its own version of squots, but they’re incomplete: it doesn’t have quarter-box or squot-grained checkerboard characters, tlhough it does have three forms of half-tone, a rather extra assortment of double-lined box characters, playing card suit glyphs, and a number of unusual characters up above that will be very familiar to anyone who played PC Rogue.
DOS Code Page 437 was in many ways the end of the venerable tradition of character set graphics. Neither the Atari ST nor Amiga had much use for general purpose character graphics, instead choosing to use their sets’ spare capacity for international characters, a noble offering, but less useful for graphic use.
It is worth noting some of the characters in the ST’s set, though:
Some miscellaneous glyphs like arrows, an X mark and checkbox, a bell and musical note, the Atari logo in two characters, a bunch of digital readout numbers, and four characters that seem to form a face. Here, I’ll piece it together for you:
Who might this handsome person be? It’s a little hard to make out at this scale, but it’s intended to be a pixel-art representation of “Bob” Dobbs, icon and symbol of the Church of the Subgenius!
