Modifying blitter registers while it's running

[mc6809e]

To what extent is it possible to modify the blitter registers while it's running? I know some register accesses cause the blitter to halt.

I'm trying think of what might be possible if the blitter writes to the data portion of a copper list which then moves the result back into a blitter register. It sounds crazy, I know, but maybe some interesting things are possible.

Does anyone know what is touchable while the blitter is running?

[pmc]

Toni would obviously be best placed to give you the official answer but my experience of modifying blitter registers in the middle of blits that were already using those registers was just plain unpredictable results.

[mc6809e]

Originally Posted by pmc

Toni would obviously be best placed to give you the official answer but my experience of modifying blitter registers in the middle of blits that were already using those registers was just plain unpredictable results.

So the blit doesn't necessary stop. Interesting.

I was thinking things might predictable if the nasty bit is set, and if blits are controlled completely by the copper. I can understand the difficulty of trying to change the registers with the CPU and getting repeatable results, but consistent patterns of operation should be achievable using the copper. It should be possible to predict down to the cycle what the blitter is doing as long as the CPU is prevented from stealing cycles.

[Toni Wilen]

There is no 100% known information because no one knows how blitter is actually implemented. Logic analyzer cycle diagram tests shows some interesting information.

Most registers are "safe" to change (pointers, modulos, data registers), they are nothing special compared to other similar registers. Of course changing pointer and data registers require very very exact timing. I guess this is at least in theory possible with copper. Modulos aren't that timing sensitive, at least if blit is wide enough.

Note that there is Agnus limitation that afaik affects all DMA pointers: there must be at least 1 cycle between accesses to same DMA pointer register or following access does nothing if it is CPU/Copper write. In real world it mainly affects sprites, if copper list sets sprite pointers just before or after sprite DMA read access (There is a demo that requires this behavior..)

I think this can cause bad problems if blitter DMA pointers are poked while blitter is active.

Changing DMA channel enable bits, line draw or fill enable bits either halts the blitter or blitter's cycle diagram changes to something strange. (http://eab.abime.net/showpost.php?p=579713&postcount=17)

I assume in this situation blitter's internal cycle diagram logic gets in impossible or bad state. Someday I'll test all possible dma channel + fillmode change combinations' cycle diagrams.. Lots of boring work.

I haven't tested how shifts behave.

[PiCiJi]

Originally Posted by Toni Wilen

Note that there is Agnus limitation that afaik affects all DMA pointers: there must be at least 1 cycle between accesses to same DMA pointer register or following access does nothing if it is CPU/Copper write. In real world it mainly affects sprites, if copper list sets sprite pointers just before or after sprite DMA read access (There is a demo that requires this behavior..)

I think this can cause bad problems if blitter DMA pointers are poked while blitter is active.

I have tried to change the D pointer during blit on A500 OCS. Cycle diagram was D only. ( -D )

The results differ between new D pointer is accepted or ignored at all. Blitter nasty or not doesn't matter. And sometimes the blitter seems to freeze. (not that often)
The cpu can do the write in idle cycle only. So I have expected the pointer change is ignored each time because there is always a pointer access by blit operation in the next cycle or cycle before.

It seems very unpredictable but I don't believe it is.

[Toni Wilen]

Originally Posted by PiCiJi

I have tried to change the D pointer during blit on A500 OCS. Cycle diagram was D only. ( -D )

WORD or LONG write? LONG write can have "unreliable" timing (long delay between first and second word write) if first word write happens just before refresh cycles. During refresh cycles CPU can't get any memory access cycles if blitter is also active.

[PiCiJi]

word writes only.

Originally Posted by Toni Wilen

During refresh cycles CPU can't get any memory access cycles if blitter is also active.

can blitter idle cycles executed during refresh cycles or is it delayed until next free cycle?

[PiCiJi]

I haven't taken in account the higher level dma accesses which can increase cycles between D pointer access and CPU writes during idle cycle. So it should be normal that some pointer changes are ignored and some accepted.

[Toni Wilen]

Originally Posted by PiCiJi

can blitter idle cycles executed during refresh cycles or is it delayed until next free cycle?

No, blitter idle cycle need "real" free cycle.