Hardware Sega Genesis Video Game Music Player 2.0

I'd consider this to be the hardest part of the development cycle for this project. Driving the display itself really wasn't too bad. I simply used the U8G2 Library for that. The really tough part was parsing through the GD3 data within the VGM file. GD3 data is the meta data footer attached to the bottom of every VGM file. You can locate where the GD3 data begins by parsing out the GD3 offset starting at index 0x14 of the vgm file, then jumping down to that offset. Within the GD3 data, you'll find strings of oddly formatted 16-bit text delimited by sets of double 0's. Here you'll find lines such as the track title, which game the track is from, the console the game was on, composers, etc. The biggest challenge here was having to convert the 16-bit chars into 8-bit chars, since practically everything in my program and libraries rely solely on standard chars.

The way I did this was to first parse out the total size of the GD3 payload, create a temporary string to hold that data in, then use a for loop to iterate through that data. Within that for loop, I used two temporary chars to store the first half of the 16-bit char, and the second half. I'd only save the first half of data, unless both temporary characters happened to equal 0. Double 0's indicates a delimiter (end of a line of data), so I'd then insert the code for a new line within my temporary string.

  for(int i = 0; i<dataLength; i++) 
  {
    char c1 = vgm.read();
    char c2 = vgm.read();
    if(c1 == 0 && c2 == 0)
      rawGD3String += '\n';
    else
      rawGD3String += char(c1);
  }

Now that I have my nicely formatted string of standard 8-bit chars with clearly defined delimiters, I can parse out all of the data that I want and can tell when there is a new line by just checking for "\n"

The reason behind the 16-bit chars was to store Japanese characters. Since my player only shows select English song data, I'd just skip over the Japanese sections.

Now, we're still not done yet. Now that we've obtained all of our song data safely stored away in string variables, we need to output them to the display. Sounds easy, right? Just call the graphics library function with your position data and string and that's it? NO! That's too easy! Of course you're not allowed to write arbitrary strings to the display!

You need to first convert your string into a character array, then call the library function with your new character array and position data, then you need to send the pixel buffer over to the display. Duh!

I've actually found a pretty short an elegant solution to that whole string->c string problem though:

String trackTitle = "My Song Name";
u8g2.clearDisplay();
char *cstr = &trackTitle[0u];
u8g2.drawStr(0,10, cstr);
u8g2.sendBuffer();

This method actually seems to work very well and allows you to insert strings of arbitrary length. It's a little bulky, but hey, it works!

SD card support was another big feature that I desperately desired on my player. Having SD support basically means that I can store a virtually unlimited amount of songs on my player, which is totally awesome. I was originally going to use the standard "SD" library, but I found its features too limiting. Instead, I've opted to use the much more powerful SdFat library.  Now with added power, comes added complexity. I managed to get simple file-reading done in no time, but something was wrong. SdFat refused to read my lone VGM file, regardless of what I tried. Why? Well, it turns out that Windows likes to plop a hidden folder named "System Volume Information" onto any drive it can get its hands on. This is mostly for recycle bin support, but never the less, it was annoying as hell because I wasn't able to detect or remove it from my desktop computer. After a quick boot into a Linux environment and mounting the offending SD card, the magic mystery "System Volume Information" folder was there clear as day. Instead of having to remove that folder manually every time I re-wrote to the SD card on Windows, I decided to have my project terminate it automatically with extreme prejudice.

void RemoveSVI() //GTFO WINDOWS
{
  File nextFile;
  nextFile.openNext(SD.vwd(), O_READ);
  char name[MAX_FILE_NAME_SIZE];
  nextFile.getName(name, MAX_FILE_NAME_SIZE);
  String n = String(name);
  if(n == "System Volume Information")
  {
      if(!nextFile.rmRfStar())
        Serial.println("Failed to remove SVI file");
  }
  SD.vwd()->rewind();
  nextFile.close();
}

Now navigating through the file system was a whole other challenge. With SdFat, you can only iterate forwards to the next file. Never backwards, never randomly. In that case, I had to get creative. I would store the current file index as an integer, then, should I need to change the song in any direction or even pick a random song, I would just start from the very beginning of that list and iterate through every file until my index matched where it was supposed to be. Slow and a little clunky? Actually, not really. Even with hundreds of files, the correct track is resolved in under a second.

Here's an example of how I picked a random file from the SD card:

  randomSeed(micros());
  uint16_t randomFile = currentFileNumber;
  while(randomFile == currentFileNumber)
    randomFile = random(numberOfFiles-1);
  currentFileNumber = randomFile;
  SD.vwd()->rewind();
  nextFile.openNext(SD.vwd(), O_READ);
  {
    for(int i = 0; i<randomFile; i++)
    {
      nextFile.close();
      nextFile.openNext(SD.vwd(), O_READ);
    }
  }
  nextFile.getName(fileName, MAX_FILE_NAME_SIZE);
  nextFile.close();

As of writing this, my project supports moving forwards, backwards, picking a random song, "shuffle" mode, looping mode, and standard "album" mode where songs are played in order. You can also request songs via the serial console by their file names by using the r: command. For example, r:mySongFileName.vgm . Once this command is sent, the program will search the SD card for files matching "mySongFileName.vgm." Should it find the target file, the new file will be opened. Otherwise, the program will continue with the current song. Keep in mind that your spelling and capitalization must be perfect! Spaces in file names are also allowed, too. Just remember to use uncompressed .vgm files, not compressed .vgz files. You can uncompress a vgz file using a tool like 7zip and dragging out the internal file.

This version of the project was really fun. While there were quite a few new challenges to deal with, working with the Teensy line of boards has been a dream. It helps that the Teensy boards program near instantly - 2 seconds compared to the ESP's mind-melting ~30 seconds. This sped up prototyping significantly. Not only that, but I've decided to give the Atom text editor from Github a go and paired it with PlatformIO. Atom is... eh... I don't know. Meh to be honest. Pretty slow, clunky, and not very well designed. PlatformIO though is amazing. Everything under one roof and ready to go instantly. Love it.

I think the next step for this project will involve soldering it together since I'm more than happy with the results so far. I think it has been refined down to a point where the bugs and hardware problems are minimal and the performance is near optimal. With a bit more research, I could probably make my program much more efficient, but at this point, it runs every song I throw at it at full speed. It's so cool to have this little player jamming out hundreds of genuine Genesis tunes all day long automatically. It even serves as a platform to hear what unreleased game and homebrew soundtracks would sound like on genuine hardware. It's super cool, sounds great, and I'm very proud of it! :)

...And finally, the schematic, so you can build your own too!

PDF link