[hatari-devel] Improving color alignment with pixels
huth at users.berlios.de
Sun Dec 21 00:56:18 CET 2008
Moving this thread to the new list at berlios.de ...
On Mon, 15 Dec 2008 11:15:58 +0100 (CET)
npomarede at corp.free.fr wrote:
> On Mon, 15 Dec 2008, tobe at freemind-tobe.com wrote:
> >>> How can i adjust these timings for the blitter ? Actually a word
> >>> operation can take from 4 to 12 cycles.
> >>> The cycles buffering implemented in blitter.c was mainly done to
> >>> fix blitter-rasters, and if possible i would like to get ride of
> >>> it.
> >> in order to do this, we would need to adapt
> >> Cycles_GetCounterOnWriteAcces to have a different result depending
> >> on whether the write was made by the cpu or by the blitter.
> >> As the blitter is using iomem funtions, one solution would be to
> >> add a parameter to the functions to tell if the write is performed
> >> by the cpu or by the blitter, and use this in
> >> Cycles_GetCounterOnWriteAcces.
> >> Once this is done, we can have a case for the cpu timing and
> >> another one for the blitter.
> >> Thomas, what would be your opinion on this ?
Sounds ok for me, I also don't have a idea for a real better solution
(with good performance).
> I'm not sure a "simple bus manager" would be as simple as that. It
> requires to break every 68000 opcodes to be able to precisely know
> when a read or a write is done in the internal micro code of each
> 68000 instruction. For example, with a "move.w (a0),(a1)" that takes
> 12 cycles, you need to know when the bus is accessed to read (a0) and
> when it's accessed to write (a1).
> This is a huge task, mainly undocumented. So far, the cpu core in
> winuae has this kind of precision, but porting it to hatari is far
> from trivial.
I once already started on a new CPU core based on WinUAE ... it's a lot
of work, but it can be done. And we would need that anyway one day, as
soon as we want to have its other new features like MMU emulation...
More information about the hatari-devel