This is another huge topic that I should come back to later, but in the meantime here’s an article, mostly about the British type-in scene, from Wireframe Magazinne last year. It mentions the longest type-in game ever, Axys: The Last Battle (Youtube), an Amstrad program that had to be printed in five successive issues, and what it calls the best type-in game of all, Crossroads from COMPUTE!, although I’m dubious about that claim, there were lots of type-ins. It’s definitely great, though. It’s worth a read if you have the time, although who has enough of that these days?
On Romhack Thursdays, we bring you interesting finds from the world of game modifications.
Edit the Frog is back, with a new romhack! And this one’s really amazing.
We’ve mentioned before Vitor Vilela’s hacks that retro a SA-1 (“Super Accelerator”) into SNES games that suffered from slowdown. So far he’s done it with five games: Super Mario World, Gradius III (which really needed it), Contra III: The Alien Wars and Super R-Type. The fifth is the most amazing so far: Race Drivin’.
When the original Hard Drivin’ came to arcades it was pretty incredible, the first 3D racing game that didn’t use scanline tricks to display its track, that rendered it using an actual polygonal 3D engine. It used special custom hardware to make its track and physics possible. Race Drivin’ was less revolutionary, but only because the ground had been broken for it.
It was exactly the worst kind of game to be ported to the Super Nintendo’s infamously underpowered hardware, a 16-bit variant of the venerable 6502 running at about 3.5 mHz, just a bit over twice the speed of the NES. Even from the start, the SNES used in-card accelerators and co-processors to help complex games run: even though launch title Pilotwings made heavy use of the SNES’s “mode 7” graphics to display the game world, it still needed a DSP chip to help it with calculation.
https://github.com/VitorVilela7/SA1-Root/tree/master/Race-DrivinRace Drivin’ doesn’t use any accelerator, despite being one of the games most sorely in need of one. Asking a SNES to perform up to the custom mathbox chips in the arcade game was ludicrous, and so SNES Race Drivin’ is looked down upon by many, and probably unjustly: the coding is perfectly all right, it was just asking too much of the system.
Even with a SA-1 you’d think that Race Drivin’ on SNES couldn’t measure up, but Vitor’s hack does quite a respectable job! The SA-1 is essentially a second of the same kind of chip that runs the SNES, with a number of extra features bundled in. It also has some faster memory included on-die, and runs at triple the frame rate. Imagine if this had come out at the time: the SNES game is less than two years older than the arcade version! An SA-1-powered version that matched the arcade so closely back then would have astounded. I see that in a few places on the Super Stunt Track, it drops to 12 FPS instead of the 30 it holds at elsewhere, but it’s still damn slick.
Here is one of Vitor’s side-by-side comparison videos, demonstrating the old version (on the left) and the upgraded hack (on the right):
The SuperGrafx is a failed system that had only five games, only three of which seem to be worth playing. The Sharp X68000 series of high-end personal computers, which were only released in Japan, on the other hand, is probably the popular gaming system Westerners have heard the least about.
As I said yesterday, the X68000 cost three grand, and that was just for the base system. If you thought the NeoGeo was expensive, hah. It’s price was justified in that it was a computer, indeed a workstation, and had a variety of software other than games. But it did still have a lot of games, including some of the best arcade conversions, including excellent ports of Rygar, After Burner, Strider, Final Fight, Street Fighter II and Detana! Twinbee, and a well-remembered recreation of the original Castlevania up to then-current aural and visual ideals. The X68000 even got conversions of Atari arcade games like Marble Madness, and even KLAX, that would I would have loved to have played back then.
The X68000 also worked a lot like a MS-DOS machine from the time. It ran mostly HUMAN68K as its OS, a DOS clone made by HudsonSoft, although it also had windowing OSes. Despite how it seemed in use though, it used Motorola 680X0-family processors, like original iteration of the Macintosh. But while it has a DOS-style OS, it’s a home computer with a dedicated sprite chip!
At times it feels like this blog is a recap of my gaming-related Youtube explorations, but I have no qualms about it when they’re as excellent as the two I have this time. One is a review of the “pro” version system from four years ago, from someone who went and obtained one:
Three years later, RMC returned with a more thorough exploration of a different machine of the line:
And this one is about emulating it, which is probably the closest most of us will ever come to trying out any of its software:
What is the SuperGrafx? Why don’t we remember it as well as its predecessor, the PC Engine/TurboGrafx 16, with which it was backwards compatible?
Sharopolis on Youtube digs into the system and its capabilities (17 minutes):
As you can tell by the video’s cover image: Amazing Power, No games. The SuperGrafx only had five games released for it throughout its lifetime, pretty harsh for a system that cost around $300 by today’s money. That cost, relative to that of the PC Engine CD, which was also expensive but could play CD games with vastly greater storage, was probably what doomed it. For those really seeking an arcade experience in Japan there was the Sharp x68000, famous at the time as the true enthusiast’s system with a good number of nearly exact arcade ports. It also cost around $6,000 in today’s money, and still $3,000 in then-money.
The system used the same chip as the PC Engine before it, a 6502 variant running at 7 mHz, meaning it was only a 8-bit system. But was that really so bad? The major 16-bit competition for it was the Motorola 68000, another venerable chip at the time that was used in the original Apple Mac, the Sega Mega Drive/Genesis, the Commodore Amiga and the Atari ST. Yet the 68000 also had some more overhead. Many instructions on the 6502 completed in from two to four cycles, whereas the minimum cycle count of a 68000 instruction was four, with some taking up to 20. This, of course, is offset by the 68000’s greater number of registers and ability to work with two bytes at once for many instructions.
Its graphics were essentially two of the PC Engine’s graphics chip, with some circuitry to interface their outputs together. This description brings uncomfortable reminders of people deriding the Wii’s graphics as “two Gamecubes taped together,” but it’s a much closer description of the SuperGrafx’s graphics. But in practice this meant twice the sprites, dual-plane backgrounds, and double the potential colors on-screen at once, while the MegaDrive/Genesis infamously was still stuck with 64.
The SuperGrafx’s failure in the market was one of those inflection points of the growth of video gaming. If it had succeeded then NEC might still be a player in gaming today, and maybe Hudson Soft would still be an independent entity, instead of just another property for Konami to mine for nostalgiabucks.
Edit the Frog is still taking a break from covering romhacks, there’s thousands to sift through on romhacking.net, but in the meantime, here’s a fan-made, browser-playable version of Metroid! Although it looks a lot like the NES game, it’s no hack, but a from-the-ground-up reimplementation.
It was made specifically to help overcome the limitations of the NES platform, so Samus animates much more smoothly, there’s particle effects, multi-directional scrolling areas, built-in mapping, and the music uses later, more orchestral versions of the original’s music, although with an option to switch to the 8-bit originals. (I find that the music is a bit reluctant to play in the current version, though.) There’s other interesting features new features to find as well.
Most interesting is a built-in randomizer mode, and a second, alternate planet to explore! It’s designed along the lines of the original Zebes (here called “Zebeth,” a nod to the on-screen Romanization of Zebes in the NES game), but has some new elements, including areas that scroll in all directions, and new bosses!
Metroid is approaching 37 years old, and it was looking a bit long in the tooth three decades ago. Yet it’s still remarkably atmospheric for its age, and I find there’s something evocative about how the game’s world doesn’t feel designed like a challenging obstacle course for the player, like it just exists on its own and doesn’t particularly show any care for the player. There are some item gates, but like the original NES Legend of Zelda, many fewer than you’d expect, especially compared to their SNES sequels.
Screed time! Will Metroid still be played 20 years from now? I think so, although I find that most of the internet energy around these classic NES games now is focused on speedrunning, randomization and romhacks, and two of these three things Nintendo is actively fighting against. It’s a good example of how copyright law and corporate control has the potential to hold back both fan interest and property longevity. The rights to these games should be released to the public, while there is still a public that cares about them. Nintendo would probably get more money out of it, in the long run, from making sequels anyway.
The always excellent Nicole Express has a great post on the Japanese gambling game Pachinko, especially the imported machines that made it to the U.S. when for a brief time we liked it too. It contains the fact that we probably got video pachinko before Japan did, through the Odyssey2 game Pachinko! (The exclamation point there is part of the game’s title, as it is with all Magnavox-produced Odyssey2 games. While I enjoy that bit of trivia, I am not actually hugely excited about it.)
Physical slot machines were, and maybe still are, illegal in Japan, so all the ridiculous graphic and sound flourishes those demonic entities bear in North America are instead put in the service of the Tiny Silver Balls. I’ve always shied away from these forms of gaming for the same reason I never got into Magic: The Gathering: by tying profitability to gameplay, they feel to me like they’re more business model than game, really. I might not be able to earn my quarter back at Pac-Man, but at least there isn’t someone figuring out how to work those odds against me.
Overseeing the early days of computing was Compute! Magazine, properly stylized with an exclamation point. They got their start as The PET Gazette, changing over to Compute as their focus spread into more types of home microcomputers. Compute stuck around as a multi-platform for some time, but ultimately spun off a couple of manufacturer-dedicated magazines. One of these was Compute’s Gazette, whose name harkened back to those PET-exclusive days. It focused on Commodore machines, and would then outlive Compute itself by some years.
The early years of Compute magazine are joyous. They’re filled with esoteric data, geeking out over low-level coding matters, and lots and lots of type-in programs. But it is depressing to me, reading over the early issues, knowing how numbered are its days. This whole genre of computer magazine, that encouraged users to type in programs, that offered coding tips, sometimes even offered add-on disks of software, is now only a memory. We are all poorer for it.
The writing on the wall for this style of magazine could perhaps be seen as early as September 1982, when Compute published an article about a great new upcoming product from Commodore, the Commodore 64. Not because of the style of the article or anything specific about the computer. Just that, by being so greatly popular, the C64 greatly expanded the magazine’s audience, which would inevitably steer it towards becoming more “mainstream,” which ultimately would be the death knell for a publication like this.
The Commodore 64 was not Commodore’s first home computer. It wasn’t even the VIC-20. Their first machines were the line of the PET, or “Personal Electronic Transactor,” as labored an acronym as any.
The PET was a decent machine, with integrated monochome monitor and a heavy metal case. Although it had no color, no sprites, only a basic speaker for sound and no synth, it had a number of things in common with the later C64, particularly the 6502 processor that lay at the core of half of the personal computers sold at the time.
There was something else, something fairly major, that the PET lacked: customizable graphics. No hi-res mode, and no programmable character sets. The graphics were encoded on a ROM that wasn’t even mapped to the CPU’s address space. The letter ‘A’ would forever look like a letter ‘A’. It couldn’t be changed to anything else, even a slightly different ‘A’. This greatly limited what PETs could display, and basically doomed it as a gaming computer.
Commodore tried to compensate for this feature by including “PETSCII,” a set of custom characters included in the upper 128 characters of its ROM intended for makeshift graphics. PETSCII would survive throughout the rest of the Commodore 8-bit line, even featuring on machines that had programmable graphics: the VIC-20, C64 and C128 all had it included too. (The Twitter account PETSCIIBOTS (now inactive) shows off its many graphical characters in making robots.)
On the later machines PETSCII graphic characters were a fun nicety. On the PET, they were all you had, all you would ever have. This is exactly the kind of limitation that demo authors love circumventing where they can, and taking advantage of when they can’t. Hence: Back To The PET, a demo, complete somehow with chiptunes, that runs on Commodore’s ancient machine:
Every character cell of every frame of this video is one of the PET’s 256 ROM-based characters. It had no hardware scrolling, so effects are all faked or done 8 characters at a time. Yet it’s still pretty slick! The PET had quite a better selection of graphics characters than even IBM’s code page 437, including lines of single pixel differences in thickness and horizontal and vertical position. Image what the ASCII artists of the 90s could have done with this selection! Luxurious!
ZZT was (is) an ancient shareware DOS game that runs in character mode, created and published by Tim Sweeney. Originally published by Potomac Computer Systems, a company ran out of the basement of Sweeney’s house, when it expanded its software selection it was renamed to Epic MegaGames, and later Epic Games, under which title it remains today, still headed by Tim Sweeney after all these years. He would go on to create the Unreal Engine, upon which the modern fortunes of the company were founded.
But back to ZZT, which is still a nifty piece of software, and a lot of fun to mess around with. It included an editor that allowed users to create their own scenarios, which spawned a modding community that survives to this day. Noted game designer and educator anna anthropy wrote a book about ZZT for Boss Fight and she continues to carry its banner today. ZZT scenarios both old and new can be found on the site Museum of ZZT, and every three hours Mastodon bot Worlds of ZZT publishes screenshots from random ZZT adventures.
Because it’s a character-mode game, ZZT modules are often confused with classic roguelike computer games. ZZT is not necessarily a roguelike, but it may be possible for someone to write a classic-style roguelike game in ZZT.
But running a DOS game nowadays is not as easy as it used to be. It requires the use of either a vintage computer system running a compatible DOS, a virtual machine like VirtualBox or Docker, or some DOS emulator, such as DOSbox, a tool for emulating a working DOS system that can run on current OSes, or Zeta, a DOS emulator with just enough features to get ZZT working.
ZZT was written in Turbo Pascal, but its source code had been misplaced by Tim Sweeney and was considered lost, until very recently (the past few days), when a nearly-complete version of ZZT 3.0 was found. Most of it can be downloaded from The Almost of ZZT, on Github, which is that version minus some parts of the source that are considered to be under third-party copyright.
Since it is incomplete it is not useful for compiling a working game, and is presented for historical reasons more than anything. Fortunately, there already exists The Reconstruction of ZZT, a reverse-engineered (with Sweeney’s blessing) version from 2020 that compiles to identical binaries.
ZZT is a subject that deserves much more detail than I can give it in an introductory post like this. Maybe later….
Did you ever play Wario Land 4 on the Gameboy Advance? It was the last “classic” Wario Land game before its team switched over to making WarioWare games. If you’re a gaming, or at least a Nintendo, enthusiast you probably know what WarioWare games sound like, that endearingly weird crushed and echoey sound, but you might be surprised to discover that Wario Land 4 sounds of a piece with the Wario Land titles! Here’s the intro, hear for yourself:
Here’s the original WarioWare’s intro to compare its sound to. It’s all the good stuff!
geno7 over on Youtube (who has a terrific home page, by the way!) did a 51-minute deep dive into WL4’s sound design that’s just the kind of obsessive attention to detail that our cadre of pixel art loonies appreciate! Have a gawk and a listen and see if you agree.
Bahamut is one of the oldest traditions in Final Fantasy, going all the way back to the first game, where much of the game’s bestiary came directly from the Dungeons & Dragons books. Yet Bahamut was not fightable in that game, they wouldn’t fall into their standard role of challenge encounter until the third Japanese game. Like many D&D creatures, and JRPG creatures too, Bahamut was a borrowing from a mythological source. They were one of the entities upon whose back the world is carried. Observe:
Which of these entities is “dragon king” Bahamut? The person is just an “earth-bearing angel.” The bull is Kuyuta. Bahamut, or “Bahamoot,” is the fish. What’s more, it’s thought that the name derives from Behemoth, from the book of Job, despite Behemoth not being a fish. But Final Fantasy already has a Behemoth….
None of this proves much of anything. RPG writers, both tabletop and videogame, have long just pulled anything out of mythology, and sometimes more recent literature, that they wanted and just used it, regardless of author, age or culture. Gary Gygax had a Monster Manual to fill, he didn’t have any internet to help him fill it, but lots of other people enthusiastically used his bastardization, to help them compile their own bastardizations. That’s what most game lore is when you get right down to it: it’s bastardizations all the way down.
This is just a fraction of the edifying enfo, er info, in the article, a link to which awaits you here:
Here’s another of those deep-dive NES internal videos from Behind the Code, possibly the most complex one they’ve done to date. Most game engines, when you examine their basic logic, are basically physics simulations, with some AI included to determine how actors behave.
Not so with the Punch-Out!! games. They are essentially entirely different kinds of games from that. You have certain things you can do moment to moment, and opposing boxers do too. Each of those opponents basically runs a big script, made out of byte code, that determines their behavior throughout each round of each fight. I am struck both by the simplicity (no need to simulate gravity) and the complexity (boxers take all kinds of things into account) of the system.
One of the interesting things shown is that the engine can affect more than just the boxers, but can also subtly affect the crowd, which is how the previously-revealed fact that a specific camera person in the crowd uses his flash right at the moment the player must counter Bald Bull’s charge move. It turns out that this isn’t the only instance of this happening in the game!
You don’t need to know 6502 assembly code to get what the narrator is talking about, but a lot of code is shown, so those of you who understand it may get a bit more out of it. Here are a few basics to help you follow along.
The 6502 has only three registers (bits of memory internal to the CPU that can be accessed quickly), the Accumulator (sometimes called just A), the X register, and the Y register. Each is only one byte long. The Accumulator is by far the most flexible, but all three are general-purpose registers. The most common instructions are Loads (LDA, LDX, LDY), Stores (STA, STX, STY), Transfers between registers (TAX, TAY), Incrementing and Decrementing (INX, INY, DEX, DEY), Adding (ADC), Subtracting (SBC), Comparing (CMP), Branches (some of them, Branch Not-Equal to Zero: BNE, Branch Equal to Zero: BEQ, Branch of Carry Set: BCS, Branch on Carry Clear: BCC), Jump (JMP), Jump to Subroutine (JSR), and Return from Subroutine (RTS). While some instructions are just one byte long, the longest any 6502 instruction can be is three bytes, and the opcode (the command itself) is always just one.
(I wrote all of that from memory. I figured, I have all of this in my head from my coding youth, I might as well use some of it.)
The 6502 can only address 64K of memory, so often systems will use bank switching to connect various memories to it within that space. The great majority of NES/Famicom games had to do this. Punch-Out!! was unique on the NES in that it was the only game to use Nintendo’s MMC2 chip. (I wonder if the chip was designed ahead of time, and they made this game as an excuse to use it?) Punch-Out!! uses MMC2 to bank in each boxer’s large data script as needed.