Changes

Jump to: navigation, search

CRTC

240 bytes added, 6 July
/* CRTC counter differences */
|}
No matter its type, the CRTC never buffers any of its counters, except for the video pointer MA. A buffer MA' is needed because MA has to be reloaded at each raster line start.
The only value that is saved in a buffer in the CRTC is the video pointer MA because it is reloaded at each raster line start.<br>
R12/R13 is loaded only once per frame, in MA and MA', at the first raster line start of the frame. The == CRTC counter MA is then reloaded with the value of MA' at each raster line start. And at each new character line start, MA' captures the current value of MA.differences ==
The exception is the CRTC 1 for which === MA is reloaded at each raster line start with R12/R13 instead of MA' as long as VCCbuffering ===0.
This is a major source At the end of incompatibility if the programmer does not take care display of this discrepancythe last raster line of each character line (ie. In demos when HCC=R1 and gamesVLC=R9), to make a display compatible with all CRTCsMA' captures the current value of MA. CRTC 2 is the exception, program where MA' capture R12/R13 when VCC!=0. This will then take effect instead of MA at the next last line of the frame start.
<br>
== = MA reload === On CRTCs 0/3/4, at the first raster line start of the frame, MA and MA' are loaded with R12/R13. On CRTC counter differences 2, at the first raster line start of the frame, MA is loaded with MA' as for all the raster line start of the frame. On CRTC 1, on every raster line start of the first character line of the frame (ie. when VCC=0), MA is reloaded with R12/R13 instead of MA'. This discrepancy a major source of incompatibility if the programmer does not take care. In demos and games, to be compatible with CRTC 1, program R12/R13 when VCC!=0. This will then take effect at the next frame start. <br>
=== VSC (C3h) overflow ===
7,977
edits