Differences

This shows you the differences between two versions of the page.

--- caveats [2020/10/04 00:25] – created laubzega
+++ caveats [2020/10/04 21:38] (current) – laubzega
@@ Line 5: / Line 5: @@
 === Badlines ===
-If you ever did any VIC-II programming, you are probably very aware of the concept of so-called badlines. Briefly, badlines are the display lines during which VIC-II is doing additional memory fetches from color RAM and video matrix((For a great introduction to the concept of badlines we recommend https://nurpax.github.io/posts/2018-06-19-bintris-on-c64-part-5.html)). The side-effect is that during 40 cycles of such line the main CPU is fully blocked from accessing the buses, and thus sits there doing nothing. What's worse, VIC is so preoccupied with the extra work that it has no time left to listen to writes to its own registers, in effect becoming totally deaf to whatever is going around it.
+If you ever did any VIC-II programming, you are probably very familiar with the concept of so-called badlines. Briefly, badlines are the display lines during which VIC-II is doing additional memory fetches from color RAM and video matrix((For a great introduction to the concept of badlines we recommend https://nurpax.github.io/posts/2018-06-19-bintris-on-c64-part-5.html)). The side-effect is that during 40 cycles of such line the main CPU is fully blocked from accessing the buses, and thus sits there doing nothing. What's worse, VIC is so preoccupied with the extra work that it has no time left to listen to writes to its own registers, in effect becoming totally deaf to whatever is going around it.
 Thus, although VASYL runs concurrently and is not bound by limitations of the system bus, it cannot affect VIC-II in any way during these busy cycles. If you issue a write to a VIC register while it is not paying attention, VASYL will stop and wait until VIC finishes doing extra fetches and becomes interested in the outside world again.
@@ Line 55: / Line 55: @@
 As is well known, the 6510 can perform up to three write accesses in sequence, and consequently needs as much time to be stopped. That's why VIC-II asserts BA line three cycles ahead of pulling down AEC - giving the CPU enough time to stop no matter what it is doing at the moment. How can then BeamRacer function with just a single-access buffer?
-First, the only situation where three write accesses in a row happen is at the start of interrupt service sequence((Execution of instruction **BRK** is a near-equivalent of this.)), when CPU writes program counter and status register to the stack. This is of no concern to BeamRacer, because the stack is always in the fixed location (''$100-$1ff''), certainly outside VIC-II address space, and so the writes to it never need to be postponed.
+First, the only situation where three write accesses in a row happen is at the start of interrupt service sequence((Execution of instruction **BRK** is a near-equivalent of this.)), when CPU pushes program counter (two bytes) and status register (one byte) to the stack. This is of no concern to BeamRacer, because the stack is always in the fixed location (''$100-$1ff''), certainly outside VIC-II address space, and so the writes to it never need to be postponed.
 Two writes in a row happen:
@@ Line 64: / Line 64: @@
 The **JSR** is not an issue, for the same reason three-writes-in-a-row situation was not - BeamRacer does not need to stop the CPU during stack writes.
-That leaves the final scenario - execution of one of **ASL**, **LSR**, **DEC**, **INC**, **ROL** or **ROR** instructions. Each of these instruction makes - in addition to read accesses - two successive write accesses. The first stores the original value which was lead from the target location, the second - a modified one. For instance, if there is a value ''$01'' at memory location ''$8000'', instruction ''DEC $8000'' will write values ''$01'' and then ''$00'' to address ''$8000''.
+That leaves the final scenario - execution of one of **ASL**, **LSR**, **DEC**, **INC**, **ROL** or **ROR** instructions. Each of these instruction makes - in addition to read accesses - two successive write accesses. The first stores the original value which was read from the target location, the second - a modified one. For instance, if there is a value ''$01'' at memory location ''$8000'', instruction ''DEC $8000'' will write values ''$01'' and then ''$00'' to address ''$8000''.
 This is sometimes exploited to acknowledge VIC-II raster interrupt - the appropriate bit is the least significant one in register ''$d019'', so if it is set, executing, e.g. ''DEC $d019'' will with its first write achieve the equivalent of ''LDA #1; STA $d019'' (and the second write stores a value of zero, which is irrelevant in this case).
-This "trick" is not supported by BeamRacer, because only the second write gets stored and subsequently replayed if CPU and VASYL writes happen simultaneously. In any case, it is recommended that VASYL interrupts are used, as they have the advantage of being triggerable at any rasterline cycle, not just at its beginning.
+This "trick" is not supported by BeamRacer, because only the second write gets stored and subsequently replayed if CPU and VASYL writes happen simultaneously. In any case, it is recommended that VASYL interrupts are used instead, as they have the advantage of being triggerable at any rasterline cycle, not just at its beginning.