On Mon, 22 May 1995 22:52:50 +0200 (MET DST), Frode Tenneboe said: > > > > On May 22, 3:58pm in "Re: The Annoyed Hog's Problematic Program...", you > > warbled: > > ] With rouding this adds up to 13. Or will the 3+5 be 'evened out' as > > ] it adds up to 8?
I _know_ I've seen the above-quoted mail before, but for some reason it is now no longer to be found anywhere in my mailbox. That perhaps explains why I didn't answer it the first time (makes me wonder whether there are some other mails out there that have been zapped...). > >> A JR does this. > >> > >> fetch+decode 4 cycles > >> fetch 3 cycles > >> if true then jump 5 cycles > >> --------- > >> 12 cycles > Two bus accesses at 4 each + 5 = 13? A bus access takes 3 cycles, but only starts at a multiple of 4. So if the condition is false, we get fetch+decode 4 cycles fetch 3 cycles taking 7. However, the next instruction must obviously begin with a fetch, so there is 1 wait state before the next instruction. If we were watching from outside, we would think that the wait state occurred at the end of the JR rather than at the beginning of the next instruction. Thus a JR takes 8 cycles when the condition is false. If the condition is true, then the above applies to make 12 cycles. This time, the thing just after the second fetch is not a memory access, so it starts immediately after the third cycle of the fetch. The instruction INC HL contains only the one fetch to read the instruction, but it takes 6 cycles in total. The next instruction cannot be fetched for another 2 cycles, so we say that INC HL takes 8 cycles. Now this instruction has an interesting property, which I used in my improved version of the VMPR scrolly in my brother's demo. If the CPU is running while the screen is being displayed then bus accesses are only allowed every 8 cycles (but they still finish in 3 cycles). But the next multiple of 8 after an INC HL instruction is just 8. Hence the instruction INC HL takes the same amount of time whether the screen is being displayed or not. Clear? imc
