supercharge - alternative to makewav

[JetSetIlly]

I've written an alternative to makewav for making Supercharger WAV files. It's a terminal program and can work on batches of files. There's currently no way of changing the parameters for the WAV file creation, but it uses the same default values as makewav so it should work in most instances.

 

Source code here: https://github.com/JetSetIlly/supercharge.

 

There are windows and linux binaries (for AMD64) in the releases page. If you want to try the Windows binary remember that it's intended to be run from the terminal.

 

 

I wrote this because I wanted a way of loading a Supercharger tape in Gopher2600 without having to go through the manual process of converting a binary file into a WAV file.  As part of that development I wrote the command line interface you see here as a separate project.

 

It currently only supports 4k files but I'll improve on that as I feel the need. I'm also happy to take suggestions, bug reports and pull requests.

 

 

Short video showing the auto-conversion process in Gopher2600.

 

 

 

[alex_79]

Cool. I'll give it a try with my Supercharger.

 

I like the idea of being able to try non-bankswitched games in Supercharger mode in an emulator. In fact, years ago, I wrote a small utility to "clean up" Supercharger binary files (fix wrong checksums and clear padding data) which also converted regular  roms into the corresponding Supercharger binary format, to try them in Stella and see if they would crash in a Supercharger:

 

[alex_79]

4 hours ago, alex_79 said:

I'll give it a try with my Supercharger.

Tried it and the generated audio files load without issues in a real Supercharger.

 

 

[JetSetIlly]

1 hour ago, alex_79 said:

Tried it and the generated audio files load without issues in a real Supercharger.

Excellent. Thanks for testing.

 

It would be good if you could test the audio file after it has been converted to MP3. I can't get that to load here. If it also doesn't load on a real hardware then we can say that the WAV file isn't suitable for conversion for whatever reason.

 

Interestingly, I can load the MP3 files from the "Stella Gets A New Brain" collection. So I think there's something about the construction of the WAV file that's being damaged by the MP3 compression.

[alex_79]

12 hours ago, JetSetIlly said:

It would be good if you could test the audio file after it has been converted to MP3

I did convert a test wav (Oystron) to mp3 using lame v 3.100.
It works with constant bitrate (-b option) set at 128 or 320 kbps, it doesn't at 64kbps.
Using variable bitrate (-V option), it seems to always work with setting from 0 to 3, it sometimes need a few attempts on 4 and doesn't work at all with 5+ values.

 

 

[JetSetIlly]

1 hour ago, alex_79 said:

I did convert a test wav (Oystron) to mp3 using lame v 3.100.
It works with constant bitrate (-b option) set at 128 or 320 kbps, it doesn't at 64kbps.
Using variable bitrate (-V option), it seems to always work with setting from 0 to 3, it sometimes need a few attempts on 4 and doesn't work at all with 5+ values.

Thanks. That's good to know.

 

I'd prefer it if the program would output MP3 by default rather than WAV so this is great research for the future.

[+SvOlli]

A couple of years ago, I did a clean-up of the makewav code. Removed DOS parts and added support for generating audio directly using portaudio. It's available at: https://git.h8u.de/Atari_2600_Tools/makewav.

[+Gemintronic]

9 minutes ago, SvOlli said:

A couple of years ago, I did a clean-up of the makewav code. Removed DOS parts and added support for generating audio directly using portaudio. It's available at: https://git.h8u.de/Atari_2600_Tools/makewav.

 

I appreciate the earlier versions but DOS/Windows support is still very much something I can't break away from in my 2600 dev.

[+Al_Nafuur]

 

4 hours ago, JetSetIlly said:

I'd prefer it if the program would output MP3 by default rather than WAV so this is great research for the future.

Why mp3 ?

[JetSetIlly]

5 minutes ago, Al_Nafuur said:

Why mp3 ?

Smaller files. No other reason. There are other formats producing smaller files of course but MP3 feels like a good solution.

[JetSetIlly]

52 minutes ago, SvOlli said:

A couple of years ago, I did a clean-up of the makewav code. Removed DOS parts and added support for generating audio directly using portaudio. It's available at: https://git.h8u.de/Atari_2600_Tools/makewav.

That's a nice idea.

[+Al_Nafuur]

5 minutes ago, JetSetIlly said:

Smaller files. No other reason. There are other formats producing smaller files of course but MP3 feels like a good solution.

I thought this too, but the wav files produced by makewav are surprisingly small, even smaller than the 192kbps mp3 rips from the "stella get's a new brain" CD.

 

What is the size of the mp3s you created?

 

[+SvOlli]

55 minutes ago, Gemintronic said:

I appreciate the earlier versions but DOS/Windows support is still very much something I can't break away from in my 2600 dev.

Windows support is still in, that's why I chose portaudio: it's multiplatform and supports Linux/Windows/Mac.

[JetSetIlly]

49 minutes ago, Al_Nafuur said:

I thought this too, but the wav files produced by makewav are surprisingly small, even smaller than the 192kbps mp3 rips from the "stella get's a new brain" CD.

 

What is the size of the mp3s you created?

 

I converted Pitfall with supercharge and produced a WAV file of 298814 bytes. Converted to a 128kbps MP3 with lame gives me a file of 109504 bytes. That seems a significant saving to me.

[+Gemintronic]

3 minutes ago, JetSetIlly said:

 

I converted Pitfall with supercharge and produced a WAV file of 298814 bytes. Converted to a 128kbps MP3 with lame gives me a file of 109504 bytes. That seems a significant saving to me.

 

I remember playing with .WAV and .MP3 on my PSP and found .WAV files to load games successfully more often.  But, maybe that's on the PSP.

[+SvOlli]

If you take a look at my demos which are released as mp3[1][2], you'll see that the mp3s are ~31.5k. The original wavs are ~171k. If I remember correctly, the mp3s did work rather well with my SuperCharger. The encoding was done using command line "lame" with default parameters.

[1]https://xayax.net/the_mating_of_the_colorworms/

[2]https://xayax.net/gar_nix/

[Mr SQL]

This is a cool utility, would be possible to add an option to patch the hotspot if the ROM breaks?

 

 

 

[+SvOlli]

35 minutes ago, Mr SQL said:

This is a cool utility, would be possible to add an option to patch the hotspot if the ROM breaks?

This is technically not possible, because there is no generic patch. If you take a look around the old entries in the forum where 2K/4K patching games for SuperCharger is discussed, you'll see that there are different approaches.

 

Let me take a 4k demo I did quite some time ago as an example: I "ported" that about half a year after the release to the SuperCharger. This was rather painful, as the demo was using every single byte of the ROM. So what I did: I asked Thomas Jentzsch, if he could free up a couple of bytes so I could add some code. That code did not prevent the bankswitching, but rather pre-configured the bankswitching to switch to the current bank, effectively doing nothing, once the hotspot has been touched. Not touching the hotspot was not an option, as the full ROM was used as pseudo random data similar to Yar's Revenge.

 

If you really want to use the SuperCharger to play your collection of 2K/4K games it might make more sense to modify the SuperCharger by adding switch to disable the hotspot. That was a common mod back then. But with something very cheap multicarts like the 2600PicoCart around the corner, I don't think it's a good idea, to "de-originalize" the SuperCharger, which has become way more valuable than an average 2600.

 

Also there might be a collection around from "back in the days". And I also like the sport of it having to patch a game you really want to play. This way playing the game turns into a reward for playing a meta-game.

[JetSetIlly]

1 minute ago, SvOlli said:

This is technically not possible, because there is no generic patch. If you take a look around the old entries in the forum where 2K/4K patching games for SuperCharger is discussed, you'll see that there are different approaches

A good alternative might be for the program to simply detect that the ROM can't be converted and refuse to produce the WAV file (unless forced).

[+SvOlli]

The only way to detect this would be a blacklist with md5sum or something like that. Because there's no way by looking at address $FF8 of the ROM image if this gets touched at any time in the game. Running through some kind of emulation does not work also, since the address could be access only after 2 hours of gameplay in a specific situation.

[JetSetIlly]

8 minutes ago, SvOlli said:

The only way to detect this would be a blacklist with md5sum or something like that. Because there's no way by looking at address $FF8 of the ROM image if this gets touched at any time in the game. Running through some kind of emulation does not work also, since the address could be access only after 2 hours of gameplay in a specific situation.

I think a static analysis of the ROM might get you there in 80% of the cases, but I agree that you can never know for sure.

 

[Mr SQL]

30 minutes ago, SvOlli said:

This is technically not possible, because there is no generic patch. If you take a look around the old entries in the forum where 2K/4K patching games for SuperCharger is discussed, you'll see that there are different approaches.

 

Let me take a 4k demo I did quite some time ago as an example: I "ported" that about half a year after the release to the SuperCharger. This was rather painful, as the demo was using every single byte of the ROM. So what I did: I asked Thomas Jentzsch, if he could free up a couple of bytes so I could add some code. That code did not prevent the bankswitching, but rather pre-configured the bankswitching to switch to the current bank, effectively doing nothing, once the hotspot has been touched. Not touching the hotspot was not an option, as the full ROM was used as pseudo random data similar to Yar's Revenge.

 

If you really want to use the SuperCharger to play your collection of 2K/4K games it might make more sense to modify the SuperCharger by adding switch to disable the hotspot. That was a common mod back then. But with something very cheap multicarts like the 2600PicoCart around the corner, I don't think it's a good idea, to "de-originalize" the SuperCharger, which has become way more valuable than an average 2600.

 

Also there might be a collection around from "back in the days". And I also like the sport of it having to patch a game you really want to play. This way playing the game turns into a reward for playing a meta-game.

 

Good example, that was an exceptionally difficult ROM to patch for using the full ROM as random data and including the hotspot.

 

Many ROM's may be easier to patch that jsr or jmp to the region and could possibly be offset.  

 

There may be methods to patch the ROM's dynamically or at least some of them with interesting programming.

 

For example you also created Atari 2600 demo for the C64 where you used the sprite scaling option to match the graphics to the correct size and described there was no way to also do the three levels of Atari 2600 sprite scaling. I encountered the same problem and found a solution for adding three levels of scaling.
 

9 minutes ago, JetSetIlly said:

I think a static analysis of the ROM might get you there in 80% of the cases, but I agree that you can never know for sure.

 

 

I agree maybe some of the analysis could be automated with the emulator detecting and making transmeta changes to the ROM when a common scenario is encountered.