When Chris and I first started tossing around project ideas, I sputtered out: 'Hey! Wouldn't it be cool if we could emulate a Nintendo using some Atmel chips?' Chris replied 'Ooh, that'd be awesome, then I could play Ice Hockey and Final Fantasy 1 again!'
After looking over some documentation on the NES, we realized how impossible it was going to be to emulate not only its 6502 processing core, but also the separate Picture Processing Unit (PPU). The systems integration would have probably taken us a year to build ourselves, so we decided to scale down the project a little..
The result? 'We're going to build an Atari 2600 emulator! Yeah!!' This seemed more manageable, and we began work on it in zest, hoping to be able to relive our childhoods of playing Asteroids and Pitfall!. Once again though, we were about to realize that we bit off more than we could chew. Due to some insane synchronization constraints between the Atari's 6502 processing core and the proprietary Stella Television Interface Adapter (TIA) chip, we were pushing the limits of our poor little Atmel chips. The emulation process usually degrades one's processing capability considerably, and there just wasn't going to be enough cycles in the Stella emulator chip to render video and process input from the 6502.
Once again, we needed to adjust the bounds of our project, or else risk certain failure. Finally, we settled on the unifying element of all these systems: the MOS 6502 processor. This was the backbone of all the systems we examined, and so we figure it would be the right place to start. We've set a series of goals that increase in complexity, and plan to conquer as many of them as we can. In the short term, we want working emulation; father off on the horizon, we'd like to add in some video generation and input capabilities to be able to play Apple II games.
And so, we begin our quest to emulate one of the greatest processors ever to walk the earth.
As he stated above, when Jeff approached me with the concept of building a Nintendo out of the Atmel, I instantly thought back to the winter afternoons when I used to come home from middle school and spend hours glued to the gaming system. We quickly jumped at this opportunity, and began to research the technical specifications of the system. Yet, despite our over-ambitious nature, we soon realized that our original goals were simply unattainable due to the constraints of both time and processing power.
Looking back at this past month, this project was not only a test of our ability to program a microcontroller to emulate a different processing core, but also a test of both our patience (with the equipment, the code, and especially each other), as well as a test of our ability to balance our ambition with our sense of reality. Since hindsight is usually 20/20, I feel the need to briefly impart my advice to future 476 students. As an addendum to the Top Ten Things You Can Do to Survive ECE476's Final Project Month, I'd like to add this advice:
Know your limits. As much as we'd all love to have a final project whose bells and whistles rival Las Vegas slot machines, realize that a month is a very short time, and that dealing with the disappointment of having to scale back your project as you progress along is much better than coming to the same realization on the day of your demonstration.