(no subject)
Once I'm done with all this work, I want to code something.
I've always wanted to write an SNES emulator. I have some ideas for how to improve accuracy and performance. For instance, I'd like to try out the idea of a "lazy dot clock": one of the big stumbling blocks so far in SNES emulation has been emulating the PPU's process of continuously drawing the screen, pixel by pixel. It's too slow to do this actively (i.e. actually drawing a pixel at a time at the right speed), but the thing is that the SNES CPU is too slow for games to truly take advantage of pixel-by-pixel changes anyhow. It should theoretically be possible to calculate the position the dot clock should be at at the moment the SNES CPU performs an operation that is affected by it, and at that point draw the scanline up to that position. It would also be best to take advantage of multithreading for the audio stuff: the SNES audio chip is especially suited to this because the amount of interplay between the core system and the audio chip is minimal (4 1-byte registers mirrored on both sides, to be exact). I'd like to try writing the emulator in C#, with the tight CPU intensive stuff (like the core 65816 CPU emulation, probably) in assembler.
Or I could write an iPhone driver for Linux. This would involve reversing the USBMux stuff, then the Lockdown stuff, then implementing the AFC protocol. Again, I'd probably do this in C#/Mono. It'd be tricky, and Apple can change the protocol at any time, but it's a big gaping hole in Linux driver support at the moment.
Any thoughts? Other project ideas? Nothing too ambitious, mind you :)
I've always wanted to write an SNES emulator. I have some ideas for how to improve accuracy and performance. For instance, I'd like to try out the idea of a "lazy dot clock": one of the big stumbling blocks so far in SNES emulation has been emulating the PPU's process of continuously drawing the screen, pixel by pixel. It's too slow to do this actively (i.e. actually drawing a pixel at a time at the right speed), but the thing is that the SNES CPU is too slow for games to truly take advantage of pixel-by-pixel changes anyhow. It should theoretically be possible to calculate the position the dot clock should be at at the moment the SNES CPU performs an operation that is affected by it, and at that point draw the scanline up to that position. It would also be best to take advantage of multithreading for the audio stuff: the SNES audio chip is especially suited to this because the amount of interplay between the core system and the audio chip is minimal (4 1-byte registers mirrored on both sides, to be exact). I'd like to try writing the emulator in C#, with the tight CPU intensive stuff (like the core 65816 CPU emulation, probably) in assembler.
Or I could write an iPhone driver for Linux. This would involve reversing the USBMux stuff, then the Lockdown stuff, then implementing the AFC protocol. Again, I'd probably do this in C#/Mono. It'd be tricky, and Apple can change the protocol at any time, but it's a big gaping hole in Linux driver support at the moment.
Any thoughts? Other project ideas? Nothing too ambitious, mind you :)