Eero Tamminen schrieb:
Ok, so issue always starts at middle of screen, and continues (either up
or down) until EmuTOS
finishes drawing the line with blitter.
Any idea why the garbage lines left behind would
be solid when the window outline is dotted?
It's too late for me for a really detailed write-up. So, here's what
goes wrong: Hatari sometimes restarts the Blitter in the middle of a TAS
instruction; something that does not happen on the real CPU, because no
other bus master is allowed until TAS completes.
I added some code to cpuemu_13.c to print when TAS is entered and the
values it reads and writes. I also added code to Blitter_Start() to make
note of the CTRL register at the beginning and and the end of a Blitter
round.
Normally I get output like this:
Blitter_Start: ctrl=80
Leaving Blitter_Start: ctrl=81
TAS: before read cycle
TAS: after read cycle = 81
TAS: after write cycle = 81
Blitter_Start: ctrl=81
So the Blitter modifies it's control register, TAS reads the control
register and restarts the Blitter. Everything's fine.
In the error case I see something like this:
TAS: before read cycle
Blitter_Start: ctrl=80
Leaving Blitter_Start: ctrl=81
TAS: after read cycle = 80
TAS: after write cycle = 80
Blitter_Start: ctrl=80
So the Blitter modifies it's control register, *during* a TAS
instruction, but, importantly, *after* TAS has read it. Therefore TAS
writes back an *old* value to the control register. This sets the index
into halftone RAM to the wrong value. Since EmuTOS uses the halftone RAM
to draw a dotted line, setting the index off by one causes pixels to be
drawn where they should not be and vice-versa.
I hope this is comprehensible. Otherwise I can expand on it tomorrow.