6502.org

hi everyone! i'm trying to write a nintendo nes emulator. i'd written almost the 50% of the cpu core, but i have some doubts with the video emulation.

where should i start writing the ppu emulator? any advice will be greatly apreciated!

There are already NES emulators, some probably open source. Also, the rise on the NOAC chips (Nintendo On A Chip) are populart because the PPU patent has expired.

One place to look, the Playpower $10 computer which uses one. They have an open source emulator so you will wan to take a look there. playpower.org

thanks for your answer!

i'd already taked a look to the Open Source emulators, but since the source code it's not commented it's hard to understand.
i'm just asking for a few advices to write my own PPU emulator.

Not only that, but the TMS9918A from which the PPU was copi..err...inspired from is, technically, quite an awesome little video architecture despite its resolution limitations. Unlike the Commodore VIC architecture, the VDU found itself, in one way or another, in the TI-99/4, TI-99/4A, ColecoVision (console and ADAM), all the MSX architectures, the Nintendo and SuperNintendo consoles, and the TRS-80 Color Computer series.

I've half-way considered making a VDU-clone myself in programmable logic some day, more suited to the VGA display resolutions and frame rate, but otherwise similar in programming interface and architecture.

Some day....

Unfortunately, there's really no advice that can be given, beyond simply stating the obvious: read other people's code, even if it's not commented. Just take your time with it, and try to understand it as best you can.

That being said, you can at least get a first-order approximation of how the PPU works by breaking your emulator's time into different chunks. For example, on NTSC displays, each horizontal scanline takes 63 microseconds or so to complete. So,

1) you can write your emulator to emulate 63 microseconds worth of instructions (IIRC, the NES runs its 6502 at 1.79MHz -- same as Atari 800 I think), so that is something close to 96 CPU clock cycles worth of emulation. Then,

2) you render a complete scanline into your emulator's frame buffer. Then,

3) Wait for a some amount of time to ensure that 63 microseconds actually passes in the real-world. Since modern computers can compute a scanline and emulate 63us of 6502 instructions much faster than the original systems could, you need this to make sure game play is manageable.

4) Goto step 1.

NOTE: this kind of emulation loop will NOT handle cycle-perfect emulation. But, it is a good first-step, and as long as you're games don't do timing tricks shorter than 63.5us long, it should work out OK. I think. The experience from writing this will also give you the knowledge and background needed to decipher what the open-source emulators are doing too, so when you need cycle-accurate emulation, re-using ideas becomes much easier.

ok, thank you all for your answers! specially kc5tja, i'll try to make just like you said above.

this is a project i've been working on since i'm 18 (now i'm 20) and i always got stucked in some point (because i've internet access in my house since 2 years ago and because the complexness of this project stress me out )... so let's ride again into this project that's making me mad

thanks!