@HoodedMan - I second emulating the Chip8 (although Chip8 technically isn't a console but you get what I mean). Even if you've never finished an emulator, it's something you can do a lot with as a weekend project. This link seems pretty in-depth -> http://www.multigesture.net/articles/how-to-write-an-emulator-chip-8-interpreter/
Getting started is easy. Just, erm, start. Really, even if you don't have a final idea of how the emulator will function, start throwing together code that you know how to make (reading a file into memory, setting up functions you know will be used often) and start emulating the parts you best understand. After that, write test code (in your case Chip8 test code), compare it to a "completed"/working emulator or real hardware, verify the results, fix stuff, then move on to the next thing that's missing from your emulator.
The short answer of where I started: the GameBoy.
The long answer of where I started: I discovered Dolphin late in my college career, gave emulators on Linux a try (was previously unsuccessful/disappointed). I was (like you) impressed with the devs and wanted to be like them. I first fiddled around with several abandoned emulators (an SDL port of OSwan and RealityBoy) but all I ever did was make GUIs or add trivial features like screenshots. I decided I was tired messing around, and I got serious about learning how to program an emulator. I went straight for the GameBoy (at this time, I also worked sporadically on Gekko, a would-be GC emulator) and spent a while doing that off and on. I also messed around with Desmume, trying to get it to render 3D objects at higher resolutions like Dolphin. This was way before Desmume X432R, but it was quite a journey. That kind of also gave me a purpose too; I'm actually still serious about writing my own DS emulator with user-defined internal resolutions from Day 1.
EDIT: A year later, I have to correct myself... I'm sorry, but I've learned better now.
ಠ_ಠ
No. VBA-M's code is absolutely unreadable. That isn't an opinion. I've dug through it, and only a compiler could love that coding style (or lack thereof). I don't mean to offend the work of previous emulator authors, but every time I try to parse what's going on in there, I only rarely understand wtf it's doing. The distinct lack of comments helps not one bit.
Getting started is easy. Just, erm, start. Really, even if you don't have a final idea of how the emulator will function, start throwing together code that you know how to make (reading a file into memory, setting up functions you know will be used often) and start emulating the parts you best understand. After that, write test code (in your case Chip8 test code), compare it to a "completed"/working emulator or real hardware, verify the results, fix stuff, then move on to the next thing that's missing from your emulator.
The short answer of where I started: the GameBoy.
The long answer of where I started: I discovered Dolphin late in my college career, gave emulators on Linux a try (was previously unsuccessful/disappointed). I was (like you) impressed with the devs and wanted to be like them. I first fiddled around with several abandoned emulators (an SDL port of OSwan and RealityBoy) but all I ever did was make GUIs or add trivial features like screenshots. I decided I was tired messing around, and I got serious about learning how to program an emulator. I went straight for the GameBoy (at this time, I also worked sporadically on Gekko, a would-be GC emulator) and spent a while doing that off and on. I also messed around with Desmume, trying to get it to render 3D objects at higher resolutions like Dolphin. This was way before Desmume X432R, but it was quite a journey. That kind of also gave me a purpose too; I'm actually still serious about writing my own DS emulator with user-defined internal resolutions from Day 1.
EDIT: A year later, I have to correct myself... I'm sorry, but I've learned better now.
Shonumi Wrote:but look at VBAM, ZBoy, or this GB emu if you want readable source code.
ಠ_ಠ
No. VBA-M's code is absolutely unreadable. That isn't an opinion. I've dug through it, and only a compiler could love that coding style (or lack thereof). I don't mean to offend the work of previous emulator authors, but every time I try to parse what's going on in there, I only rarely understand wtf it's doing. The distinct lack of comments helps not one bit.