The title refers to an ongoing series with two videos so far. Part 1 (28 minutes) is about how the tokenizer works and how programs are stored in memory, and Part 2 (19 minutes) is on what the BASIC interpreter does to execute the program as it’s running. These are pretty detailed and a bit technical, but interesting of these kinds of shapes can fit into your brain. More below.
I’ll distill the basics of the videos for you. Commodore BASIC is a dialect of Microsoft BASIC. It puts the loaded program at the bottom of memory, starting at 2049, or $0801 in hex. (The custom on the C64 is to denote hex numbers with a dollar sign.) When lines are written, the C64’s screen editor start from the beginning looking for a line number, and if it’s found tries to tokenize the rest of the line. Unrecognized keywords are still stored as PETSCII characters (which will cause a syntax error when run).
Commands are matched against a list of keywords stored in ROM. All the keywords are stored as “tokens,” single bytes, to conserve program space and to help with execution speed. At runtime, the tokens are detected by their high bit being set, then run through a lookup table. It pushes the high and low bytes of the command’s address in memory then does an RTS, which then jumps to the routine by acting like it’s returning from a JSR. Notably, the short routine that gets the next byte of BASIC text to act upon, CHRGET, is actually copied into zero page RAM to run, to take advantage of faster zero page versions of some instructions, but also because it’s self-modifying.
I could link the things that everyone already knows about, that people in that wretched hive they call Reddit have already linked five times, that have blown up on social media, that there’s already a Youtuber or two making snide comments about. I mean, I’ve linked stuff like that before, pretty often really. They aren’t hard to find.
But I’d much rather link something interesting that’s basically unknown. Help spread the word about it! The only problem there is, how do you find that stuff in the first place? It’s a bit of a chicken-or-David-Egger. I think that’s what you’d call it, sure.
So when I saw someone I follow on Bluesky wrote out nearly every Nintendo video game property, including those that appeared on niche platforms like Virtual Boy and Satellaview, primarily so they could boldface the ones that have arrived on Nintendo Music, I had to run directly here to link to it.
The beginning of a long list
I don’t vouch for its total accuracy, but it still could be a useful resource. In fact I know there are some things that are missing, like their early arcade games Sheriff or Radar Scope, just for starters. But if the idea is to present things that realistically could present soundtracks included in Nintendo Music, it’s a pretty good list.
We linked to a Skawo video yesterday, the one about flash card rumble motors activating when playing Link’s Awakening DX. Well I happened to have this one open, so here’s another: the last gasps of a failing PPU chip, shown off in several games. (5½ minutes)
It starts out seeming to work okay, but it isn’t long before it becomes obvious that something very wrong is happening. If you ever wondered what a failing graphics chip looks like, well, this will show you one example of it happening. Chips can fail in any number of ways, and there’s no guarantee that another PPU in the process of expiring will expire in the same way, but this is the kind of thing that can happen.
The Game Boy doesn’t have a Rumble Pak. Of course it doesn’t; where would you slot it? But a few games were released for the Game Boy Color (and Game Boy Advance too) that have built-in rumble motors. Because of this, it’s impossible, with unmodified physical hardware, to separate the Rumble from the Pak. If the game supports rumble, it has the motor included; if it doesn’t support rumble, it won’t have the motor. Pretty simple.
Except. Some people discovered, if you put Link’s Awakening DX onto some flash carts with a rumble motor included, there is a point during the game where the rumble will activate. Skawo on Youtube looked at the game’s code and sought an answer as to why. (10 minutes)
The tl;dw: GBC rumble motors are controlled via a MBC5 chip, a chip not dissimilar to the now-famous MMC line of chips on the NES/Famicom. Writes to ROM space are caught by the chip and used to activate functions. The main purpose for these chips is to switch between memory banks, but one bit in the written byte activates or deactivates the motor. Link’s Awakening DX uses a MBC5 and a miscoded write that activates any included motor. The MBC5 usually ignores these writes because it checks the cartridge header to see if it includes rumble support, a check that fails for this game, but GBA flash carts run will use an emulator to run GBC games, and if the emulator is inaccurate it might trigger rumble motor regardless of any header.
So why is the value written anyway? I’ll leave that for the video to explain, but it has to do with the additional save information added for the Color Dungeon, and an issue in the game when it saves puzzle completion data for areas that aren’t in dungeons.
It’s been possible for quite a while to increase the framerate of SNES Star Fox. Even during the SNES’ hardware release period, an updated version of the SuperFX chip that made it’s then-amazing 3D visuals possible was used that doubled its performance, and was used in other games like Yoshi’s Island. And now overclocking and emulation can increase SuperFX performance by much more.
But there’s a problem with speeding up Star Fox this way. The game wasn’t designed that the frame rate can be separated from the gameplay or animations. If you speed up the chip, you’ll speed up everything else in the game too, rapidly making it unplayable.
Some progress has been made recently towards improving the framerate without making it a twitchy stuttery mess. Tyler Loch made a video of his efforts (3½ minutes), and to people used playing Star Fox’s at its original 15fps it’s a wonder to behold:
Because the code has to be adjusted in many different places, there are parts of the game that are obviously incorrect. Falling pillars, you’ll notice, tilt over much faster, bosses move and fire much more rapidly and are more dangerous as a result, and the engine of the player’s Arwing spaceship flashes at a rate that some people may not appreciate. And the video shows off only the first level, because the full game isn’t finishable yet. But much progress has been made! Let us hope Tyler’s momentum holds up through the rest of the project.
I’ve already introduced The Bard’s Tale in prior posts, so in brief: The original Bard’s Tale trilogy were all Wizardry-style dungeon exploration RPGs in the classic style, called by some “blobbers.” Indeed they did a lot to define that style. A few things that Wizardry did weren’t adopted by later blobbers, especially its particular form of permadeath, its simulation of “Out” parties and retrieving lost characters from the dungeon, and its willingness to obliterate your entire group instantly and permanently if you teleported into solid stone.
The Bard’s Tale, on the other hand, looks exactly what the standard picture of a classic blobber looks like today. So long as you have the cash to revive a character there is no real penalty for dying, there is no absolutely solid stone to teleport into, and there’s no concept of “Out” parties, for if your party wipes their corpses get mysteriously teleported back to the Adventurer’s Guild, where if there’s enough gold in their cold pockets you, I guess in the capacity of being a caring guardian spirit, can tell the priests to bring them back to life.
But while not as eager to annihilate members of your group, neither is The Bard’s Tale an easy game. Compensating for the lack of permadeath, dungeons tend to be much more diabolical in design, with magical darkness, teleporters, spinners and antimagic zones in evidence. Dungeon levels are bigger than Wizardry’s, there are more of them, and most significantly to a new player, “Town,” here named Skara Brae, isn’t a simple menu of options but an entire level of its own to explore! And at the start of the game, you don’t know where anything except the Adventurer’s Guild is! You have to do significant mapping before you can buy equipment, recharge your spell points, or even raise your experience level.
In this 7th installment of the video series, the player finds and begins to explore the third of the game’s dungeons, finds some interesting items, suffers from disk corruption and loses some progress, earns it back, and fights a jabberwock.
Way back in 1984, having had success with their first product Softdisk, the nascent Softdisk Publishing released the first issue of Loadstar, a “magazine-on-disk” for Commodore 64 microcomputers.
Softdisk is mostly known these days as being the former workplace of several people who would go on to found Id Software, creators of Commander Keen, Wolfenstein 3D, Doom and Quake. Softdisk published, as the Id guys’ last work for the company, Catacomb 3D using the Wolf3D engine, and a Commander Keen episode.
Softdisk released other products too, but Loadstar eventually proved to be something special. Early on they assumed that their PC and Mac products would be their legacy, but then Microsoft and then the internet came along and it suddenly became much harder to make a go of it with a monthly paid software collection. Softdisk became an ISP; they got bought out by a bigger ISP; nowadays they don’t exist really, except as a bag of rights owned in pieces by Piko Interactive and/or Catacomb Games, who bought their Id-related assets.
The cover of Loadstar #72, the last issue sold on newsstands.
But some time before then Loadstar and its relevant assets had left the company. Defying expectations and buoyed by the large userbase of the Commodore 64 (quick googling suggests they sold 70 million units), Loadstar was still doing fairly well for itself. It was no longer sustaining the whole company like it once had, but it was too large an audience to ignore. So Softdisk spun Loadstar off to J&F Publishing, under the captaincy of its longest-serving Managing Editor Fender Tucker, and they kept the lights on a while longer.
When Fender retired from Loadstar at the dawning of the year 2000, he passed managing editorship over to Dave Moorman, who kept it going for 49 more issues. It was starting to become hard to find new things to keep Loadstar going at this point. While Dave had some regulars sending in new things, a large back catalog to mine for material, and skill enough to write some software for Loadstar himself, its release rate slowly dropped from monthly to, in 2007, two issues in that year. Then a tornado his his house and destroyed the tools he used to make Loadstar. One more issue made it out in the following year, that had been in production and finished by Ricky Derocher in 2008. And that is where Loadstar’s story ended.
Next, what I’ve been doing
A year or so ago, with the permission of Fender who still owns Loadstar and J&F Publishing, I threw together something called Loadstar Compleat. A prior product also called that had been sold by Fender for some time, a CD-ROM with the 199 issues from before and during his run, along with the 42 issues of another magazine, Loadstar 128, and various other products and odds and ends.
I took the issues from there, replaced some bad copies with better ones provided by Ricky Derocher, added in the 51 later issues from Dave Moorman’s editorship, and added a kind of shell program to make browsing and searching through them all easier. I packaged this all together and threw it up on itch.io as Loadstar Compleat for $15. Since then I’ve now also given three talks on Loadstar and its history, in person at VCFMW 2025, virtually for TPUG, and three days ago also in person at VCFSE 2026. (There should be video of that soon, I’ll link to it here when it enters my notice.)
Now, possibly, the future
Loading screen for early Loadstar issues
Dave has always said he wanted Loadstar to last to its 256th issue, to make it an even binary number (28, or 100000000). Even though Loadstar only had about 100 subscribers left by that point he was still committed to doing it, and only the fury of nature prevented him from making it.
I mentioned this at VCFSE, musing that perhaps I could finish the task he had started, making a final six issues of the venerable disk magazine, and a couple of people there thought that it might be a good idea. And I think I have enough knowledge now of Loadstar’s underpinnings that I might be able to accomplish this. With all the tools available for producing software for retro platforms now (I have an upcoming article on those in the works), it is arguably easier to make C64 software than it’s ever been, and now that there’s the Ultimate64 and Maxi65, the size of the C64 platform is growing once again.
So, let’s start making plans for how this could happen. In addition to doing whatever needs to be done to understand Loadstar’s file formats to get its Presenter system to fulfill our purposes, I figure we need:
Contributors, and contributions. Commodore 64 software, hi-res artwork (at least one image for each issue for the loading image), SID music (at least one piece per issue for the Presenter background music), articles and anything else we’d need to keep up Loadstar’s standards according to the systems they used in their late period, which used a polished Presenter menu program written in machine code, a text reader to display documentation and articles, and miscellaneous other niceties.
Means to compensate them. We aren’t sure if this can support itself financially yet. For right now, we need to keep our options open. If we get a lot of interest it’s not out of the question that this could mean a bit of actual money, but for now free issues are what we’re considering.
A means to produce physical disks. These issues would be sold digitally (as .d64 and .d81 disk images for emulators), but it feels like to be a real disk magazine, there must be actual Commodore-formatted 5 1/4″ and/or 3 1/2″ disks to sell too. You can still get 5 1/4″ disks. Amazon sells them ten for $25.
Middle-period loading screen. (Later issues used custom loading screens for each issue.)
We’re currently discussing ways to accomplish these things. I’ve started a thread at loadstarce.com to discuss this project. We are fortunate that many of the Loadstar editors are still around, including Fender Tucker, his associate editor Jeff Jones, and Dave Moorman, as well as people who care about Loadstar’s memory like Ricky Derocher.
There are two things we need right now. The first is indication of interest. Would you be interested in buying something like this? How about spreading the word about our little venture?
The other thing we need is “content”: software, writing, art and music, in formats appropriate for the Commodore 64. C64 art must be hi-res VIC-II format. Music can’t just be any old SID tune but in the format its Presenter used (more information on that as I determine it). Software doesn’t have to be machine code, for Loadstar published many BASIC programs, and multiple BASIC extensions too, including one, Dot.BASIC Plus, that still has a website and working downloads!
Are you any of you interested in, and capable of, providing these things? I don’t know how much we can pay you yet. For my part I will make the rounds online and approach people who might be interested in helping revive Loadstar, if just for a little while.
And who knows, if this proves popular enough, maybe we could go past issue 256? Shooting for 512 seems like a ludicrous dream, certainly not something I could do in my remaining lifetime, but who knows for sure? Let’s dare to dream.
If you want to be involved in the continuation of the frankly improbable legacy of Loadstar, you can reach me:
Recently we posted a link to an excellent video that took a look at every software product (Bandai-)Namco has made that had the temerity, the utter gall to call itself “Namco Museum.”
Since then however, its creator Mythic Resonance became dissatisfied with how it turned out, so he took it down for a bit for some editing. Well, it’s back now, and at 2 hours 23 minutes it’s even more complete and in-depth as it was originally.
We’re promised new entries, updated information and corrected errors. He admits that it may still not be absolutely perfect, but of course projects as lengthy and effort-intensive as this one will probably always have something about them that could still be improved. He says it took him 35 months in all to make it, so I’m willing to grant any deficiencies it still has, if just to help Mythic Resonance preserve his mental health.
While it’s seen more than one revival since its original release by New World Computing (the Heroes of Might & Magic series, and the 2008 series titled King’s Bounty by Katauri Interactive), that first version is still a fine game to play even today. Players explore four continents raising armies, fighting hordes of monsters, building income and leadership, collecting artifacts and bringing a variety of colorful villains to justice.
The game simulates the passing of time, which affects a number of things. Every week (five game days) you get income from the king of the realm, but also must pay your troops and other miscellaneous expenses. There is a time limit (determined by the game’s difficulty level), preventing you from passing weeks for income. While you’ll probably fight hundreds of battles in a typical game, technically speaking you can win without fighting any: bringing villains to justice earns you pieces of a map, a depiction of one screen of the game’s vast scrolling area, and the win condition is to find that screen and search for a lost scepter on its center location. While the maps are the same every game, nearly all the locations of the wandering monsters, treasures, villains and other important elements are randomly placed each game, giving King’s Bounty tremendous replayability.
A true classic strategy wargame, King’s Bounty was widely ported, to DOS, the Mac, the Atari ST, even to the Commodore 64 (that must have been a difficult job), and there’s also a surprisingly good rendition for the Sega Genesis/Mega Drive that might be the best version, and was implemented in-house by New World Computing themselves (they did a similarly great version of Might & Magic II for that system).
Dan Heskett has recreated the engine of King’s Bounty and put the code on Github. You’ll need the files of the original DOS disks to use his code, but if you don’t care to go that route you can instead play it in your web browser. The keys are the same as the DOS version; use this PDF of the manual to learn how to play. The Github Readme has a wealth of information, not just on how to build the recreation but of the internals of King’s Bounty. It even includes two autoplayers, one that simulates a game as a human would play it, the other a game played with perfect knowledge of the game world.
Note: I have noticed a couple of bugs in this project. I am giving this project the benefit of the doubt that it was not generated by an AI system. If I discover otherwise, I will mention that fact here.
The world is full of traps for the unwary. There’s a whole genre of movie, mockbusters, that exists purely to try to catch people who are only vaguely familiar with some media property, and they make enough money that by cutting their costs extremely thin they can be profitable. Mobile app stores are full of games that try to trick people in a similar way, making themselves look as closely to some popular game as they can get without becoming legally actionable.
Let us all spare a thought for the poor kids who opened up a bright package on Christmas Day to find this. (Image from Wikipedia)
A similar kind of trap was the Game.com, Tiger Electronics’ bid to compete with the Game Boy. It made a kind of sense, sure. Nintendo got into portable gaming with the Game & Watch series, from there spreading into a more flexible system with replaceable cartridges. Tiger made Game & Watch-style LCD games too, so why couldn’t they do the same thing?
Thing is, Tiger was doing this through most of the 1990s! They kept their costs and prices down and managed to make them profitable by just putting out the most barest games possible, Game & Watch-like LCD games in the era of the Sony Playstation. (Ernie Smith at the excellent blog Tedium wondered at their success too.)
Tiger released their Game Boy competitor, Game.com, in September 1997. It was absurdly cheap at $30, but at that time a Game Boy Pocket was only a little more expensive at $55. I think it’s safe to say the only people who were buying up Game.com devices were extremely low information buyers. But they found 300,000 such buyers. I expect a majority of them were grandparents.
It was named after a Saturn release of the Genesis Sonic the Hedgehog games, and claimed to have Sonics 2, 3 and “and Knuckles,” but not only were all the games strained through the Game.com’s small monochrome screen, they all were drastically cut down. Each has only one level! And it’s barely playable at that!
I’m loving the optimism of that six digit score counter. Screenshot from Mobygames.
Bad Game Hall of Fame did a general retrospective on the Game.com. I personally love terrible janky systems like this, but it’s not because I think they’re secretly good, it’s because, like the mockbuster output of The Asylum, I think they’re hilarious. But I’m not laughing at the kids who were expecting a Game Boy but ended up with this instead.
These days Tiger Electronics exists, as many other game companies from past decades like Milton-Bradley, Parker Brothers, Avalon Hill and Wizards of the Coast, as merely one organ out of the many that comprise the grotesque Frankenstein’s Monster of Hasbro, Inc. Hasbro paid $335 million dollars for them, possibly because they saw something in their then-new Furby product. Nowadays I don’t think Tiger’s name is being applied to any current products, and that’s probably for the best.
Displaced Gamers‘ Behind the Code series, and its companion Talkin’ Code, are probably the best technical examinations of NES games on Youtube. They take games that were the bread and butter of the Famicom/NES in its heyday, products of skilled programmers some of whom had gotten started working on arcade games, and disassemble them, revealing both their the tricks of their trade and the quirks, and sometimes glitches, that made their work unique.
Their most recent examination is the best NES basketball game, Double Dribble. If you’re not familiar with it, it plays and feels an awful lot like it were an early version of NBA Jam, without the teams or players or personality sure, but it does play a mean arcade-style game, which makes sense since it was a port of an arcade game (one that plays, I should say, a hideous vocalized version of the Star Spangled Banner at game start).
Here is the video. (32 minutes) Discussion of the discussion is below it.
Okay, the first surprise is that it that whether the ball goes in or not depends entirely on physics. The game takes the angle of the player to the basket (gotten from the X and Y position of the shot on screen) and sends the ball towards the basket using a lookup table to tell how the ball should move. When the ball arrives, whether it goes in depends on whether the ball is close enough to the center of the basket.
Double Dribble actually just sends the ball towards the basket, and if it’s close enough to the hoop (less than four pixels away), it goes in. Basically, the spot on screen the ball leaves from is what determines whether it scores. Affecting that is that there’s a limited number of discrete angles the ball can be thrown at. Displaced Gamers runs through the math, which is fairly involved, but in short, if you throw at the wrong combination of angle and distance, the ball just won’t go in.
More than that. The big discovery made by Displaced Gamers is that the two hoops aren’t the same! Due to flaw in the math, both hoops’ centers are essentially shifted to the right slightly, and both are also easier to hit when shots are made from the top of the screen, above the basket.
This is only a couple of points from the video. It’s full of the kinds of shortcuts that time-pressed programmers from the age of 8-bit consoles often had to use to make their code work. If you’re allergic to discussions of math (especially trigonometry) you might want to skip this one, but I think it’s worth a look.
The World Wide Web is now over thirty years old. In that time, more content has vanished from it than remains now, but some of it can still be dredged up from the shadowy archives of the Wayback Machine. This is the latest chapter in our never-ending search to find the cool gaming stuff that time forgot….
We here at Set Side B do everything we can to encourage the kind of unhealthy obsession with video game ephemera that is epitomized by these sites. And carrying a torch for a novelty song dating back to the height of the arcade era, that sounds even crazier (“It’s drivin’ me cray-zee!”) than my own obsession with Rampart.
Started in 1994, when readers would have had to browse the page in Mosaic, the length of the site Pac-Man Fever Forever’s legacy now begins to rival that of the song itself. Like all good websites it refers to other pages on this Widest of World Webs, but alas most, if not all, of the sites it refers and links to are defunct now, saddest being that of the song’s creators, Buckner and Garcia themselves.
As countless kids on social media remind me nearly every minute, I am old, and yet I still dimly remember 1981, the year of Pac-Man’s release, which now might as well be the Stone Age. Social Media, the Web, the public Internet and, I seem to remember, electricity didn’t exist back then. But people still listen to Pac-Man Fever, and they still play Pac-Man today, and Bandai-Namco continues to squeeze the hungry lemon-wedge for every final drop of its juice. I maintain that Bally-Midway, R.I.P., was at least as responsible for its worldwide success as Namco was, and it would have been them who’d have sub-licensed the game’s sounds for a novelty song, as they would have for the Pac-Man Saturday morning cartoon show, a whole landfill of tatty merch, and most of the other instances of Pac-mania from the classic age of arcades. (But not Pac-Mania: Atari published that in the US)
We know Gary Garcia has since passed away. Jerry Buckner (IMDB) continues to roam the neon-blue tunnels of the Earth, and he wrote a song for Wreck-In Ralph. We here hope he continues giving breath as long as he wants. Thanks for the tunes, and to Lee Seitz, thanks for remembering them.
