English Amiga Board Mobile
Coders. Asm / Hardware>Modifying blitter registers while it's running
mc6809e 20:47 31 January 2012
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?
[Rep]
pmc 21:59 31 January 2012
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.
[Rep]
mc6809e 23:03 31 January 2012
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.
[Rep]
Toni Wilen 08:35 01 February 2012
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.
[Rep]
Up

Page generated in 0.10423 seconds with 11 queries