I made an NES emulator – What I learned about the original Nintendo
medium.com
medium.com
There's a community that looks for unused content that remains in games. The main wiki for this community is <http://tcrf.net/ >, which contains a fascinating amount of material. If you don't see your favorite old game on there, why not dissect it and try to find some unused stuff?
I did this for a favorite old game of mine called M.C. Kids. I reverse-engineered the game's level and graphics data formats and managed to create a level dumper for the game. Then, I did the same for a leaked prototype version of the game. I took the dumped images and made a page on TCRF comparing them:
http://tcrf.net/Proto:M.C._Kids
It took a few months on afternoons and weekends. It was very challenging, but I never felt overwhelmed by the details. There's really only so much you can do with three registers and little more than adding and branching instructions. If you're curious to see what a reverse-engineered level dumper looks like, the code is available at <https://gitlab.com/mcmapper/mcmapper/blob/master/main.c >.
Admittedly, I should get back to work - because I still don't know how to play the video file that I pulled out.
And yeah, I'm a big fan. Aside from just growing up with it, it's a really solid NES-era platformer. If you're curious to learn more about it, one of the developers actually maintains a blog and has written about it a few times. He also posts on HN infrequently.
http://games.greggman.com/game/m_c_kids/
http://games.greggman.com/game/programming_m_c__kids/
Also he & the other two primary developers actually signed my cartridge:
http://gamesplusone.com/mckidscart.jpg
I'm a dork.
This is why I say old computers never die - their owners do! Old systems have lots of technology to engage the hacker mind.
By the way, my favourite emulator is Oriculator, which emulates the Oric-1/Atmos/Telestrat/Pravetz 8-bit machines that never had much of a chance in the 80's .. just look at this beautiful code, for example, of how to emulate a 6502:
https://code.google.com/p/oriculator/source/browse/trunk/650...
With the revival of emulation of these systems, we're even getting new software written for them - in the modern era, titles are being released for these old machines that we would never have though possible in the 80's. Just look at this beautiful collection for the Oric-1 - all made in the 21st Century - for example:
http://space1999.defence-force.org/
http://stormlord.defence-force.org/
http://1337.defence-force.org/
http://skooldaze.defence-force.org/
http://oricium.defence-force.org/
Featuring Gameplay and Graphics that we would never have thought possible in the 80's!
http://www.oric.org/software/pulsoids-1515.html
Check out this collection from Twilighte, who before his untimely departure was a real master of this platform in the 21st century:
http://www.oric.org/index.php?page=software&fille=softwarese...
So much fun to be had on these old machines!
Is it because the field of CS has advanced further, which means that we can apply modern ideas and algorithms?
Or is it because we can cheat and have a toolchain running on vastly superior hardware, which enables us to use it in ways that would have been too time-consuming to develop back in the day?
today, we have plenty of programmers who have been at it for thirty years. They got started on these very machines, and in the meantime they have been doing other things on other computers—but which were still programming—and now, if they decide to go back to the original computers, their instincts more than compensate for the lost familiarity.
In some of my last years as a student (late nineties), I dug up my old ZX81 from my parents' basement, and the effects of all three items were visible: I had access to a cross-assembler that I ran on a SPARC workstation. Techniques that may or may not have been known in the 1980s were now published and available on the Internet for anyone curious about them. And my ability to concentrate and understand the issues I was facing was better than when I was eight.
It also helps that the toolchains are far superior to what we used to have .. I never would have thought, in my youth, that I'd be writing C code for the Oric-1, but indeed the OSDK has a C compiler that makes the effort of packing code into 48k a lot more fun than it used to be!
But in the end, you don't write software for these old machines unless you have a lot of passion, and that's what counts, I think. There is a lot of passion for the Oric-1 these days, that is for sure .. at least in the small scene that keeps the machines alive.
I'm not sure I agree about toolchains, though. The 6502 is not a very good target for C compilation, pretty much any assembly programmer can code circles around what cc65 produces. So, no offense to you or anyone else that writes C for 8-bit machines, but I don't think any of the new games and programs that really "push the limits" of these machines are written in C. So that leaves modern cross assemblers, which are indeed much more capable than common target/native assemblers of the olden days, but don't exactly afford a quantum leap of productivity either.
Then again, modern emulators are a godsend for debugging.
Hell yeah they are. I think thats also a key factor for why development on the old machines is experiencing a revival.
Yes, theoretically you could stick an ARM processor in a cartridge and run most of the game off that, using the PPU as a glorified framebuffer. But many (most?) retroprogrammers are in it largely for the engineering/optimization challenge (or else, why wouldn't you just write a retro-styled PC game), so they draw the line for "cheating" much more strictly than even you have. e.g. some fan translators refusing to expand the ROM size of a game and butchering the translation to fit (Japanese text is much more dense than English), instead of using a larger ROM to fit a better translation. Or some NES homebrew programmers not using mappers at all and working within the constraints of NROM (32kb program rom and 8kb graphics rom). So I wouldn't accuse any of these homebrew programmers of "cheating," because if they were actually guilty of it, those in "the scene" would have called their bluffs long ago.
But if a retroprogrammer were to use a mapper to achieve a 1 meg ROM, modern hardware would make that a decision with very little negative consequences. A programmer at the time might have to live with a game that cost well over $100.
So cheating in quotes because people did it in their actual cartridges. Cheating without quotes would be something like breaking out of the emulator sandbox and embedding the Quake engine.
The edit-compile-test cycle is near instant and debugging from an emulator is a lot easier than debugging on the real hardware.
I wrote this a few years ago - it's ~500 lines taking advantage of the logic behind the instruction set (instead of a jump table) and it can run Apple I BASIC at least.
That is similar to my approach to emulating the Gameboy Color's Z80-like CPU. Not yet completed - probably never will be :(
To make a dumper you first need to find the ROM pinouts for the chips they used. This tells you which pins select an address, which pins output data, etc. Then, build a dumper (for example writing an Arduino program) that selects each address one by one, and outputs the response from the chip in a format your computer can read.
Compare this to some of the early non bank switched games where the all sprites fit entirely in memory, with some creative tweaks (bushes are recolored clouds, etc).
It's a bit myopic of Nintendo that on-cartridge mappers had to be necessary, but on the other hand, it's early 80's consumer hardware; it was probably state of the art in the late 70's ... which makes it hilarious that Wario's Woods was released in 1994.
As for mappers, the 6502 (along with most other 8-bit CPUs from that era) has 16 address lines, imposing a hard-limit of 64 kilobytes of CPU-side address space. Without bank switching hardware somewhere, there was just no other practical way to access any more program ROM than that. Now, Nintendo could have pulled a PC-Engine/TurboGrafx-16 and embedded a bank switching unit somewhere in the console itself, but hindsight is 20/20.
https://www.kickstarter.com/projects/1101008925/lizard/updat...
(Of note, this is the same one who made MOON8 - a cover project for Pink Floyd's Dark Side of the Moon for the NES [0] - and more recently, getting the "2A03 Puritans" album, a NES chiptune collaboration album, onto a rom and cartridge [1].)
[0] http://rainwarrior.ca/music/moon8.html
[1] http://rainwarrior.ca/projects/nes/2a03puritans.html
---
I've personally only messed with the NES from an audio perspective, having spent a lot of time a few years back in FamiTracker [2] to write music for it. I always found it interesting that the Famicom had the ability for cartridges to include their own audio hardware in addition to the mapper, battery-RAM, etc. Like the mappers, the vast majority of these games that included expansion audio chips kept to a small-ish set of chips. Chiptune (especially Famicom chiptune, due to the time I spent tinkering with it) is a fascination of mine, so I could point out some samples for the various expansion audio chips if anyone would like.
A couple of other students and I did this same thing, but in Python, for the final project in our Python class. The result was excruciatingly slow. It still has some bugs, and we haven't touched it in almost a year, but we all learned a lot along the way. If you're interested in taking a look, or providing some feedback, the repo is here: https://github.com/billymeter/pynes