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

[Nicolas Pomarède <npomarede@xxxxxxxxxxxx>]

Le 09/06/2020 à 11:18, Toni Wilen a écrit :
> > shouldn't be the case when using TAS as the bus is still owned by the 
> > cpu.
> > For now, there's no cpu/bus specific code when TAS is used, guess I 
> > will have to add code for this as this is one the case where the cpu 
> > and blitter will both try to access the bus at the same time.
>
> Actual locked cycle is not implemented in UAE core because on Amiga TAS 
> special rmw cycle is completely ignored when accessing chip ram and 
> write part of cycle can conflict with DMA access. In this situation DMA 
> cycle wins and CPU write access goes nowhere. (There are latches between 
> CPU and chip bus that separates CPU side and chipset side data bus)
>
> I guess best option is to call some platform specific function from TAS 
> that can do whatever it wants instead of hacking any platform specific 
> code in TAS CPU core functions? (It currently has UAE specific TAS hack)

Hi

I will add some Hatari specific code in TAS (unless you want to add an 
empty handle_tas_xxx function in gencpu for TAS that could be replaced 
by a non empty function in the case of Hatari ? that would allow to keep 
a common gencpu, but if you feel it has no use for amiga, no problem, I 
will add it directly in Hatari's code)

> Does this also mean 68020+ CAS/CAS2 need similar special handling in 
> Hatari? (If there are some software that assumes locked 
> read-modify-write cycle will affect blitter)

I guess it would require similar special case. But regarding using them 
in the case of the blitter, I don't think it would have any interest.
So it's likely there's no program so far that relies on CAS/CAS2 really 
doing a rmw cycle during the emulation)


Nicolas