Forty-two

Saturday, July 15, 2017

If you've ever tried one of the many amazing SNES hacks utilizing the MSU-1 audio coprocessor, you may have run across information about volume levels referencing "hardware" versions and "emulator" versions of the same hack, as well as "boosted" or "non-boosted" audio files, and may have been confused by the complicated, and often conflicting information about all of these different variants. I've explained the issue on several forums, but I wanted to go ahead and do a single, unified write-up explaining the issue, as well as the "correct" way to do things. Hopefully this will help clear up the confusion for people new to the MSU-1.

First of all, before I dig into the full explanation, I'll just cut to the chase. THERE IS NO LONGER ANY NEED FOR SEPARATE VERSIONS. You only need one version, and that same version works everywhere. Many MSU-1 hack authors have fixed their hacks and released them as a single fixed version. However, since there are still a handful of un-fixed patches floating around, if you happen to have a patch with both "Hardware/SD2SNES" and "Emulator" versions, the correct combination is to use the "Hardware/SD2SNES" version of the patch with non-boosted audio files. However, if you can't find non-boosted audio files, then you can also use boosted audio files with the "Emulator" version of the patch, but that will not sound as good (see Problem #3 below). If you're not sure whether your audio files are boosted or not, try out the Hardware/SD2SNES patch in an emulator. If the audio sounds really loud/distorted, you have boosted audio files.

Also, if you have an older-revision SD2SNES, you'll need to go into the menu and set the MSU-1 audio boost to max (see Less Hacky Workaround #1 below).

Now, to explain the issue...

First, we had higan. Audio was mixed properly, and .pcm audio files were more-or-less properly normalized. Let's call this the correct patch and correct audio files.

Problem #1:

The SD2SNES played MSU-1 audio too quietly. There was a lot of speculation as to why, but eventually ikari realized that the DAC output was high impedance, and the SNES analog mixing inputs were low impedance, which caused reduced volume. This means the problem is in the hardware, and can't be fully fixed without a board revision.

Hacky Workaround #1:

SNES audio tends to be somewhere in the range of -10dBFS to -20dBFS RMS. This leaves a fair amount of headroom. Therefore, it's possible to simply amplify the .pcm files to remove that headroom, allowing them to be more or less the right volume when played on the SD2SNES. Let's call this boosted audio files.

Problem #2:

These newly boosted audio files are much too loud when played on higan. Maintaining 2 separate audio packs is not only a logistical pain in the butt, it's also a huge amount of storage and bandwidth increase.

Hacky Workaround #2:

Instead of releasing separate audio packs, just modify the .asm code so that any time you write to the MSU-1 volume register, you write a smaller value instead of the original. Patch files are small, so uploading 2 versions of the patch is much easier than 2 versions of the audio files. Through rough trial-and-error, it was mostly settled on $60 being the value used for "full volume" and $30 for "half volume" with anything else such as fade effects being adjusted relative to those values. Let's call this the "emulator version", and the original is now the "hardware/SD2SNES version". These are sometimes also referred to as the "FF version" (aka the hardware version) and the "60 version" (aka emulator version). To reiterate, the hardware/FF version is the original, "correct" patch.

Less Hacky Workaround #1:

ikari realized that he could actually do this same audio boosting in firmware, in realtime, between reading the file and sending it to the DAC. This would allow using "correct audio" files and the "hardware/FF" patch, and still get more or less the correct audio levels. This essentially eliminated any need for HW#1, which in turn eliminated the need for HW#2.

Non-Hacky, Correct Fix #1:

SD2SNES Rev. H includes a unity-gain op-amp on the output of the MSU-1 DAC, which solves the impedance problem, fixing the volume level. Along with LHW#1, all revisions of the SD2SNES can now output the correct volume levels. HW#1 and HW#2 are completely unnecessary.

Non-Hacky, Correct Fix #2:

For those of you with an
older hardware revision of the SD2SNES, it is possible to install a
hardware mod which upgrades the audio output circuit to match that of
the Rev. H. Rev. G. hardware requires an extra step in order to
"downgrade" to Rev. F first, but other than that, the process is
identical for all revisions. I outlined the process here,
but since writing that post, a guy by the username borti4938 has
created a simple PCB which greatly simplifies the process, so I would
suggest checking that out. Once the mod is installed, the hardware is
essentially identical to Rev. H, and the previous instructions will
apply. Use the proper "SD2SNES/FF" patch with properly normalized audio
files, and completely disable the MSU-1 audio boost in the firmware
menu.

Now, technically, with HW#2, boosted audio and the "emulator/60" patch cancel each other out, resulting in the correct levels, so why not just use that version for everything? After all, a lot of patch creators were really annoyed at having to go to all the trouble of boosting their files for HW#1, along with re-uploading everything and writing new documentation, and they really didn't want to go through all of that again. Unfortunately, that leaves us with...

Problem #3:

Actually, this is several problems. First of all, most of the boosted audio files were actually peak normalized to 0dBFS. On the one hand, thankfully this wouldn't cause any clipping, but it does mean that the audio files aren't actually normalized relative to each other. If you don't understand the difference between RMS and peak normalization, the ELI5 version is that with peak normalization, the ONLY THING that matters is the single loudest sample in the entire track. Imagine you have 2 tracks, one is really loud all the way through, and one just has a loud cymbal crash at the end, while the rest of the track is really silent. Peak normalizing these two tracks to the same level means that loud crash at the end will be the same loudness as the entire loud track, so if you listen to them side by side, the entire quiet track will be much quieter than the loud one. This is an extreme example, but if you've ever looked at a waveform visually, this is basically true of any track with a lot of really large "spikes" in volume (the "quiet" tracks) vs tracks which are very "dense" and consistently the same volume. The "spiky" tracks will end up sounding much quieter. RMS normalization accounts for this by "averaging" the volume over time, which gives a better comparison between tracks. Basically, long story short, peak normalized tracks are no longer properly normalized relative to each other.

Now, that's assuming that the tracks were peak normalized to 0dBFS. Some people didn't do that, they just "cranked up the volume", which actually resulted in clipping, permanently damaging the files. The only way to fix them is to reconvert from the original source files.

Also, some games don't actually have a single normalized level for their entire OST, and instead use a wide dynamic range. Super Metroid is probably the most extreme example I've found, but a lot of the JRPG's do as well. You completely lose this dynamic range in the boosted tracks, which really kills a lot of the impact of that dynamic range (imagine the Arrival on Brinstar track being as loud as the Ridley fight... it's just wrong).

So, you could stick with HW#2, but it's ugly, and it's still wrong for several reasons. Thankfully, I've gotten a lot of people on board with understanding this and have been working to remove and replace boosted audio packs with properly normalized ones. It's been a bit of an uphill battle, it's not 100% complete, and in some instances I've just had to do the work myself, but the hardest part was convincing people that this was really the right way to do it, and on that front, at least, I've pretty much succeeded. This means no more need for separate patches, or hacky workarounds, the ONLY workaround that needs to be mentioned is the MSU-1 boost option in the SD2SNES menu for older hardware revisions, OR the op-amp installation mod, which essentially upgrades the hardware to Rev. H. Then, all you need is the correct patch (aka "hardware/FF" version), and the correctly-leveled audio tracks, and we can go back to (mostly) pretending that this whole fiasco never happened.

Sunday, May 29, 2016

I have this thing about coming up with funny (at least I think so), quirky, or... colorful names for software projects. I've come to the conclusion that perhaps I should not be allowed to do so. I don't really remember all of the names I've come up with, but here is the list of the ones that I do. Some of these products exist, others exist under other names, others still exist only in my mind... and should perhaps stay that way.

Personally, I think Chaos Monkey passed up a perfectly good opportunity to be called ClusterF*%#

Monday, June 8, 2015

A few months back, I learned of the USBDriveby device developed by Samy Kamkar that was able to infect MacOS computers by posing as a USB keyboard and mouse and executing a scripted sequence of mouse movements and key presses. His device used the Teensy 3.0 microcontroller dev board and requires a micro-USB cable to plug into. In my classic fashion of never having any good ideas of my own, but seeing other people's cool ideas and thinking "I can do that better" I started thinking of ways that I could improve on the hardware used, rather than utilizing a general purpose dev board like the Teensy.

I immediately knew that I wanted to use my favorite USB microcontroller, the PIC16F1455. It comes in packages with as few as 14 pins, or as small as a QFN-16, and requires no external components beyond a pair of simple bypass capacitors, making it perfect for small, simple USB devices. It's also supported by the free USB M-Stack, which means I'm not tied down by the frustrating license stipulations of the Microchip USB stack.

The real design revelation came when I tore apart a cheap $2 DealExtreme Bluetooth dongle to find that all of the electronics, including the actual USB pads, were all on a single PCB that could be easily removed from the shell.

The tricky part was that the PCB was 0.6mm thick, and finding a manufacturer willing to produce boards at that thickness for less than $100 took some doing. Once I realized SeeedStudio would handle such a board, it was a simple matter of measuring the original board and throwing together a replacement in EAGLE.

The firmware isn't quite done yet, but I do have the device enumerating as a keyboard and mouse and can send arbitrary mouse movements and button presses, as well as keyboard key presses, so all that really remains is setting up a queue-based event processor and then feeding it the original USBDriveby script. All in all, I'm pretty happy with how it turned out, and now I'm trying to come up with other ideas for how to use this thing, since I'm probably not going to get much use out of it as a MacOS exploit. The board has a single push button and LED (plus an additional power LED), so I can probably find another purpose for it eventually.

Tuesday, May 26, 2015

I use Google Maps API to render the maps on my Zelda Parallel Worlds walkthrough, and as a result I needed to generate the necessary tiles for the Maps API to use. My source image was a 4,096x4,096 image, and I needed to generate 256x256 tiles at various zoom levels, starting at fully zoomed out, where the entire map was contained in a single tile, up to however large I could reasonable render (which ended up being a whopping 16,384x16,384). GIMP's script-fu functionality was perfect for the task, but I couldn't find a script that quite did what I wanted, including scaling the map to the various zoom levels, so I made my own. I used the tiles-to-files plugin as my starting point and went from there. The end result gives the following options

Tile size is adjustable (though I've only tested powers of 2, such as 64, 128, and 256)

Max zoom level determines how many zoom levels should be generated. The lowest zoom level is 0, which is a single tile in size.

Output file type is selectable between PNG and JPEG

Interpolation mode can be chosen separately for shrinking and growing. In my case, I didn't want any interpolation when growing, since I was growing a pixel-perfect image by a factor of 2 each zoom level, so I wanted to retain the pixel-perfect aspect and just create "big pixels".

Tuesday, August 27, 2013

It's been awhile since I've written anything, mostly because I've been busy actually making stuff, but I figured I'd take some time out to do some writing instead. Something I've been working with lately is building SNES reproduction carts. I see a lot of people buying and using Willem-based programmers to burn their EEPROMs, and from what I can tell, they're way more trouble than they're worth, and more expensive too. I chose to go a different route and build my own programmer. EEPROM programming is a pretty straightforward microcontroller exercise. The main trouble is finding a microcontroller with enough I/O pins. Personally, I used a Teensy++ 2.0 development board. One of the most common chips used for SNES reproduction is the AM29F032B, used with a TSOP-to-DIP36 breakout board, usually the one made and sold by BuyICNow.com. So, for lack of anything better to do, I'm going to explain how to go about creating a programmer for the AM29F032B, though much of the information can be adapted to any EEPROM.

First of all, you'll need to build yourself an adapter in order to connect the microcontroller to the ROM. For the sake of cleaner code, logically contiguous pins on the ROM, such as A0-A22, D0-D7, should be connected to logically contiguous pins on the microcontroller (an 8-bit microcontroller will only have 8-bit ports, so a good compromise is to utilize full ports as much as possible, e.g. A0->PORTX0, A1->PORTX1 . . . A7->PORTX7, A8->PORTY0, A9->PORTY1, etc.). For my Teensy++ adapter, it looked like this:

(I'm trying to figure out how to create a custom part in Fritzing so I can post a nice image representation of this circuit, but for now you'll have to live with a pin table)

Ok, so now that we have everything wired up (or, in my case, I created a socketed PCB), we can start writing code. The most basic functions are reading and writing a single byte. The function prototypes will look something like this.

In order to understand how to implement these functions, we first need to look at the function waveforms in the datasheet. Here's the read function:

We can ignore the actual timings right now, all we really care about is the sequence. From the diagram, we can see that the sequence goes like this:

Set CE# high, OE# high, and WE# high (in any order, or simultaneously)
Set up the address
Set CE# low
Set OE# low
Wait for a short time
Read the data
Set CE# high and OE# high (in any order, or simultaneously)

...and so on. Writing is almost identical, though you wouldn't think it, looking at the waveform in the datasheet.

The reason that this looks so complicated is that Flash ROMs actually require you to write several command bytes for every byte of data you actually want to program. However, we want to first write the code to write a single byte, then it's easy to write multiple bytes in a row by making consecutive calls to that function. To make it easier, the sequence is:

Set CE# high, OE# high, and WE# high (in any order, or simultaneously)
Set up the address
Set CE# low
Set WE# low
Set up the data
Wait for a short time
Set CE# high and WE# high (in any order, or simultaneously)

The write operation actually occurs when CE# or WE# is pulled high, which latches the data lines and then performs the write.

No code this time, it should be trivial. Copy and paste the read function and make the necessary changes.

Next, we want to be able to program information to the chip. As mentioned before, this is done by writing several command bytes, followed by the actual data byte. This varies from chip to chip, but for the AM29F032B, the sequence is:

Addr Data
0x555 0xAA
0x2AA 0x55
0x555 0xA0
addr data

where the final "addr" and "data" are the actual address and data that you want to program on the chip. All you have to do is call your WriteByte 4 times in a row with those addresses and data values.

Now, the final function we need to write is to erase the chip. EEPROMs, including Flash ROMs, must be erased before they can be written to. This is because the program function can only change a 1 to a 0, it can't change a 0 to a 1. Because of that, in order to change a 0 to a 1, you have to change EVERYTHING to 1's by erasing the chip, then you can go back and program the 0's. It's just how it is. Anyway, erasing a Flash ROM is achieved by a command sequence. Again, this varies from chip to chip, but for the AM29F032B, the sequence is:

One last thing is that we need to know when the erase function has completed. There are several ways to do so, as described in the data sheet. The lazy way to do it is to continuously read any address (I usually pick 0x000) until the data returned is 0xFF. The reason for this is that during an erase procedure, the result of any read, instead of being the data at that address, is actually a status register. The status register will never equal 0xFF, but once the chip is erased, the whole chip will be all 1's, so any read should return 0xFF. Like I said, it's the lazy way to do it.

So now, we have 4 functions that pretty much handle everything that we need in order to burn code to our Flash ROM:

Now, you have to figure out how to actually transfer data between the PC and the microcontroller. I use RealTerm, because it has the ability to transmit binary files over a serial connection. I then set up my Teensy++ main loop with a simple serial interface that resembles a command-line application, with various commands and flags, then I use RealTerm's send function for programming, and its capture function for reading. Once I've programmed the ROM, I read it back to a file, and compare the file against the original ROM file to make sure that they match (be sure you've padded your ROM file or else trim the file you read back to match the original file size or you may get an incorrect mis-match). Because I'm using the Teensy++'s CDC virtual-serial-port-over-USB interface, it would be entirely possible to write a full PC-side host application tailor-made for this device, but there really isn't much point, seeing as all it would be doing is sending a file to a serial port, or capturing data from that serial port. Better to just use an existing application, if it fits our needs, and RealTerm does just that.

[Minor Edit]RealTerm apparently does a really terrible job of packet utilization for USB-CDC virtual serial devices, an issue which I've submitted to their bug tracker, though it hasn't generated any response, so it's unlikely to be fixed. For that reason, I've switched to Tera Term, as it speeds up write speeds by a factor of about 20-30, which makes the difference between taking 45 minutes to burn a chip with RealTerm vs about 90 seconds with Tera Term. This doesn't change the fact that I'm still using the same code on the microcontroller side.

Anyway, I'll probably throw up some more pictures at some point, but for the most part, I wanted to describe the process, rather than just handing out schematics and code. This is a relatively simple feat to accomplish, and from what I've seen of a lot of the SNES reproduction makers, I feel it should be something of a rite of passage. If you want to just go out and buy yourself a Willem, go ahead. But be warned that nobody really wants to help repro makers with their crappy Willems. Be a man, roll your own burner.

Here's mine:

An original SNES MaskROM, used for my initial read-only testing

The double-sided PCB design cut down on PCB size, and as a result, cost

Friday, June 21, 2013

Well, school really caught up with me, and although I've had a few pretty neat projects over the last several months, I haven't had the time to post any of them here. For one, I finally got around to trying reflow soldering, and created a second revision of my SNES Wii Classic Controller mod which turned out really nicely. I'm actually working on a third revision now, which may not actually be possible, but if I can manage to get it working, it'll be REALLY nice, so fingers crossed there.

Another project I put a lot of time into was the Altera EMP7064S development board I built for my CST231 class. A large part of this class was devoted to building a wire-wrap board around the Altera CPLD for the purposes of simultaneously building the board and learning to program it in Verilog. I chose to put my PCB manufacturing experience to good use and go ahead and build a PCB version of the wire-wrap board we built in class. Here's the board we built in class (the wiring wasn't *quite* complete in the second photo, but it gives a pretty good indication of how much wire wrapping was involved)

And here's the PCB that I made from the same schematic:

As you can see, I made good use of surface-mount parts for the LED current-limiting resistors, as well as the traffic light LEDs. I also added a DC power jack and a 7805 regulator so I can just hook up a power plug without the need for a bench power supply. I also made a nice little clock generator from a dual 555-timer IC that plugs into the 4-pin header directly above the main chip socket, so I don't need a function generator for most stuff either. I'm pretty happy with this board. My professor really liked it too, and he bought one of the extra boards from me.

In other news, I'm also still working on the Zelda: Parallel Worlds mapping/walkthrough site. I finally managed to build my first SNES reproduction cart, of ZPW, of course (I built one of Metroid: Super Zero Mission as well...), and have managed to play through the entire game on the actual console hardware, so yay :) The one major change coming to the website is that I hope to replace WorldKit with Google Maps API. I currently have a test page up and running and properly displaying the overworld map, but I'm having a few issues, most of which probably stem from my lack of understanding of the Projection class. I also have yet to try messing around with markers to see if they'll work for my purposes, but I suspect they'll do fine. So, be watching for that to roll out site-wide soon (I hope...).

I have a bunch of other small projects I've been working on that aren't really in any shape for a write-up yet, lots of fun with the Super Nintendo and other stuff, but I'll get around to them eventually...

Tuesday, January 8, 2013

Awhile back, Nintendo released an awesome Wii controller as a Club Nintendo Japan exclusive, the Wii Super Famicom Classic Controller.

This thing is beautiful. The only problem is, not only is it only available through Club Nintendo, it's a Japanese exclusive. It's been out long enough to have found its way onto Ebay and other resellers, but it typically goes for about $100. Not cool, Nintendo. Not cool. There are 3rd party versions of this controller, but like the cheap Ebay knockoff SNES controllers, they're crap. So what's a guy to do? Let's build one!

So, obviously we have to start with an official SNES controller (or, just because I want to, a Super Famicom controller). I found this project implementing a classic controller adapter in a cheap AVR microcontroller and figured I could improve the hardware design. The existing design was incredibly simple, and the AVR came in a surface-mount package, so I figured I could shrink the board sufficiently to fit it inside the controller itself. Actually, there's a ton of room inside the controller, so I could have even fit the DIP version inside if I'd wanted to. But I wanted to do better. So I did. The PCB did shrink down nicely, and here's the result:

With a minimum of external parts, the final
PCB shrunk down quite nicely

The board fits perfectly over the pin header from the original cable

The placement of the PCB avoids all of the spacer posts, meaning no
cutting or other modification to the controller shell is necessary

Voila!

You can find more info, including source and PCB design files, at the project page on my site.

About Me

I'm a nerd. And if you immediately take that as derogatory, first of all, what the heck are you doing on G+, and second, I give you this quote from John Green:

“…nerds like us are allowed to be unironically enthusiastic about stuff… Nerds are allowed to love stuff, like jump-up-and-down-in-the-chair-can’t-control-yourself love it. When people call people nerds, mostly what they’re saying is ‘you like stuff.’ Which is just not a good insult at all. Like, ‘you are too enthusiastic about the miracle of human consciousness’.”

Also, I'm rather ADD, as well as occasionally and selectively OCD. The two combine to create very interesting results at times.

Also, I like making cool stuff, and sharing that cool stuff with people who appreciate it makes it all worth-while. Finding out people actually *use* stuff that I've made and shared is just about the coolest thing ever, so if you like what you see, feel free to take it and make it your own.