[hatari-devel] Improving color alignment with pixels

Jean-Baptiste Berlioz jb.berlioz at freemind-tobe.com
Mon Dec 22 23:47:00 CET 2008

> I just committed a patch to do this. As we only have to differentiate 
> between cpu and blitter at the bus level, I added a variable named 
> 'BusMode' which is by default BUS_MODE_CPU.
> When the blitter starts working, it sets BusMode to BUS_MODE_BLITTER.
> When done, it sets it back to BUS_MODE_CPU.
> This way, the overhead is minimal and I don't think we should see any 
> performance impact (no modification to IoMem functions required and no 
> parameter to add).
> Tobé, you can now adjust blitter specific timings in cycles.c and 
> spec512.c (I might put the special case of spec512.c in cycles.c too, 
> so only cycles.c will be relevant).
> By knowing how many words were already processed by the blitter, you 
> should be able to determine how many cycles should be added to have a 
> precise value of the write cycle and obtain correct color alignment 
> and border removal with the blitter.
> Nicolas
Thanks Nicolas,

I've checked out the Mercurial repository and my new FreeBSD 
installation will hopefully be finished tomorrow so I'll be able to code :)
Mercurial is interesting, i like the idea of having multiple branches 

Just before i trashed my Ubuntu installation, i did dome tests with 
mixed YM and DMA sounds, i don't know if theses problems are know:
- Playing DMA samples make YM sounds very noisy
- DMA sounds starts too late
- DMA volume is too high (or YM too low)

It was tested against an MegaSTE.

Have a nice christmas :)

More information about the hatari-devel mailing list