Table of Contents

VASYL interrupts and VASYL/CPU coordination

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:

Let's review them one by one.

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's reach - a canonical example here is VIC bank switching in CI2PRA register at $dd00, but it could also be just-in-time Color RAM or video matrix updates.

Computations difficult to do with VASYL

As in any well-balanced system, both the 6510 and VASYL have domains of operation where they excel, as well as those where they may be a poor match for the job. Although a lot can be done using display lists, it is only natural that a general CPU like 6510 will be more effective (or even the only) choice for many types of calculations. Their results can afterwards be uploaded to VASYL's local memory for use as look-up tables or display data.

Coordinating raster time between VASYL and CPU

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', effectively mitigating the risk of access collisions. However, as you became more proficient in VASYL programming, and the complexity of your display lists increases, so does their appetite for resources - and you quickly find yourself writing VASYL code that uses both ports.

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 demo_rastersplit.s, where display list is using both ports most of the time. The CPU has a narrow time window to upload updated rasterbar positions to the local memory - between raster lines 0 and 14. It thus patiently waits for the video beam to reach line number 0, and then quickly does the job.


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 demo_irq2.s, one can execute 6502 writes with a single-cycle precision.

Setting up VASYL interrupts

Getting VASYL interrupts working is as easy (or as difficult), as setting up VIC raster interrupt:

	LDA #<irq_handler
        STA $314
	LDA #>irq_handler
        STA $315
	LDA #$10
        STA $d01a
        WAITBAD     ; wait for the start of a rasterline preceding the next badline
        DELAYH  10  ; wait 10 more cycles
        IRQ         ; trigger an interrupt
        DELAYV  10  ; wait for 10 more rasterlines
        IRQ         ; trigger another interrupt, this time at the beginning of the line
	; We assume here that no VIC interrupts are enabled and
	; VASYL is the only possible video related IRQ source
	LDA #$10
        STA $d019

You can trigger multiple interrupts in a frame, or even in a single rasterline.

A complete example showing how to set up VASYL interrupts alongside VIC raster interrupts, how to differentiate between them, and how to use one to set up another can be found in our GitHub repository.