Tag: coprocessor

Romhack Thursday: Race Drivin’ using the SA-1

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):

SA-1 Root: Race Drivin’ (github)

Romhack Thursday: Gradius III using the SA-1 chip

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:

How David Crane Got Good Music Out Of The Atari VCS For Pitfall II

Back in 2013, David Crane chimed in on a thread about Pitfall II. The Atari VCS (a.k.a. 2600) was not known for the quality of its music. For sound effects, especially noise effects like blasts and booms, it was fine, but its TIA chip didn’t have the frequency resolution to produce every musical note precisely, meaning some of it notes would sound a bit off.

Pitfall II’s music, some of the best on the system in the classic era

There was technically a way to produce almost arbitrary waveforms, though like many techniques on the system it was processor-intensive. It involved changing the volume on one of its sound channels in real time to simulate the waveform of the sound you wanted to make. That was fine so long as you didn’t need the processor to do anything else, and sadly, on the VCS, just displaying graphics relied heavily on the processor.

Pitfall II, VCS/2600 version. Image from Mobygames.

David Crane managed to get decent polyphonic music out of the VCS by using Pitfall II’s DPC chip, which Crane created himself, as a co-processor that figured out the right values to set the volume to produce the mixed waveform for the music at a specific time, which the machine’s overworked 6507 CPU could then read and send to the right volume register in the TIA every scanline. The process is explained (to the understanding of a sufficiently technical frame of mind) here. I think I understand it myself!

The fact that David Crane is still around, and so willing to discuss the many tricks he came up with to make his games, is a great blessing, as is the existence of the AtariAge forums themselves, which are a trove of classic gaming information.

Nowadays this technique has been refined and utilized in homebrew cartridge productions. A particular standout is the music from Champ Games’ version of Mappy, which is frankly amazing. Check it out:

Video: Its Programmer, On SNES DOOM

I’ve been doing a lot of high-effort posts lately, even for things that should be fairly quick. Working to make this more sustainable, here’s a laid-back post that’s mostly just a Youtube video of a talk between the guys of Digital Foundry and Randy Linden, coder of the SNES port of DOOM, which uses the SuperFX chip to make the hardware push polygons at a rate that, while not stellar by PCs-of-the-time standards, at least not abysmal.

Let’s run down the differences of hardware:

PC running MS-DOS: targets VGA monitors, displays all its pixels in software, but makes up for it with a minimum requirement of a 386 running (if memory holds up over nearly 30 years) at 33 mHz.

SNES: Its processor is a much slower workalike of the 65C816, a 16-bit version of the 6502, running at 3.58 mHz. While it makes up for its slower clock speed with a simpler design, meaning instructions complete generally in fewer cycles, it’s hard to make up for that 10-fold difference in speed.

Their use of specialized graphics hardware was an important advantage, at the time, of consoles over personal computer hardware. Even many standard home microcomputers, like the Commodore 64 and Atari 800, had dedicated graphics hardware that helped games run better than what most PCs could do. Even when VGA came out, the standard had no hardware-level support for scrolling or sprites.

Consider what it takes to scroll a screen without hardware support: something in the system has to be able to move every pixel from one spot on-screen to another. The NES pulls this task off by having a bank of memory that its PPU can be pointed within, meaning the memory could stay in the same place, and the graphics chip would just work from a different region within it. Sadly, this technique is not amenable to 3D graphics, which usually do require every pixel on the screen to be recalculated every frame, either in software or hardware.

The SNES is known for having a rather slow chip for its time, but more demanding games tended to make up for it with co-processor chips included on the cartridges. The most well-known of these are the DSP-1, which functioned as a math co-processor; the SA-1, which was basically a second 65C816 running at around triple the speed and with a few added features; and the SuperFX, which ran at about the SA-1’s clock speed but functioned as a graphics accelerator. (The later SuperFX 2 ran at twice that speed.)

These were far from the only add-on chips included on Super Famicom and SNES carts. Since the SNES had a much larger address space than the NES’s 6502-clone, the need for mapper chips was much less, but these co-processors were used in a number of more notable games to help it make framerate goals.

Hm. Well, I tried making it a laid-back kind of post. Ah well, back to playing Live-A-Live.

DF Retro: The Making of Doom on Super NES – The Original ‘Impossible Port’