Re: [hatari-devel] Blitter bug in STe mode

[Christian Zietz <czietz@xxxxxxx>]

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.

Regards
Christian
--
Christian Zietz  -  CHZ-Soft  -  czietz@xxxxxxx
WWW: https://www.chzsoft.de/
PGP/GnuPG-Key-ID: 0x52CB97F66DA025CA / 0x6DA025CA