urbanspr1nter wrote:Would it then make sense to say that after every number of X cycles my CPU has been running, I can switch off and handle APU/PPU/etc processing? Is this what you mean by "alternating"?
Yes, you basically have to make it look like all parts are running at the same time, and the most common way to do that is to run each part for a little bit and then move on to the next. Sounds simple, but the interactions between the different parts makes this significantly more complicated. For example, you can't simply run 1 frame worth of CPU instructions and then draw the entire screen at once, because the CPU might have done something that affects the display when it was running, and those changes must show up exactly where they would if the chips were running in parallel. One common technique is to emulate another part whenever something that affect that part happens. For example, if the CPU changes the scroll mid-frame, switch to emulating the PPU and draw the picture all the way until the point where the scroll changes, then go back to emulating the CPU. You also have to predict when other things will affect the CPU state (such as interrupts), so that so you can apply the changes at the correct times.
I'm no emulator author so I'm not 100% sure of the best ways to implement these things, but for interrupts, I imagine the CPU could have a queue of timestamps, populated by the other components (PPU, APU) indicating when interrupts are supposed to happen, and the CPU would then check the current timestamp against the timestamp of the next interrupt on every instruction in order to decide whther to trigger an interrupt, and remove that timestamp from the queue when it does. If the CPU does something that causes those predictions to change, they have to be updated/removed somehow.
A lot of these complications are eliminated when you emulate everything cycle by cycle, since any changes that happen in any component are immediately visible to the entire system, but there's a lot of overhead in switching between all emulated parts every cycle. This shouldn't be a problem for a modern desktop computer, but some devices will struggle with this model.
And to emit the sound by the APU, i would just need to let's say for example, at a 32KHz sample rate, just make sure I fire off 32,000 samples within 1 second?
Sound is not my area of expertise either, but I think that's basically it. Common audio-related problems I see a lot in the forums are related to resampling (consoles often generate sound at a much higher frequency than computers work with, so you have to scale the waves down somehow) and synchronization. Some people say it's better to make the audio steady and synchronize the video to it, others say to synchronize to the refresh rate and compress or expand the audio to fit... there are many possible ways to approach this problem, and hopefully you'll get more detailed responses than mine.
I actually have both APU and CPU memories separate as classes in Java. There is a main memory that will then do reads/writes to the appropriate object based on the mapped address. For example if the address is $2140, I would write to APU memory for the appropriate IO register. Hope this is what you meant also.
Yeah, sounds like that'll do.