Insane! Why solve such insane problems? I feel like the constraints are the kinds of things you come up with at a party with people you work with at 2am while drunk.
Because some people find it fun and it keeps the brain sharp. Conversely, I don't find hiking or playing cricket fun but millions do :-)
Truly awesome stuff.
I am a student in 1st year currently. And I am very much interested in Emulation as well as crazy stuff like this.
Can anyone please explain in a bit of detail what all knowledge is required to build such a thing.
Then a good set of debugging tools, which is possible for NES games as there are many different emulators written in all sorts of languages which would make for a good learning resource.
To get more involved, investate open-source emulation projects - building them yourself. Then get more involved - try to fix an open issue - which will help you get familiar with the project. Read up on reverse engineering and ask questions!
While I've not used it, this website seems pretty solid: http://www.codeslinger.co.uk/pages/projects/gameboy.html (You may want to make other choices; personally I'd go straight to the gameboy because it was a real console and skip the Chip8, but your mileage may vary.)
It's an excellent project. Great on a resume, too; if I saw a fresh grad show me their Gameboy emulator they wrote from scratch my head would be turning. I personally would expect you followed a site like that and know it's perhaps a deceptively simple project compared to what most would expect, but I'd still be quite impressed, and you have a pretty decent chance of hitting an interviewer who quite overestimates its difficulty too :)
The "easiest" part is emulating the basic Z80 CPU operations, but even that implies the individual (truly) understands how a CPU works: registers, op codes, timing, MSB/LSB, addressing, program counters/jump instructions etc.
Now, you have to add on how cartridges work: the various memory bank controller types, bank switching, save states, etc.
Then, you have code to display video, emulate audio, and controls.
Putting all that code together, in a nice OO organization, is top 5% coder level stuff. Anyone that did that would almost certainly get a 'hire' vote from me. It's probably 10-20X the complexity of most demo projects I've seen.
There must be some subset of games that don't have a mapper. It's good to know when you start that it's something you might want to do later, but you can get tetris going with out it.
I actually whacked a paragraph about how said emulator will not be the fastest emulator and it won't be a perfect emulator, but you'll certainly have some running games, and for that all the things I said will still be true. Making an emulator that exactly matches the console is hard, but making an emulator that more-or-less runs a game isn't that hard.
One question - what, if any, is the difference between the NES's PPU (Picture Processing Unit) and today's GPU?
Sorta—there was no direct video out from the cartridge on the SNES (though oddly enough, there were audio out pins), so the Super FX chip had to actually generate sprites on the fly for the PPU to composite together. This resulted in unfortunate color limitations.
You can see in the debug info for Star Fox 2 that the dynamically allocated sprite count was something that they had to constantly keep track of: https://r.mprd.se/fup/up/35454-Star_Fox_2_(Japan)_(Proto)_(A...
The DSP-1 was a preprogrammed microcontroller that preformed certain calculations that would have been inefficient to preform on the SNES CPU. The inputs were written to a memory mapped location, and the outputs read back. An interposed copier could simply redirect these reads and writes.
The SuperFX and SA1 used the cartridge's ROM and RAM for program and data, and therefore these enhancement chips are placed between the SNES bus and the cartridge memory. The cartridge memory is unavailable to the SNES bus while the enhancement chip is executing, as in the SuperFX, or the the enhancement chip enters wait states while the CPU is accessing the cartridge memory, as in the SA1.
Many game consoles gave their video chip its own internal memory, so the CPU would hit memory mapped I/O ports to set registers, like palette values or the position of sprites.* At each line (or character, or however it's timed), the video chip would read the current value of the palette & graphics bitmap data and stream it out the analog video generator pixel by pixel in sync. Multiple layers (SNES, etc) or sprites would all be read "live" per scanline, and the chip would decide, based on transparency & priority, which object's color would be visible for that final pixel output.
Graphic screens were usually a grid with a byte per "tile" or "character", often an 8x8 pixel chunk, which offers a form of dictionary compression. The tile ID byte + tile gfx dictionary (gfx were usually 1-4 bits per pixel, for 256 8x8 pixel tiles) + palette info constitued the screen graphics formats, with a similar setup for independently movable sprites.
Many effects could be achieved by having the CPU change registers mid-way down the screen. It can do color gradients by updating the palette every line, change tile or scroll definitions for different sections of the screen (like having a non-scrolling score/inventory section, then flipping to scrolling graphics for the other part of the screen). Many video chips signaled CPU interrupts at configurable scanlines, or allowed the CPU to set up display lists which had address/value/screen-location tuples that it would execute as it drew the screen.
Because all of this was real-time generated, most games were 60fps. If there was too much going on in some frame then graphics were simply lost or ended up in the next frame with wild visual glitches because the timed gfx changes happened at the wrong time & place. Nowadays, GPUs paint a framebuffer, and display that framebuffer when it's done being drawn, yielding variable frame rate. Some non-action games did that back in the 80s as well, and it was often slow enough to see each step of the image being drawn.
[* = most home computers held gfx and palette info in their "large" main memory, with the video chip having exposed configuration registers on the memory bus, instead of tunneling through I/O ports]
Being able to move the player's character around would also be useful for goal setting out of local maxima wrt AIs
This work is not really a product of higher education though. It's one of creativity, tenacity, good programming and more than that a deep knowledge of the NES architecture! Most people have the capability to do the last two regardless of education!
The more I read about 8 bit computing the more amazed I am. Needing a very detailed knowledge of the underlying system was a given then, unlike today. What's massively impressive is that some hit games back then were developed by teens in their bedrooms (so no grad school!). Miles away from the game industry we see today!