Supercharger Improvements in v0.54.0

Gopher2600 has supported the Atari2600 Supercharger for several years. However, in recent weeks some longstanding flaws and some newly identified ones, have been addressed.

The improvements relate to the way in which both tapes and binary AR files are loaded. The latter in particular being now being accessible to people without access to the real Supercharger BIOS.

The TAPE load register

The TAPE load register is a reserved address that is used by the BIOS to receive data from the tape input of the Supercharger cartridge. The address of this register is $xff9 in any of the cartridges mirrors.

In the real hardware, reading this address simply returns the data that is being supplied by the tape at that moment. In our emulation however, we also use the access of this register to control the automatic playing of the virtual audio tape (a WAV or MP3 recording of a real Supercharger tape).

That is, rather than require the user to start and stop the audio tape, the emulator automatically begins to stream the audio data once the TAPE register has been accessed (frequently within a period of time).

Similarly, once access of the TAPE register has ceased, the streaming of the audio data is stopped.

We also use the TAPE register to activate the bootstrapping of data from a binary AR file. Prior to v0.54.0 the use of the TAPE register to facilitate bootstrapping has been problematic.

Phantom Access of TAPE

Using the TAPE register for bootstrapping fails when non-BIOS code accesses the register. Accessing the register can be intentional or unintentional.

An example of unintentional access can be seen in the game Suicide Mission.

In Bank 3 of Suicide Mission at address $1ff8 there is an RTS instruction. This is a one byte instruction but because of how the 6507 works, there will be a phantom read of the next address. The next address is of course the TAPE register.

This isn’t a problem for the real hardware, but for our emulation it causes erroneous bootstrapping of AR files. In the case of Suicide Mission and likely other games loaded from an AR file, the game would immediately crash with a CPU KIL error.

As of v0.54.0 the emulation handles phantom accesses by ignoring TAPE accesses that follow a specific pattern. The pattern is very simple: handling of auto-loads and bootstraps only occurs when the access was not preceded by an access of $1ff8 or $1ff9.

Loading from a virtual audio tape worked but it did mean that silently in the background, the tape was always “playing” in the background. While it didn’t create a problem, that behaviour has been corrected too.

Intentional non-BIOS Access of TAPE

My original fix for the phantom access problem was to do nothing (ie. no auto-load or bootstrapping) unless the BIOS was active. That’s a good solution except it prevents intentional access by non-BIOS code.

And as it happens, I came across an example of such a ROM while I was working on the problem. This ROM helped me to better understand the problem and to arrive at the superior solution described above.

A video of this ROM, a Morse code decoder, is shown below.

Currently, Gopher2600 requires the audio to be concatenated into one file. Future versions may support the ability to specify more than one file, or even reading from the computer’s microphone port.

The WAV file used in the video above can be download here

Fake Supercharger BIOS

As of v0.54.0 it is possible to load AR binary files without a real Supercharger BIOS.

Previously, a file containing the real BIOS was required. It was to be provided by the user and stored in Gopher2600’s configuration directory (full details in the project wiki)

A real BIOS is still required for loading from a virtual tape but it should never have been a requirement for binary files. Loading AR binary files now uses a built-in fake BIOS.

Future Changes

Although Gopher2600’s emulation of the Supercharger device is very advanced and arguably the best available from any current emulator, there’s still room for improvement.

The next enhancement will likely be better MP3 decoding. The code for decoding MP3s is one of the few areas of Gopher2600 where I uses a third-party module. As it happens, the module I chose has flaws and cannot cope with all MP3 encodings even when the quality is seemingly sufficient.

It’s likely that I will still use a third-party solution but I’ve not yet settled on one just yet.

Another improvement, mentioned in passing already, is the possibility of loading audio from the computer’s microphone port. This would be a nice feature but I’m reluctant to add code that gathers data from the user’s environment because the intention of the code could easily be misinterpreted.

A better option might be to allow loading of data from a named pipe (if available via the operating system), leaving the user to plumb the pipe as the see fit. This requires more thinking.