Skip to content

Run loop

Dirk Hoffmann edited this page Jan 12, 2019 · 2 revisions

Proposed architecture of vAMIGA's run loop:

Run loop

Note

  • Under normal conditions, the CPU will be granted immediate access to memory, so executeUntilBusIsFree() is not called. In that case, the run loop first executes a CPU command. After that, it runs the DMA controller for the same amount of cycles. Special care needs to be taken if the CPU is blocked because the data bus is occupied by the custom chips. In that case, we have to run the DMA controller until the bus is free for the CPU. After that, we can peek the requested value from memory (which is now guaranteed to be up to date) and return it to the CPU.

  • The DMA controller will be implemented as a state machine with the HSYNC counter as the current state. In contrast to the CPU, which can only be run on a per instruction basis, the DMA controller can be run for an arbitrary amount of cycles. Hence, wherever the CPU is in time, the DMA controller can be run to the exact same position in time.

  • The event scheduler will be a simple FIFO list storing actions with a time stamp. Every time the DMA controller advances a cycle, it is checked if an event triggers. It is like a time-stamped version of Apple's notification center.

  • Note that different AMIGA components run with different speeds. On a PAL machine, the CPU runs with 7.09 MHz, the custom chips with 3.58 MHz, and the CIAs with 0.71 MHz. All clock signals are derived from a single 28 MHz master clock on the Amiga board.

  • Inside the emulator, a common clock unit must be used and it is reasonable to use the master clock for this purpose. Hence, a CPU clock cycle increments the clock counter by 1 * CPU_CLK_SCALE with CPU_CLK_SCALE = 4 and every DMA cycle increments the clock counter by 1 * DMA_CLK_SCALE with DMA_CLK_SCALE = 8. Setting CPU_CLK_SCALE to 1 allows to emulate a CPU running at 28 MHz. DMA_CLK_SCALE must not be modified, because it is tied to the PAL video signal.

Clone this wiki locally