vasyl_interrupts_and_vasyl_cpu_coordination
Differences
This shows you the differences between two versions of the page.
Both sides previous revisionPrevious revisionNext revision | Previous revision | ||
vasyl_interrupts_and_vasyl_cpu_coordination [2020/10/07 00:09] – [Setting up VASYL interrupts] laubzega | vasyl_interrupts_and_vasyl_cpu_coordination [2021/04/15 12:04] (current) – [VASYL interrupts and VASYL/CPU coordination] laubzega | ||
---|---|---|---|
Line 3: | Line 3: | ||
While BeamRacer makes it easy to offload many graphics-related operations to VASYL, there are situations where some precisely-timed assistance from the main CPU may be needed. These can be chiefly grouped into three categories: | While BeamRacer makes it easy to offload many graphics-related operations to VASYL, there are situations where some precisely-timed assistance from the main CPU may be needed. These can be chiefly grouped into three categories: | ||
- | * Write to an address inaccessible to VASYL. | + | * Writing |
* Performing computations that 6510 is better suited to. | * Performing computations that 6510 is better suited to. | ||
* Making sure that CPU operations happen in a specific region of the video frame, to avoid clashes over resources shared with VASYL. | * Making sure that CPU operations happen in a specific region of the video frame, to avoid clashes over resources shared with VASYL. | ||
Line 11: | Line 11: | ||
=== Non-VIC writes === | === Non-VIC writes === | ||
- | **MOV** and **XFER** display list instructions do an excellent job of fast, precise writes to VIC-II registers. However, there are locations in C64 memory space that influence video output, and yet are beyond VASYL' | + | **MOV** and **XFER** display list instructions do an excellent job of fast, precise writes to VIC-II registers. However, there are locations in C64 memory space that influence video output, and yet are beyond VASYL' |
Line 23: | Line 23: | ||
Access to particular hardware resources needs to be properly managed to avoid the risk of visual glitches and odd errors. With both the CPU and the display lists being able to write VASYL registers, certain degree of planning is necessary to avoid situations where, e.g. concurrent use of PORT0 registers would lead to undesirable results. At an intermediate level of BeamRacer programming a good rule of thumb is to dedicate one port for CPU use, and the other for display lists', | Access to particular hardware resources needs to be properly managed to avoid the risk of visual glitches and odd errors. With both the CPU and the display lists being able to write VASYL registers, certain degree of planning is necessary to avoid situations where, e.g. concurrent use of PORT0 registers would lead to undesirable results. At an intermediate level of BeamRacer programming a good rule of thumb is to dedicate one port for CPU use, and the other for display lists', | ||
- | If you also need to keep moving the data from CPU side to local RAM, you will need to start coordinating port access, making sure each of them has only one user at a time. A straightforward way to do this is by reserving specific time periods during a frame for each of the port users. You can see this in action in [[https:// | + | If you also need to keep moving the data from CPU side to local RAM, you will need to start coordinating port access, making sure each of them has only one user at a time. A straightforward way to do this is by reserving specific time periods during a frame for each of the port users. You can see this in action in [[https:// |
\\ | \\ | ||
- | In all of the above scenarios, relying on interrupts makes it possible to avoid busy looping when waiting for the right time, but VASYL IRQs (compared to VIC's) have the added benefit of being triggerable on a specific cycle of a rasterline, thus providing more just-in-time operations. And using CPU/VASYL synchronization technique demonstrated in [[https:// | + | In all of the above scenarios, relying on interrupts makes it possible to avoid busy looping when waiting for the right time, but VASYL IRQs (compared to VIC's) have the added benefit of being triggerable on a specific cycle of a rasterline, thus providing more just-in-time operations. And using CPU/VASYL synchronization technique demonstrated in [[https:// |
Line 34: | Line 34: | ||
Getting VASYL interrupts working is as easy (or as difficult), as setting up VIC raster interrupt: | Getting VASYL interrupts working is as easy (or as difficult), as setting up VIC raster interrupt: | ||
- | * They are delivered as IRQs, so depending on whether you want to rely on ROM interrupt handler or do the whole thing yourself, IRQ interrupt vector at either '' | + | * They are delivered as IRQs, so depending on your ROM configuration and whether you want to rely on the original |
<code [enable_line_numbers=" | <code [enable_line_numbers=" | ||
Line 42: | Line 42: | ||
STA $315 | STA $315 | ||
</ | </ | ||
- | * The interrupt needs to be enabled by setting bit 4 in the register $d01a (the same register that stores bits controlling VIC's interrupts), | + | * The interrupt needs to be enabled by setting bit 4 in the '' |
<code [enable_line_numbers=" | <code [enable_line_numbers=" | ||
Line 57: | Line 57: | ||
IRQ ; trigger another interrupt, this time at the beginning of the line | IRQ ; trigger another interrupt, this time at the beginning of the line | ||
</ | </ | ||
- | * In your interrupt handler, you need to make sure that VASYL IRQ is acknowledged by setting bit 4 of register '' | + | * In your interrupt handler, you need to make sure that VASYL IRQ is acknowledged by setting bit 4 of '' |
<code [enable_line_numbers=" | <code [enable_line_numbers=" | ||
+ | ; We assume here that no VIC interrupts are enabled and | ||
+ | ; VASYL is the only possible video related IRQ source | ||
LDA #$10 | LDA #$10 | ||
STA $d019 | STA $d019 |
vasyl_interrupts_and_vasyl_cpu_coordination.1602054558.txt.gz · Last modified: 2020/10/07 00:09 by laubzega