Mixing tabs and spaces is a syntax error in Python 3, and you can get the same behavior in Python 2 with the "-tt" switch.
Not to mention you should never mix tabs and spaces for indentation in any programming language. A tab might be 8 spaces wide in one editor and 4 spaces wide in another; mixing tabs and spaces means the code is guaranteed to look wrong in someone's editor.
FWIW, I use a text editor where pressing Tab inserts spaces, so I virtually never have tabs in my code. Of course, I have to disable this feature when editing makefiles and remember to enable it when done editing them, but it's never been a big deal.
Because it wasn't made by Nintendo -- at least, it wasn't programmed by them. Ikegami did most if not all of the programming for the game. But Nintendo designed and distributed the game.
This became a sticky issue when Nintendo used this code as the basis for Donkey Kong Jr. without consulting Ikegami. Ikegami claimed copyright infringement and sued. They settled out of court, but it's possible that Ikegami still owns the rights to the code. This doesn't apply to the NES version or other ports, because they didn't use any of Ikegami's code.
Actually, very little of the game's sound output uses the discrete logic. It's used for Mario walking, Mario jumping, and the boom sound used at various points (when Mario gets hit, DK pounds his chest, etc.). That's it.
Everything else uses an i8035. The i8035 is a standard Intel microcontroller with no native sound capabilities; it only runs a program (in this case a 4K ROM). They hooked up one of its output pins to a DAC, and the music and other sound effects are generated through that DAC. It was in the middle of playing around with the i8035 code in the debugger, trying to reverse engineer the code, that I wound up making it play one of the unused tunes and discovered the game's hidden content.
Some of MAME's documentation was immensely useful in giving me a starting point for my disassembly, but that's all it did.
Sorry to nitpick, but MIDI has nothing to do with this. Game music (other than on computers like PCs and Macs) was rarely ever stored as MIDI until the 32-bit era.
Yeah, it's true. I found that out shortly after I submitted the story; my discovery of the existence of these assets was entirely independent. Somebody told me that he heard about unused music before and dug up the links, and indeed there are YouTube clips of a homebrew Intellivision port that uses the assets. I was a little depressed because I'd thought I found something special that nobody outside Nintendo or Ikegami had ever heard of before. But hey, at least l've brought the knowledge to the public.
HTML5 probably wasn't much of a thing when tcrf added the plugin, and I assume they just haven't gotten around to updating it yet. Plus they probably still want some compatibility with stone age browsers.
Mixing tabs and spaces is a syntax error in Python 3, and you can get the same behavior in Python 2 with the "-tt" switch. Not to mention you should never mix tabs and spaces for indentation in any programming language. A tab might be 8 spaces wide in one editor and 4 spaces wide in another; mixing tabs and spaces means the code is guaranteed to look wrong in someone's editor. FWIW, I use a text editor where pressing Tab inserts spaces, so I virtually never have tabs in my code. Of course, I have to disable this feature when editing makefiles and remember to enable it when done editing them, but it's never been a big deal.
Because it wasn't made by Nintendo -- at least, it wasn't programmed by them. Ikegami did most if not all of the programming for the game. But Nintendo designed and distributed the game. This became a sticky issue when Nintendo used this code as the basis for Donkey Kong Jr. without consulting Ikegami. Ikegami claimed copyright infringement and sued. They settled out of court, but it's possible that Ikegami still owns the rights to the code. This doesn't apply to the NES version or other ports, because they didn't use any of Ikegami's code.
Actually, very little of the game's sound output uses the discrete logic. It's used for Mario walking, Mario jumping, and the boom sound used at various points (when Mario gets hit, DK pounds his chest, etc.). That's it. Everything else uses an i8035. The i8035 is a standard Intel microcontroller with no native sound capabilities; it only runs a program (in this case a 4K ROM). They hooked up one of its output pins to a DAC, and the music and other sound effects are generated through that DAC. It was in the middle of playing around with the i8035 code in the debugger, trying to reverse engineer the code, that I wound up making it play one of the unused tunes and discovered the game's hidden content. Some of MAME's documentation was immensely useful in giving me a starting point for my disassembly, but that's all it did.
Sorry to nitpick, but MIDI has nothing to do with this. Game music (other than on computers like PCs and Macs) was rarely ever stored as MIDI until the 32-bit era.
Yeah, it's true. I found that out shortly after I submitted the story; my discovery of the existence of these assets was entirely independent. Somebody told me that he heard about unused music before and dug up the links, and indeed there are YouTube clips of a homebrew Intellivision port that uses the assets. I was a little depressed because I'd thought I found something special that nobody outside Nintendo or Ikegami had ever heard of before. But hey, at least l've brought the knowledge to the public.
Also, I don't see anything about a Java plugin. In my browser it seems to be using JavaScript, not Java.
HTML5 probably wasn't much of a thing when tcrf added the plugin, and I assume they just haven't gotten around to updating it yet. Plus they probably still want some compatibility with stone age browsers.