User Tools

Site Tools


caveats

Differences

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

Link to this comparison view

Both sides previous revisionPrevious revision
Next revision
Previous revision
caveats [2020/10/04 00:30] laubzegacaveats [2020/10/04 21:38] (current) laubzega
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? 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: 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. 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 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 instead, 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.
caveats.1601796600.txt.gz · Last modified: 2020/10/04 00:30 by laubzega