Posted By
TLC
on 2010-12-05
18:08:16
|  Re: Vertical splitting
You can't interrupt DMAs in any way. ...It's very simple: you can't get back to control once you lost it, until you're given it back (which won't happen in a middle of a line).
Also, I'd suggest arranging a theoretical experiment. Let's suppose you "can" interrupt a TED badline ie. DMA somewhere in the middle of a line. ...Then, you need to do the $ff06 write (4 cycles), and "re-initiate" the badline (4 cycles at minimum, +3 pending DMA cycles). Let's suppose you combine the two (since it's likely that you'd write $ff06 for both operations anyway). Now you have 7 character places (minimum) whose DMA cycles have been skipped, ie. whose character pointe/color or color/luma data is not updated / is corrupted. ...So even if you could break a badline, you'd still have to face some consequences.
Delaying the start of DMAs might help to arrange the mode change, and still maintain color+luma data fetch for the right side of the screen ie. the multicolor bitmap. Character pointer + color data fetch for the left side are unfortunately skipped (due to the skipped left part of the DMAs). Also, three characters after the position of triggering the DMA -- in this case, the first three positions of the bitmap -- will be "invalid" because of pending DMA cycles.
The most clear solution should be skipping DMAs completely -- with the consequence of skipping character pointer + color / color + luma fetches completely. That is, the left side shows the same rows as the first one (...or invalid data, if the first two badlines had been skipped), and the right side will appear in the colours + luma of the first row (...or, again, invalid colors).
...Or you can possibly avoid the whole fuss by implementing your character-based stuff on the multicolor bitmap... with the other benefit of not having to spend the whole screen in a busy loop.
Edit:
The $b0 value is not precise, I don't remember where exactly the checkpoint is (but all checkpoints that have something to do with badlines + pointer increments are past that point... loosely that value, that is). If you're on a line before a badline, take $ff1d & 07, add x>=2, put that to bit0..2 of $ff06 and you do all that _before_ the b0 point, the next badline will be skipped. You might possibly arrange a test where you'd only deal with badline skipping... won't take more than some ten rows (if you already have the cycle exact timing infrastructure). From that, you could conclude the "last" cycle that still fits.
Also -- notice that you could probably arrange your code to write $ff06 only once. The $b0 cycle is well past the point of where you intend to switch the screenmode.
Edit: ...Precisely speaking, that particular cycle is way "past" the character area, it's in fact at the end of the right sideborder.
|
