|
EmuTimer question
#339945 - 05/12/15 09:36 AM
|
|
|
Hi all, I have a question about MAME timers that really gives me a headache 
From what I see a timer, "advances" when a CPU eats cycles (so it's CPU dependant).
Well, let's take a case with a single CPU (eg. M6809) and with only one IRQ source (for example a vblank IRQ fired by a timer)...
So, if the CPU is in "wait mode" (eg: CWAI instruction) and therefore it can be "unlocked" only by the vblank irq..., then 'who' increases the timer that should fire the vblank irq?
|
|
|
|
Re: EmuTimer question
[Re: dma.request]
#339980 - 05/13/15 06:14 AM
|
|
|
> Hi all, I have a question about MAME timers that really gives me a headache
> From what I see a timer, "advances" when a CPU eats cycles (so it's CPU dependant).
>
> Well, let's take a case with a single CPU (eg. M6809) and with only one IRQ source
> (for example a vblank IRQ fired by a timer)...
> So, if the CPU is in "wait mode" (eg: CWAI instruction) and therefore it can be
> "unlocked" only by the vblank irq..., then 'who' increases the timer that should fire
> the vblank irq?
I don't know the details of how MAME works (I've only read, not worked on, that code base) but when a CPU is in a suspended state like this, the clock is still ticking. The CPU will continue to "eat" cycles. It just won't be doing anything (the program counter won't advance, for instance). So if MAME has timers tied to CPU cycles, they will continue to function as expected.
Think of it this way: Work doesn't cause the CPU clock to tick. Causality runs the other way: clock cycles are what drive the CPU. When in a suspended state, on each clock cycle, the CPU evaluates whether a "wake-up" condition has been met (e.g., an external signal, an interrupt, or some on-chip timer expiring). In your case, it's an external interrupt. If this hasn't happened, it will remain in the same state.
Edited by Bart T. (05/13/15 06:15 AM)
|
Bart
|
|
|
Re: EmuTimer question
[Re: Bart T.]
#339989 - 05/13/15 10:05 AM
|
|
|
|
|
| R. Belmont |
|
Cuckoo for IGAvania
|
|
|
|
|
|
Reged: 09/21/03
|
|
Posts: 9716
|
|
Loc: ECV-197 The Orville
|
|
|
|
Send PM
|
|
|
Re: EmuTimer question
[Re: Bart T.]
#340008 - 05/13/15 08:33 PM
|
|
|
> Think of it this way: Work doesn't cause the CPU clock to tick. Causality runs the
> other way: clock cycles are what drive the CPU. When in a suspended state, on each
> clock cycle, the CPU evaluates whether a "wake-up" condition has been met (e.g., an
> external signal, an interrupt, or some on-chip timer expiring). In your case, it's an
> external interrupt. If this hasn't happened, it will remain in the same state.
Right. If the CPU is suspended, the only difference from normal is that no opcodes are emulated on each clock. (This of course greatly reduces the emulation load on the host's CPU). Time still happens for timers and screens and so on.
|
|
|
|
Index 
Threaded 
EmuTimer question
Reply
[Re: 