Set Side B

What I’m Working On: Dungeon DX

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.

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.

rodneylives

Pixel Memories Dioramas

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.

rodneylives

Home Computer Graphic Character Sets Compared

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!

It’s not a good set of squots, but it’s not bad.

rodneylives

C64 Dungeon Play and Lost World Demonstration

Another personal project post! I have done more work in making David Caruso II’s obscure Commodore 64 CRPG Dungeon, published in the issues of the disk magazine LOADSTAR more than once, presentable to current-day audiences. Although it certainly has its limits, there are some aspect to it that are unique, even forward-thinking. We posted about Dungeon here before. To remind everyone, we sell Dungeon on my (rodneylives’) itch.io page for $5, with the blessing of rights-holder and LOADSTAR owner Fender Tucker.

There are a few bugs in Dungeon, now basically impossible to fix, that I’m trying to track down and document, and I’m also working on improving the documentation, as well as provide some useful goodies with the system, like a disk of monsters, equipment and magic items. That’s useful because Dungeon has a special feature where it’ll take the monsters and items on a “Data Disk,” and scatter them around a dungeon map of its own creation. It calls these randomized adventures “Lost Worlds.”

Lost Worlds operate as a kind of quasi-roguelike. The Dungeon software creates a random map and places random items around it, but once created it becomes a Dungeon adventure that any created character can explore as many times as they like. While it doesn’t have roguelike tactical combat gameplay or random item identification, it does have a form of permadeath. Characters only get three lives to advance their level as far as they can go.

Lost Worlds are interesting places to explore, but there are some bugs in them. It is possible, in fact pretty easy, to get stuck in a part of the dungeon from which one can’t escape. Sometimes a one-way door leads into an area that can’t be escaped, and sometimes a passage-blocking trap will strand the player’s character in a dead-end. And once in a while a Lost World is downright unfinishable, its goal item disconnected from the parts of the dungeon the player can even reach.

While there are spells (Passwall and Teleport) that can release a trapped character, if they aren’t available the character is not completely lost. If you turn off the C64 (or close the emulator), then return to the Guild screen, the character will be marked as GONE. Over time, measured in loads of the Guild menu, the character will eventually find their way back on their own. It takes quite a while for this to happen though: I counted 15 loads, saving the game each time, before a GONE character returned.

This video (23 minutes) is is something I recorded myself as a demonstration of both Dungeon’s gameplay, and its Lost World adventure generation. It uses a set of 30 low-level monsters and items based on the stats of the old Basic edition of D&D, and a set of magic items I created for usefulness and to show off Dungeon’s spell set.

So, why would someone want to play this game, when there’s so many other newer CRPGs out there to play?

The idea of rolling up a character and taking them through scenarios made by other people, to try to get their level up as high as they can get before they die three times, is great. My hope, perhaps misplaced, is this release will inspire other people to make dungeons for others to play, and I look forward to seeing them myself.
The magic system of Dungeon, while it doesn’t allow for characters to learn spells themselves, is unique in that most of the spells are utility spells! There are spells for passing through walls, for teleporting anywhere on the map, for revealing terrain, for seeing in darkness, for giving oneself a damage shield, for locating the goal item, for disarming traps, and more. There is only one direct damage attack spell! Spells are more like tools than something you use to pound through the enemies.
The dungeon model allows for dark areas, traps that block exits, two-way and one-way teleporters, secret doors, one-way doors, and decorating dungeon maps with PETSCII graphics. The simplicity of the dungeons, all of them fitting on one screen, works in Dungeon’s favor. No dungeon can be too large since they must all fit within the bounds of the map grid.

There are unique design considerations for making Lost Worlds too. Even though the computer creates the maps unaided, since it populates them from the monsters, items and traps that are on the Data Disk, the difficulty of the resulting dungeon is affected. The various doodads are distributed without apparent heed for what they are; I wonder if the generator actually cares for their identities or if it just checks how many of each type are on the disk, so as not to exceed that number.

If there are more easy monsters, more powerful items, and more weak traps on the disk then the dungeon will be easier due to their corresponding numbers being greater, and vice versa. It occurs to me that one of the flaws in the dungeon generation I mentioned could be alleviated, by not giving it one of the wall creating traps that could trap a player in a dead-end, but that also makes the dungeon a bit less interesting, so I’ve left it in the mix I use.

I recognize that, if I let myself, this might become a Dungeon blog. Rest assured, I’m not going to take it that far. But I really hope that some people give Dungeon a chance. While sure it has its inspirations (one person on Mastodon said it reminds them of Phantasie, a somewhat less obscure early CRPG), I think it’s pretty unique, and deserves for more people to have a look at it. I’m particularly pleased how well the sample monsters and items I made work in the Lost World framework, and I’m trying to think of ways that it might be improved. More on this later… but, not immediately, I think.

rodneylives

Reverse Engineering the 6502

This is a 52-minute talk from 2010, from the 27th Chaos Communication Congress in Berlin, Germany (the talk is in English), presented by Michael Steil of Visual 6502, which successfully reverse engineered the venerable 6502 microprocessor, a chip used, in one capacity or another, in one form, or another, in all the Apple, Commodore and Atari microcomputers, the BBC Micro, the Atari 5200, in a modified from the Atari 2600 the NES, and countless arcade games, as well as in other places.

The talk is intended for a technical audience… literally. When the speaker asks who in the audience has coded in assembly before, practically everyone raises their hands. It’s recognized that we at Set Side B veer wildly between the most surface-level populist material and in-depth treatments for those with gigantic capacities for technical discussion and the attention span of a Galapagos Giant Tortoise. We like to think this is charming, and will listen eagerly if you tell us that you agree.

Anyway, here is that talk. I already mentioned that it’s 53 minutes. If that’s too long, there’s a speed-up function on Youtube. If that’s too technical, well, I don’t know how to help there. Maybe a read through pagetable.com’s documentation on the 6502. Oops! I’ve made it worse, haven’t I. Well, if you like, you might console yourself that the 6502 is really a simple processor to learn to code in. I’ve done it myself! There’s no memory management, there’s only three general-purpose registers, the stack is fixed in place, and all opcodes are one byte. It’s so simple that an extremely motivated child could learn it. Guess how I know?

27c3: Reverse Engineering the MOS 6502 CPU (Youtube, 53 minutes)

Here’s a description of the talk from the conference web site.

rodneylives

A 30+ Year Old RPG System for the Commodore 64

It’s been months now since I announced my plans to release some project involving LOADSTAR, a 17-year computer magazine on disk, either here or on itch.io, or both. I’m still working on them.

In the meantime, I present this, a packaged-up release of Dungeon on itch.io, a complete old-school RPG gaming system for the Commdore 64, as it was released on the disk magazine LOADSTAR back in 1990.

Written by David Caruso II, Dungeon is a way of creating adventures for others to play, and a system of creating, maintaining and playing characters in those adventures. It was kind of a throwback even in 1990 (the SNES was released that year), but it definitely has charm, and an old-school kind of appeal.

You start out on the Guild screen, where you create a character from one of five fantasy races, then venture out on adventures stored on floppy disks, which in this release are provided as C64 1541 disk images. Fight monsters to earn experience points, find the object of the quest and then return to the Guild by the exit to have the chance to advance in experience level. If your character dies they’ll be revived, but only up to two times! If something happens and you don’t make it back, but don’t die either, your character will be marked as “GONE,” meaning they’re stuck in limbo until they make it back to the Guild on their own!

Your character advances in level between adventures, but they don’t get to keep any items they found on their journey. If they advance in level however, they get to permanently improve two of their stats. Getting to the maximum score of 25 grants them a special ability, but it’s really hard to get there!

This presentation of Dungeon is being made with the permission of Fender Tucker, owner and former Managing Editor of LOADSTAR. It isn’t free, but for $5 you get the Dungeon system and five pre-made adventures for it, culled from the 240+ issues of LOADSTAR. I include a stock copy of the open-source Commodore 64 emulator VICE, configured for playing Dungeon. (If $5 is too much for you, rumor has it Loadstar issues can be found online elsewhere. Dungeon was first published on issue #74.)

If you want to know more about it, I have constructed this 40-page PDF of documentation on Dungeon, from the disks of LOADSTAR in 1990, along with the instructions for the adventures and further notes on playing it from me. Here:

dungeon Download

(file size: 2.6 MB)

The document refers to an itch.io release, that’s what I’m currently working on. Late in the document there are some spoilers for a particularly difficult adventure using the system.

Dungeon was created by someone named David Caruso II. Neither I nor long-time LOADSTAR managing editor Fender Tucker knows what became of him. I have what is almost certainly an old address for him. It’s been 33 years, and I suspect that Dungeon itself is a couple of years older than that, so it’s possible that Caruso has passed away by now. If he hasn’t, though, I’d like to talk with him. I think (hope?) he’d appreciate that people are still thinking about his creation even now.

rodneylives

An Ad From Compute Magazine #001

This is an ad, on the first page of the first issue of Compute Magazine, for “the pet program” from “softside software,” names all in lowercase. I have no idea if any copies of these programs remains in existence in our universe, but two places to look would be zimmers.net’s FTP archive and the Silicon PET Archive, and even in this era of the internet there are a fair number of PET software archives remaining.

Softside was far from the only company to put out its hopeful shingle through the pages of early computer magazines. At the time, magazine publishing worked with a lead time of several months. It is possible that Softside Software had gone under even by the time this ad saw print, but then again maybe not. A forum thread on AtariAge mentions several BASIC games sold by a “SoftSide,” apparently an Atari 8-bit magazine-on-disk, but they were based in New Hampshire, and the Softside of the ad was in New York.

Notes on the programs proffered:

Graphics Pac 2: I’m not sure what they mean, as the reference I’ve found claims the PET didn’t have a bitmapped display, but there were several models, and further add-on cards that added bitmapped displays, an 80-column mode, and even (gasp) color. A simple “Microsette” itself would not be enough. We are near the end of the PET’s reign as Commdore’s core product though.
Assembler 2001: It is easy to laugh this off nowadays when assemblers are mostly free software (and thank frog for that), but this was before that, and before the internet. $16 is a great price for an assembler from that time.
Bike. Apparently it was a Hammurabi/Lemonade Stand style game, where you made business decisions through simple menus and entering figures. Maybe someday someone will write such a game about running Commodore. You might scoff at the warning that “Bike is dangerously addictive,” but standards were lower then. It was 1979; Wizardry wouldn’t be published until 1981. “Worth a million in fun, we’ll offer Bike at $9.95.” I admire their chutzpah.
Pinball. “Dynamic usage of the PET’s graphics features” would have meant using its hardcoded, unchangable ROM graphics character set, with no sprites. “With sound!” That would mean its simple piezoelectric speaker. Don’t expect Raul Julia’s voice, or even Gorgar’s, to talk to you from the machine.
Super Doodle. Certainly of no relation to Omni Software’s popular Commodore paint program. Super Doodle lets you use any number of colors so long as they’re black or green, and a resolution of 40×25 characters. “Why waste any more paper.” Well probably because loading your notes off of tape would take too long.
Driving Ace. Offers two games for $9.95. The description doesn’t give a good sense of what they were like, but there are essentially only three kinds of racing game: scrolling in one direction (Monaco GP style), one screen or scrolling all around (Sprint style), and 3D (Pole Position through to Ridge Racer to F-Zero). I presume one of these is like Sprint and the other is like Monaco GP; I don’t think the PET was capable of even a slight approximation of 3D, but then, Pole Position’s hardware shouldn’t have been capable of what it could do either.

The ad is from Compute Magazine, most often stylized as COMPUTE! with an exclamation point, grew out of The PET Gazette in 1979. That former publication centered around the computing devices from Commodore International’s subsidiary, Commodore Business Machines. CBM had been around for over two decades up to that point as a maker of typewriters, adding machines and calculators, but in a maverick move by its co-founder and president Jack Tramiel, they bought MOS Technologies, which had just startled the nascent computing world by creating an ultra low cost microprocessor, the 6502. Tramiel had learned from a bit of a bastard move by Texas Instruments, who used their ownership of much of their supply chain to release a line of calculators that sold for less than Commodore’s production costs. Now, Tramiel owned the company that produced the chip that would soon launch the personal computing revolution, and could make other chips too, and Commodore was set to soon pull off Texas Instruments’ trick on the home computer industry with the VIC-20 and Commodore 64.

But until then they made other computers. They made the KIM-1 “single board computer,” and the PET 2001 and other machines with the PET branding. The PET Gazette’s audience was originally those machines, but burgeoning success convinced them to publish a more generalized 6502-focused magazine, and that magazine was Compute.

I have more to come on Compute, which in many ways was the archetypal type-in program magazine. It was far from the only one; other magazines offering type-in software at the time, names now even more obscure than Compute’s, were Creative Computing, Family Computing, and Commodore’s own publications Commodore Magazine and Power Play. Compute would for a while languish somewhat in the shadow of its own sister publication, borrowing part of its name from its predecessor, Compute’s Gazette, which focused on Commodore’s computers, the VIC-20, the Commodore 64, and later the Commodore 128.

The PET Gazette was founded by Small System Services Inc., and was published out of a shop, the Corner Computer Store, in Greensboro, North Carolina. Presumably that changed as the subscription rolls increased. Eventually Compute would be sold to ABC Publishing, a subsidiary of the broadcast network, and it would continue happily for several years. When its fortunes began to wane it was sold, first to Penthouse Publishing (really!), where its logo was redone to resemble that of its own publication Omni, then later to Ziff-Davis, who only wanted its subscriber list anyway; I don’t think they ever published an issue. As it became clearer that the future would be MS-DOS and Mac, its focus shifted, but they kept up their small systems focus for surprisingly long. I don’t think the Penthouse era provided any coverage that wasn’t DOS, Windows or Mac, but it would take time to check. Corrections later, if necessary.

rodneylives

Randy Glover, Creator of Jumpman

Here is a talk by the creator of the brilliant 8-bit platforming game Jumpman (who isn’t Mario). That’s all the lead-in I have time to provide right now. And if you get the chance to try Jumpman, do it. There’s a version on Steam! (Note, the C64 version is preferable to the DOS version.)

The Man Behind Jumpman: Retro Gaming Revealed (Youtube, 58 minutes)

rodneylives

NES and Commodore 64 Games Compared

Greg’s Game Room on Youtube looked at 28 games with both NES and Commodore 64 versions. It’s not by any means all of them, but a good selection. Usually its the NES version that’s better, but there are some surprising upsets, especially if the game originated on a microcomputer platform.

The Commodore games that won out are Ballblazer, Castelian, Die Hard (but the C64 version’s really different), Ghostbusters, Ghosts ‘n’ Goblins, Q*Bert and (surprisingly) Smash T.V. Decent C64 games that nevertheless lost are Blades of Steel, Commando, Donkey Kong, Mighty Bomb Jack and Super Mario Bros. (rated were both the similar Great Giana Sisters and the recent fanmade version of SMB that uses advanced scrolling tricks). Gyruss, Mario Bros. and Pac-Man were rated at a tie.

Nintendo vs Commodore 64, 28 Games Compared (Youtube, 46 minutes)

rodneylives

On The Red Obelisk

In 1987, programmers Robert Germino and David Todeshini wrote a weird and obscure Commodore 64 game called The Red Obelisk. It barely made a dent in the market, which is kind of a shame. It’s nearly entirely unique, which is a difficult thing to say of any game 36 years after its publication.

Part of why it’s not remembered much today might be how unique it is. It’s mostly a game about alchemy, but not as much in an Opus Magnum kind of way. You’re given an object, kind of like a gemstone, found in an asteroid belt. You shock it with electricity, zap it with lasers, and shoot sound waves at it. All of this is depicted in an illustrated laboratory, with surprisingly atmospheric graphics and sounds. Doing these things may increase its value. You can sell it at any point to earn energy proportionate to its value, which you need to run your ship and guard against hazards, and points. Your real goal though is to create a Red Obelisk

An earlier work of theirs was Sentinel, of which there’s even less information online.

I played a bit of The Red Obelisk and uploaded a recording to Youtube. I don’t do too well. Here is that video (7 minutes):

Both The Sentinel and The Red Obelisk, and another game I think they made called Phaserdome, were included on a disk called Master Blaster put out by Keypunch Software. Keypunch wasn’t a great organization; there are tales of them taking freeware games, scrubbing them of information by which their creators might be identified, and then selling that on a disk. It was before the widespread adoption of the Internet, the World Wide Web was still three years away, so it was easier to get away with that sort thing than it is now.

Later on The Red Obelisk got picked up for an issue of Loadstar, and the veracity of its editors I vouch for completely. I haven’t yet checked their products for the other games. Sentinel is also on Loadstar. The documentation I retyped below suggests they have another game on Loadstar as well. Both The Red Obelisk and Sentinel are on the Internet Archive, but you can get legal and paid-for copies for $15 of the first 199 issues (Loadstar was amazingly long-lived) via LOADSTAR COMPLEAT, still sold by its long-time Managing Editor, my friend Fender Tucker. The Red Obelisk is on LS64 issue 58.

The game is fully described in its instructions, below, so I’ll just give you some of my own impressions. It’s interesting! It has to have something to it for it to have persisted in my memory for so long. I think the game is implemented in BASIC with some machine code routines to handle the real-time portions. This is a perfectly valid way to implement a game; I did it often myself back then. It’s pretty much the only way to get the smoothly-moving asteroids and slick sound effects the game has.

What I remember the most is the Object Mode, where you zap various objects on your workbench in the hopes of creating a hugely valuable Red Obelisk. Everything you do costs energy, and running out destroys your ship, so efficiency is a must. In order to succeed you must take notes as to how each object behaves. Basic directions are given in the instructions: get the Tolerance below 100 with electricity, and the Temperature above 500 with lasers. Is that all there is to these tools? It has been too long for me to remember, but I do remember finding a string of Red Obelisks at one point, so there must be some process to it. Experiment to see what you can find.

The other thing I remember is the noise that your ship makes when you collect an object. All of the sounds in The Red Obelisk are effective, but that noise found a home in my brain when I played it decades ago, and it has never left. I think it probably never will.

What follows are the instructions to the game as included on Loadstar 58, as written by Fender himself, with section headings and minor formatting added by me.

THE RED OBELISK

by Robert Germino and David Todeschini

One of the safest bests of the 21st Century is that treasures will be found in space in the form of small meteors. They may be grey and drab-looking on the outside but inside will be jewels and precious gems, just waiting for the mining engineers to extract them. But it won’t be easy.

If you are a veteran of the universe of STURGRAT (on LOADSTAR #54) you will have an idea of the complexity of 21st Century space mining.

Setting

In THE RED OBELISK you are in control of a mining company. You must gather some object from space and by using the powers of your factory, you can ‘sell’ them for the maximum profit. Your goal, as is any capitalist’s, is to garner as many shekels as you can.

Let me describe your ship first. It is a Sturgrat space mining/laboratory and short-range fighting vessel. It operates in three modes, the Object Mode, the Mining Mode and the Attack Mode. You begin in the Object Mode (which is the inside of your laboratory) where you get a readout of all the capabilities of the Sturgrat.

Object Mode

The most important thing to keep your eyes on is the POWR rating in the lower right of the screen. If this gets too low, you will lose your ship, and, as is shown right above the POWR display, you only have two, not counting the one you begin with.

But your power is running down so you can’t tarry too long making decisions. And believe me, there are a lot of them to make.

You begin with an object on the conversion table. Its type is shown on the left. The idea is to process this object and then convert it into SCORE and POWR. You have to get the tolerance down and the temperature up.

These two values are shown on the left, TOLR and TEMP. You hold down the E key (for the electrodes) for a short period of time and notice that when you let up the TOLR has gone down. Get it down below 100. Press L (for the lasers) the same way to get the TEMP above 500. Since your POWR is going down all of the time, it pays to do these two things quickly and efficiently. They MUST be done for each object.

In the bottom left hand corner is the value of the object (VALU). As a true capitalist, you will want this figure as high as possible before you convert it into cash (SCORE).

You can increase the value of the object by bombarding it with Ultrasonics. Press U and then push the joystick forward and listen to the pitch of the sound. Press the firebutton and the VALU will increase by a certain amount. If you want to increase the VALU faster, push forward on the stick, the pitch will increase and so will the amount the VALU increases when you press the firebutton.

You can get too greedy with VALU. If you’ve increased it too high, the object will be destroyed and will disappear from the screen.

A good Sturgrat miner will write down the TYPE of object and try to discern the maximum VALU an object of that type can attain WITHOUT destroying itself at conversion. Write this figure down, too.

If you convert at too low a VALU, you will only get the VALU, but if you convert it at just below the ‘peak’ VALU of an object, it’ll be transformed into the incredibly valuable RED OBELISK, which, in more ways than one, is the name of the game. It’s up to you to determine each object’s ‘peak’ value.

You cannot do much more in the Ultrasonics mode. Press U to toggle out of it (if you are in it) and then you are ready for conversion. You do this by pressing RETURN. You’ll either (a) convert it for the present VALU, (b) create a RED OBELISK (which pays off handsomely) or (c) find yourself looking at a dreaded FALSE OBELISK. If you see one of these, you have to act quickly and destroy it by firing Caps at it (the F key) or by bombarding it with Ultrasonics. If a FALSE OBELISK is left to itself it will destroy your current ship and its cargo.

Mining Mode

Which brings up the question: Where do objects come from?

You have to space-mine them. Press the SPACE bar to go from the Object Mode to the Mining Mode. You’ll see your Sturgrat drifting through a meteor field. Use the joystick to maneuver around the meteors trying to capture the small, shining object that is floating slowly across the screen. The object must be captured DIRECTLY in the Sturgrat’s scoop. Even a small bit off-line will cause your ship damage.

You have a tractor beam which you can enable with the firebutton. It will draw the gleaming object up the screen where the action is less hectic.

As a matter of fact, the top of the screen is a safe place where you can scoop up hydrogen molecules with your tractor beam and slowly boost your POWR if you are running low.

You can gather up to nine objects at a time or you can gather just one and head back to convert it. To go back to the Object Mode, press RETURN.

Attack Mode

You begin your stint as space-miner with 3 ships and 3 Caps, but as your POWR gets higher (above 1500 megajoules) your Sturgrat becomes more attractive to marauding space-hijackers. When you least expect it you will be attacked.

The message says that you have lost the object on the conversion table and that the marauder wants to know if you surrender or not. If you surrender, you won’t lose your ship but you’ll have to continue with what you have. If you answer N to the surrender prompt you go to the Attack Mode.

This is the arcade portion of your mission. Move the joystick so that the cross-hairs are on the middle of the attacking ship and press the firebutton to fire. Keep an eye on your POWR level. If you are in danger of losing your ship you can weaken or destroy the marauder with a Giga-Gem by pressing the G key.

Giga-Gems can destroy any cargo that the attacker may have, so you should use them only as a last resort. When you have bludgeoned the attacker into submission he’ll ask if he can trade his cargo for his life. If you feel in a benevolent mood (or in a greedy one) you’ll probably do better accepting his offer and letting him limp off into space.

If you choose to destroy the enemy, you may be able to salvage some of his Caps. If you let him live you may get CRGO (objects), Krystals or Giga-Gems. Base your decision on what you need most.

The Krystals (KRYS) cam be converted in the Object Mode by pressing K. A Krystal is mainly a bonus score you get for defeating a marauder and being kind enough to let him slither off alive.

That’s about it. It will take a little practice with the controls of your Sturgrat but soon you will be grabbing objects and converting them like crazy hoping to find a level for each TYPE of object that will give you a RED OBELISK. As your POWR rating goes up you will have to fight off space-raiders more. Try to get the highest score so that you can head back to Earth a rich man.

As for the trip back to Earth, that’s another game, but one I’m sure Bobby and David will be creating soon. Sturgrat rules! Long may it run.

DISK FILES THIS PROGRAM USES: RED BOOT, RED BOOT 2, RED OBELISK, SPR1, T.RED BOOT

**** End of Text ****

rodneylives

Romhack Thursday: Doom on a Commodore 64, kinda-sorta

On Romhack Thursdays, we bring you interesting finds from the world of game modifications.

Look at that title and marvel a bit. Doom on a C64! What an idea. How could it even be possible? What an age we live in. It is a time of wonders. Children are our future.

Of course there’s more to it than that. There is a whole class of “retro” game that amounts to implementing the actual game on separate hardware, and using the supposed host platform as a glorified display and input device. That’s what’s going on in this case. Doom is really being run on a Raspberry Pi in a plug-in cartridge on a processor that’s underpowered by modern standards but far outpaces that of even Doom’s base configuration, and is thousands of times more powerful than the Commodore 64 to which it pipes its output.

But there’s still some technical interest in the means. The device that runs it is a “RAD Expansion Unit,” a DIY device that emulates a C64 RAM expansion, and apparently can even take over from the 6510 CPU and drive the system’s hardware directly. It works by writing to the VIC-II video and SID sound chips itself.

There was still a lot of coding work required to make this possible. A C64 has somewhat decent sound hardware, but the VIC-II chip has severe limitations on what it can display. The Raspberry Pi has to take the game’s display and port it, in real-time, to a graphics chip that can only display up to four colors (out of only 16) in each character cell, and that’s by sacrificing half of its horizontal resolution. Doing that on the fly itself is a noteworthy hack.

Could it be possible to run DOOM on a C64 without such assistance? At native resolution, ha ha ha: no. The memory limitations are too grievous, so at the very least you’ll need a RAM expansion.

I’ve mused at times on whether it might be possible if one uses the character screen as a kind of super-low-resolution graphics mode, each 8×8 character block representing either a 2×2 pixel grid (so, a resolution of 80×50) or a single pixel (40×25). Even at such a resolution 60 fps is probably out of the question, for it takes a lot of cycles to change every tile every frame, but maybe at 30 or 20? 15, 12, 10? (60 is divisible by a lot of numbers.) I will leave that question to people who are more current with C64 assembly coding.

Here is a demonstration video:

Doom on C64 – A playable tech demo for the RAD Expansion Unit for Commodore 64/128 (Youtube, 19 minutes) – Github repository

rodneylives

Gamebase 64 is in Trouble

According to this forum post, classic Commodore 64 database and information archive site Gamebase 64 has been stricken by the death of their webmaster Steven Feurer, and unless they can find someone to replace him soon, and likely provide alternate hosting too, their site will follow him into the Great Beyond.

As time passes, these kinds of events will happen more and more often, so please, if you maintain a website, of any kind sure but our remit is games so let’s say game-related site, please take measures to ensure its continuity in the unfortunate event of your passing. And if you can help Gamebase64 out, please consider it?

Bye, bye, Gamebase64?

rodneylives