Hello
What relation do CPU cycles have with the speed of the CPU? For instance, is it that there are x cycles expected per MHz?
Thanks,
Richard Hughes
rhughes wrote:
Hello
What relation do CPU cycles have with the speed of the CPU? For instance, is it that there are x cycles expected per MHz?
Thanks,
Richard Hughes
In the basic sense there are 1,789,772-or-so cycles of the clock driving the 2A03 per second, so the "speed" of the CPU is 1.789MHz-ish. However, at the next level of abstraction there isn't much the CPU can do in a single cycle of that clock because every one of its instructions consists of two or more operations that require distinct clock cycles to perform [this isn't really true either but we're going with it for now]. So the "actual" speed of the CPU is 1.789MHz but the "effective" speed of the CPU is determined only by the efficiency of the code written to perform a particular task.
That makes sense.
So for the 6502, ADC Immediate is 2 cycles. So, technically, in order to get the CPU timing correct, this command should execute (1,789,772 / 2) times per second, yes?
Thanks
rhughes wrote:
That makes sense.
So for the 6502, ADC Immediate is 2 cycles. So, technically, in order to get the CPU timing correct, this command should execute (1,789,772 / 2) times per second, yes?
Thanks
That's correct. But it's much easier to consider instructions as groups of cycles. There are some instructions that take different amount of CPU cycles to complete depending on the state of various things. Branches, for example, take 2, 3, or 4 cycles to complete depending on the state of the flag being checked and the page-location of the branch destination.
Should note that for an emulator normally there is no need to make timings of an emulated CPU match to the real time. It should work as fast as possible, syncing with the real time once per frame (with a delay).
Shiru wrote:
It should work as fast as possible, syncing with the real time once per frame (with a delay).
How would you define a frame? If is it NMI, then I assume it would be CPU Speed / Frame Count (50/60 depending on PAL/NTSC) = Expected Cycles per Frame ?
There are 262 scanlines per frame, the first 240 visible and the rest in vertical blanking (vblank). NMI begins at the start of line 241.
There are 341 dots per scanline, the first 256 visible and the rest in horizontal blanking (hblank). The CPU runs one cycle every three dots.
A frame is exactly that. The PPU renders video frame-by-frame. A frame consists of 240 visible scanlines, and 26 vertical blanking scanlines. NMI happens after the first blank scanline.
There are 341 PPU dots in a scanline, and 262 scanlines. CPU speed is 1.789773. There are 3 PPU cycles for every 1 CPU cycle. From this, you can derive the frame rate: FPS = (cpu_speed * 3) / (341*262), giving you 60.09848 FPS.
On every other frame, if the display is enabled during the pre-render scanline, you lose one ppu dot, so that slightly changes the frame rate to 60.09882 FPS.