The attached program creates badlines after cycle 14 on every 4th rasterline, starting with rasterline $30. Vice 3.5 x64sc (GTK3 3.24.23, GLib 2.58.3), Darwin Kernel Version 21.1.0: Wed Oct 13 17:33:23 PDT 2021; root:xnu-8019.41.5~1/RELEASE_X86_64, seems to use the wrong colors for the graphics on rasterline $30 (top raster line).
Since the badline causes a line crunch, rasterline $30 shows the last line of the characters that are in memory locations $0400 ... $0427 (although the first ones are hidden by the FLI bug). But, in the emulator, these bytes are in the colors that are visible in the bottom row, which are NOT from the corresponding colorram memory locations $d800 and so on, but from memory locations $d8e8 and so on. On real C64s, the colors are mid grey (which is the color stored in $d800 ... $d827), which one would expect since the VIC c-accesses read 12 bits at a time. See also the discussion in this thread on CSDb:
https://csdb.dk/forums/?roomid=11&topicid=84186
So, to summarize, the emulator seems to have a mismatch between the screen ram and color ram memory addresses used for the graphics on the first rasterline on the screen in this example.
Screenshot for Vice (model C64C) added.
just for the records, the testcode is in the repo at testprogs/VICII/colorfetchbug/
Here is a Vice 3.5 x64sc screenschot for hires bitmap mode. I don't know if this matches real C64s. It probably does not. Groepaz noticed that x64 matches a real breadbin in text mode, but x64sc does not. In bitmap mode, i saw that x64 (Vice 3.1) again differs from x64sc.
Last edit: Rastah Bar 2021-11-24
Bitmap screenshot for Vice 3.1 x64
screenshots from VICE dont really help - screenshots from the real thing would :)
also, please attach the exact program (source) that you are using for testing (there is none for bitmap mode in the testrepo yet)
Test program for bitmap mode attached.
please attach the source - we'll have to modify the program for the testbench
OK, sorry. Source for bitmap mode attached.
added to the testrepo, thanks!
here is a patch.
"vscroll" is updated in cycle 15 (when first cycle is counted as zero), hence "badline" state is active in cycle 16.
"badline" state disables idle mode but display logic recognize it in cycle 17.
In actual code "dmli" and "vmli" are incremented in each visible cycle but for "vmli" this happens only in NON idle mode. (which is right)
Means "dmli" is ahead and accesses the last written color data instead new generated of this line.
To fix this "dmli" should be incremented under same conditions.
already working VIC tests of Testbench are not affected by this fix. Of course, that doesn't mean its flawless.
I would suggest that further testing be done to make sure no new problem has arisen.
Excellent find! I was also pondering it was a dmli vs vmli race but couldn't really find out where. Will test.
I've tested a slight variant of this quite a bit, but should be tested much more. Not sure if we can take the risk before this release?
Besides "idle_state" the fix depends on "vborder". I am not sure if incrementing "dmli" depends on both. There is no test which failes, but no test which prove dependance of "vborder" either.
I chose to reset dmli on vborder too, mostly because the source looked cleaner.
That vborder case handles the apparent disabling of update under the border. This is visible in: VICII/border/border-bm-idle|ysh|ysh2.prg
The exact point of reset isn't easy to determine because I believe the behaviour of vmli and dmli is actually as described in the last post by Michiel Boland here: https://sourceforge.net/p/vice-emu/bugs/218/
I'm considering a rewrite of that part if it can be done without too big a performance hit.
Last edit: Daniel Kahlin 2021-12-02
Fix committed in r41978. Please check for regressions!