2020-10-02, 11:13 AM
(2020-10-01, 05:45 PM)laubzega Wrote:Thank you very much. I don't know why but at the beginning of this new emulation I decided to "force" the badline commands from VASYL with a stupid flag...Quote:Anyway, now I have I doubt about BADLINE.
Below what I understood so far (wihout AEC handling):
Now, if the execution continues with the next instruction, does it mean that VASYL remembers that it has to force a badline or a non-badline according to raster line target (as I do in the emulator) ?
- it doesn't wait for condition, after the beam check the VASYL will execute the next instruction
- if the target raster is reached that raster line becomes a badline
- Otherwise, all the other rasters between become non-badline. So, for example: VIC is on raster 100, VASYL executes BADLINE 2 => raster 100 and 101 become non-badline while raster 102 becomes a badline.
Where, in this process, AEC signal is checked ?
BADLINE is actually very simple to implement:
BADLINE ARG
is equivalent to
R = PEEK($D012) ; RASTER
C = PEEK($D011) ; CR1
MOV $D011, (C & $f8) | ((R & $07) + ARG) & $07)
(I hope this mix of BASIC, C and Vasylese is not too eye-searing ).
That is, it changes VIC-II YSCROLL to a value that will cause the badline to occur after ARG rasterlines. This also means that all earlier lines (if there are any), will be non-badlines.
There is no extra waiting or anything else happening, beyond what is needed to execute a successful MOV.
Of course, modifying yscroll (BeamRacer does exactly this) is the simplest and natural way.
Ok, the AEC signal is of course checked while writing to $D011.
Now, fld & fli demo seems to work properly.
Thanks to laubzega & silverdr for your support.