Projects
Retrolective (12-10-11)
I made a website that is a database of old video games (16-bit era and before) that allows users to upload
their entire retro video game collections to my site, add individual pictures, and compare collections with other
users on the site.
This was quite an undertaking for me. Not only programming-wise, but I had to start thinking about how one would
administer/moderate/control a site with the potential to have several hundered (if not thousands) of users. So
the name of the game was making it self-sustaining and self-maintaining as possible.
To facilitate this, I set up my own Ubuntu Linux Apache server. In it's previous life, it was a Dell desktop (that kind
with the crazy awkward front flap for USB drives). I think it's much happier now. I initially decided to set up
my own server when I couldn't get MySQL to work on the server that
KevinSelwyn.com is on. I eventually did get it working, but I was having WAY too much fun learning about
servers and Linux in general.
I was pretty well versed in the Windows terminal (cmd.exe) having started my computer life in DOS. So I knew all the
basic Windows commands, but Linux?! Man, oh man. I was in command heaven. I had fiddled around with dual-booting
Windows 7 and Ubuntu Linux (Natty Narwhal) on my laptop and I didn't like the interface very much so I spend a bunch
of time in the Terminal window. That certainly lessened the shock of setting up the command-line only Ubuntu
Server on the old Dell.
Anyway, the skills I really learned with this project was fully incorporating PHP and MySQL. Below are my MySQL
table structures for Retrolective:
| ID* | Title | Developer | Date |
|---|---|---|---|
| NES-ZL | Legend of Zelda, The | Nintendo | 1987 Jul |
| ... | ... | ... | ... |
| SNS-ZL | Legend of Zelda: A Link to the Past, The | Nintendo | 1992 Apr |
The ID is the primary key and they are or are based on the ACTUAL model/ID numbers on the actual cartridges. A lot of the games on the site have games that have this basic ID numbering scheme. And if they don't, I contrived them based on the same style. The first 3 letters of the ID indicate the system by joining the system table on SUBSTR(id,1,3) = prefix from the system table below:
| Prefix* | Name |
|---|---|
| NES | Nintendo Entertainment System |
| ... | ... |
| SNS | Nintendo SNES |
Then there is the table that actually holds everyone's collections on the site. It is small in terms of columns but has the potential to get HUGE because it holds everyone's games. I toyed with the idea of making a new table for every user, but things would get messy fast and would take up WAY too much information, so I went with this style:
| Username | ID |
|---|---|
| kevinselwyn | NES-ZL |
| kevinselwyn | SNS-ZL |
The ID column is a Foreign Key with the ID from the Games Table and are joined there as well. So just one well placed query would yield the following result:
| Username | Name | ID | Title | Developer | Date |
|---|---|---|---|---|---|
| kevinselwyn | Nintendo Entertainment System | NES-ZL | Legend of Zelda, The | Nintendo | 1987 Jul |
| kevinselwyn | Nintendo SNES | SNS-ZL | Legend of Zelda: A Link to the Past, The | Nintendo | 1992 Apr |
I won't go into the Users Table because that's got secrets and stuff! But that's the gist of my MySQL in this site. So check it out and let me know what you think!
QRpedia (09-30-11)
I came across a new site that they set up for Wikipedia, attempting to pump some life back into the dwindling QR usage statistics.
The result of which was QRpedia.org.
Simply copy and paste a Wikipedia URL and it'll spit out a QR code because...umm, I'm not sure why. I mean, you're sitting at your computer,
copying and pasting a URL. So why would you even need the QR code? No idea.
Regardless, it was a fun little coding experiment. Minimal code, but some nice behind the scenes AJAX requests to check if the
Wikipedia page even exists. And some simple Javascript to find out the language of the site. It's right there in the subdomain (i.e. "en.wikipedia" = English).
And that's all there is to it. Google does the heavy lifting with generating the QR code.
Interesting side note: At the time of writing, I am just now realizing that I could have just jacked the Javascript code directly from QRpedia.org.
It's there for everybody to see (or at least those with working knowledge of browsers with developer tools).
It seems that the folks over at QRpedia.org went about the AJAX requests and QR code generation the same exact way!
It was fun not knowing how they did it and seeing how most programmers take the same path of least resistance in their programming choices.
Check out this project here: QRpedia (my version)
Check out the rest of the portfolio here: Portfolio
ReadNES (09-27-11)
Like I said in my previous post, one of the most basic, practical ways of playing NES ROMs on the actual hardware is to write the raw data to the chips yourself.
This is a simple alternative, priced at $135 and with the ease of being able to load ROMs via a CompactFlash card.
But we're looking for a more legit solution to our problem. The first half of that problem is the writing of the microchips.
The second half, that we can solve right now, is splitting the ROM into the parts needed for the writing process, the PRG and the CHR.
The PRG holds the executable program data for the ROM.
The CHR holds the visual data such as sprites and backgrounds.
When Kevin Horton created the iNES Format, he lumped the PRG and CHR together and added some header info at the beginning of the file that contained information on the mapper used, the title, and other important stuff.
So to 'reverse engineer' this process, it is necessary to remove the header information and split the ROM into its respective PRG and CHR components.
Fortunately, a man named Raphael Assenat wrote a program to do just that.
Written in C and operated via the command line, I noticed that the simple program lacked a GUI.
And, while not too terribly complicated, it is necessary to recompile the source code for whatever operating system you're running (Windows, Mac, Linux).
To simplify this, I rewrote the code in PHP, a very C-like web language for server-side programming.
This allows one to access the program from anywhere on the internet on any operating system that has a web browser.
Also, making a nice, dynamic GUI is easily accomplished using HTML, CSS, with the added functionality of jQuery.
It is exceedingly easy to upload a ROM, select any PRG/CHR doubling (if your chip is too big, it is safe to double up the data to prevent read errors),
and submit to ROM to be split. The program spits out a simple ZIP archive containing the PRG and CHR files.
I must stress that I do not provide ROMs on this site, I just facilitate the splitting of the files. Ninentendo has all rights reserved, blah, blah, blah.
Check out the site now: ReadNES
Chip Music (09-26-11)
I've been slowly making my foray into chip music for a while now.
The style I love is a the Anamanaguchi
flavor but leaning more towards the I Fight Dragons style.
I like the technical aspect of Anamanaguchi but, simply put, they play along with a hacked NES, senza voce.
IFD, on the other hand, incorporate the chip music but also have great lyrics and use of traditional instruments.
So, I'm aiming to make music in the IFD style with some hardcore nerdy, tech-ness from the Anamanaguchi side.
This recording/video I did during my Weekly Musical Diddys (it's actually an IFD song) was recorded direct from the line-out of a neon green Game Boy Color:
I Will Wait For You If You Do For Me.
But recording with the Game Boy is easy because I have one of these bad boys:
This is a USB programmable Game Boy cartridge. You can load it with Game Boy ROMs and play them on the actual hardware.
The problem is that the use of ROMs and emulators is...well, illegal.
Nintendo makes it very clear that this is not cool.
Apparently, there is the tiniest of margins that you may possess the ROM of a game of which you own a physical copy.
But this is fine because the ROM that I use to make music on the Game Boy is called Little Sound DJ (LSDJ),
a custom program written by Johan Kotlinski, an awesome Swede.
LSDJ is a 4-channel tracker that allows one to program tracks consisting of the 4 Game Boy channels (2 square wave channels, 1 PCM 4-bit wave sample, and 1 noise channel).
And you can do amazing things with just these 4 channels. I've heard even better things with less channels (Atari 2600 has only 2).
But I think it's these technical limitations that foster such creativity in chip music artists. Think of them as intentional MacGyvers of music. Purposefully giving themselves limited tools to make something awesome.
In my opinion, the holy grail of chip music platforms is the Nintendo Entertainment System. 2 pulse wave (square) channels, 1 triangle wave channel, 1 DPCM 6-bit wave sample, and 1 noise channel.
So it's got 1 triangle channel up on the Game Boy, but the sound is just incredible.
And while chip music artists are doing great things with this system today, let's not forget about the INCREDIBLE music written for the games on the system back in its heyday. Like this choice track from DuckTales:
Similar to Game Boy chip music, there is custom software for the NES as well. Another tracker.
But where LSDJ was a tracker in ROM form, for the NES there are trackers for computers that can generate the ROMs.
The one of which I am particularly fond is Famitracker (a play on Famicom, the Japanese/European name for the NES. A portmanteau itself of "family" and "computer").
Famitracker allows for MIDI input which makes it choice for studio musicians.
The real neat thing about Famitracker, besides the amazing control you can get out of the 5 modest channels, is the choices of output. The choices are:
• NSF - Nintendo Sound File
A custom audio file that can be played in specialized players like Foobar2000
or with plugins like in WinAmp.
• NES - iNES ROM Image
This option spits out a complete, emulator-playable ROM. The iNES refers to the NES-hacker standard for ripped NES ROMs.
It basically contains the information contained in the ROM. The title, which mapper is used, etc.
• BIN - Raw Music
You can use this option for hardcore customization.
It gives you just the important parts of the NSF that you can rearrange with the use of other software later.
• PRG - Clean 32kb ROM Image
This is one of the most practical options for making the chip music work on the actual hardware.
It gives you a ROM image that can be written to a physical chip, inserted into a cartridge, and played on the system.
So hopefully over the coming weeks, I'll begin to populate this page with other project updates and tutorials for making practical chip music on actual hardware.