These days, if you’re playing a game with multiple versions, there’s usually one specific version you want. For pre-Crash games, if there’s an arcade version, most of the time, it’s the one you want. After the Crash it becomes less definite. Super Mario Bros. at home is a much more playable game that the arcade version. Vs. Super Mario Bros., which is hungry for those quarters. For games like Smash T.V. though you still usually want to play the arcade version.
The arcade and PC Engine CD version of Gradius II though are a much closer call. In a couple of places this home version is actually slightly better, or slightly harder, than the arcade original. It also contains an extra level that’s missing from the arcade.
Inglebard Gaming on Youtube has played through both games entirely and shows them to you side by side, so you can decide for yourself!
On Romhack Thursdays, we bring you interesting finds from the world of game modifications.
First, I’d like to fill you in a bit on the world of supplemental chips included in cartridges.
The greatest advantage of cartridges as a software distribution medium is that you can include extra hardware in the cart that extends the capabilities of the system. The inclusions, ranging from a few extra logic gates controlling banking to static save RAM and batteries to supplemental microchips to entire coprocessors, goes back to at least the Atari VCS/2600, where they played a major role in extending that console’s lifespan. The VCS only had 128 bytes of RAM, a ROM address space of a mere 4 KB, and didn’t even have lines going out to the cartridge for writing to external memory. In spite of these fairly dire limits, regularly games for the system would far surpass what was expected by its creators, culminating in the DPC chip used in Pitfall II.
It’s not true that you can do anything with extra hardware in a cart, but you can push the limits quite far. The inclusion of extra circuitry in the cartridge is what allows Champ Games to make their amazing Atari arcade ports (such as Mappy and Scramble).
After the VCS/2600 fell out of popularity the NES came along, and extra chips of this sort became almost mandatory. The tales of Nintendo being hampered by the chip shortage at the time of the NES’s popularity limiting production are true, but are also somewhat self-inflicted. Legions of popular games required at least a MMC1, a chip that could have been included in the base console, or supplied in an add-on peripheral like a pass-through cartridge. But instead Nintendo chose to include one with every game that required it, and also MMC3s, some MMC5s, and a handful of other chips.
Then the SNES came along, and more extra chips entered the picture, most notably the DSP, the SA-1, and most famously the SuperFX. The SA-1, basically a coprocessor for the machine’s overworked Ricoh 5A22, a variant of the WDC 65C812, which was itself a 16-bit version of the venerable MOS 6502, is our focus here.
Extra chips in SNES carts weren’t nearly as essential as they were for most NES games, but there were still a good number of them. In the early days of the SNES extra chips like these were not hugely common, although a DSP was used even in one of the system’s launch games, Pilotwings. On the other hand F-Zero, a game remembered fondly for its great sense of speed, didn’t use any special chips.
The SA-1 was one of the more powerful of these chips. It was basically a second 65C812-type chip running at triple the main CPU’s clock speed, with a small amount of dedicated memory and some other minor features. Most famously it was used in Super Mario RPG, but it was also used in both of the SNES Kirby games.
The SA-1 wasn’t used in that many games, and it wasn’t even available for use, I think, in the system’s early days, which was a shame. The power of the SA-1 was quite great, if used correctly. SNES hacker Vitor Vilela has made a growing number of hacks that recode classic SNES games to use its calculatory prowess, and the difference is often quite dramatic.
There’s a lot of stuff there on his Github page that I’m going to save to present later, but one of their earlier projects, and one of the best I’d say, is his conversion of SNES Gradius III to use the SA-1. Gradius III is probably the SNES game in which slowdown is the biggest problem, it is not hard at all to get Gradius III into a state where the game slows down to half speed, or even one-third speed, simply by loading up on Options and powerups. As a difficult game where slowdown makes it much easier (and it may have been designed around it), and as a SNES launch title with great graphics and sound, it’s still playable without the SA-1, but you can nearly hear the processor creaking under the weight of all those projectiles and effects.
With the SA-1, all of that slowdown is just gone. It makes the game a fair bit harder, but also a lot more fun to play. See for yourself:
And now, look on in horror at a deathless playthrough of Gradius III with this hack:
On Romhack Thursdays, we bring you interesting finds from the world of game modifications.
Gradius for Famicom and NES is a well above-average port of a game for very different hardware than the arcade original. It was good enough that it was converted right back into arcade game, released for Nintendo’s Unisystem arcade hardware as Vs. Gradius. Graphically and aurally, it is quite similar to the arcade game.
It’s similar, but not identical. Now this hack doesn’t change the major downgrades from arcade Gradius. There is no vertical scroll in levels two or three, and you still can only have two Options at once. But in a variety of subtle ways, the game looks a bit nicer. In particular, the game’s text fonts being changed from the boring old font used on the NES back to the arcade’s snazzy line-drawing affair is a nice change.
The original version of this is quite an old hack, created back in 2000, but it has been periodically updated over the years, most recently changed in 2018. That’s a long period of support for a romhack!
“We scour the Earth web for indie, retro, and niche gaming news so you don’t have to, drebnar!” – your faithful reporter
It’s a rare day that we get to link to the Washington Post, in this case a piece by Michael Cavna on the death of Yu-Gu-Oh! creator, mangaka Kazuki Takahashi. Hey there Michael! Bet you never thought your work would be linked by a single-celled pixel-art organism! Can you ask them to do something about their ludicrous paywall drebnar? Yu-Gi-Oh! is only tangentially part of our purview here but there have been enough video games from that series that we can probably make room for it under Retro, plus it’s published by Konami. One of my favorite facts is that the card game includes several cards that officially refer to the Gradius series, including cards of the Vic Viper and Big Core.
Elliot Williams at Hackaday challenges us: You think you know how Mario Kart works? I think so? You supply electric potential through a wire to a console loaded with some game software, which sends signals to a video screen, and you use a wired controller to interact with it. Yes, I win! His article just links to a video (see above) about how the AI drivers work. This subject has been thought of so much that there’s a patent on such drivers granted to Lyle Rains for his work back in the early days of Atari, in 1979! That it took 20 years for that to expire is a blight on the history of game programming, drebnar!
PC Gamer’s Rich Stanton tells us that Yuji Naka is still angry at Square Enix for removing him from the Balan Wonderworld project. He accurately notes that the degree of acrimony from Naka about this is unprecedented-Naka is pissed and doesn’t care who knows it. The article suggests listening to both sides here. Here at Set Side B we admit, we tend to take the word of developers over those of gigantic corporations, especially when the developer is someone of Yuji Freaking Naka’s standing! We may be wrong, and if the word comes out that we are we’ll cheerfully admit to it, but it is easy for me to believe, in Naka’s words, that Square Enix “doesn’t care about games.”
It’s a good day for linking to non-gaming sites! At CNBC, Ryan Brownie warns of a coming contraction of the games industry, partly due to it coming down off the boost caused by the pandemic, and also from bottlenecks produced by Russia’s invasion of Ukraine.
We’re back for another Sundry Sunday! Congratulations for making it another week into our technological hellscape! Your reward is another catchy tune and some information from the old days of arcades.
Gradius is a long-lived and storied series of shooters, full of interesting details and traditions, but my favorite part of it all is something not a lot of English-speaking fans may be familiar with.
The first arcade releases of Konami’s Twinbee and Gradius were produced using “bubble memory,” a type of storage that had to warm up, literally, to be read reliably.
It would work effectively if it had been running for at least a couple of minutes. So, to prevent anyone from playing the game too soon after the machine had been turned on in the morning, it would display a countdown on the screen. It would also emit a digitized voice, saying “Getting ready!” and then after a few seconds, it would play the MORNING MUSIC, while the computer warmed up, as in the video embedded above. I kind of think of it as the national anthem of arcadeland.
One of the quirks of Gradius‘s bubble storage is that it was read sequentially, from a starting point. Its stage layouts were stored in this memory. Dealing with this hardware quirk required the game, when the player lost a life, to return back to the last starting point they had passed. This was the source of one of the Gradius series’s major characteristics, having to return to a previous part of the level, which could then be read into memory going forward once again.
I forget where I heard this factoid, but I think I saw it in the supplemental material in the Gradius Arcade Collection, out on Steam and Switch, and no doubt other platforms. Hey, it’s Sunday, I’m not supposed to be stressing out about these details!
