| |
mankeli
Registered: Oct 2010
Posts: 110 |
Is "Inverse FLI" possible?
Is it possible to do "Inverse FLI", ie. reset RC=0 on any line, but not trigger the actual badline DMA?
The VIC Article lists some relevant positions:
Quote:In the first phase of cycle 14 of each line, VC is loaded from VCBASE (VCBASE->VC) and VMLI is cleared. If there is a Bad Line Condition in this phase, RC is also reset to zero.
and
Quote:If there is a Bad Line Condition in cycles 12-54, BA is set low and the c-accesses are started.
But I guess there isn't an instruction that allows one to cancel the badline condition after the RC is reset? |
|
... 6 posts hidden. Click here to view all posts....
|
| |
Oswald
Registered: Apr 2002
Posts: 5017 |
Quote: The only way for RC to become 0 is because of a bad line. Problem is that VCBASE stays the same all the time, i.e. you just repeat the same char row over and over again (u can still change bank, font and screen and you can still choose if you want to fetch new chars pointer FLI, or keep old char pointers and save 40c FPP)
See https://www.linusakesson.net/programming/vic-timing/index.php
"Problem is that VCBASE stays the same all the time, i.e. you just repeat the same char row over and over again"
even if VCBASE would change, there is no badline to reload the character pointers. |
| |
mankeli
Registered: Oct 2010
Posts: 110 |
Originally I was thinking if it would be possible to have badlines and normal 8 line tall characters, but have the DMA always load the character pointers from the same address in the selected screen memory. (ie. have VCBASE to be constantly 0)
I think it should be possible to do this [have DMA always load graphics from same address] with 7px tall characters (as the VCBASE gets updated in the right border when RC=7).
With badline every 4 lines and two fonts (upper and lower half) it should be possible to fake 8px tall characters but it would be nice to skip the "unnecessary" badline :) |
| |
Oswald
Registered: Apr 2002
Posts: 5017 |
it is possible with 7 pix tall character rows. and your 2nd method should work aswell.
https://csdb.dk/forums/?roomid=11&topicid=84186&showallposts=1 |
| |
ChristopherJam
Registered: Aug 2004
Posts: 1378 |
Do you actually want to reload the row every 8 rasters (like, will you be writing new values to them in the intervening lines, like I did for the 5 pixel high characters in Jam Ball 2), or is reading them once per frame then just repeating the same set of characters every row for the entire frame ok? |
| |
Krill
Registered: Apr 2002
Posts: 2839 |
Quoting mankeliOriginally I was thinking if it would be possible to have badlines and normal 8 line tall characters, but have the DMA always load the character pointers from the same address in the selected screen memory. (ie. have VCBASE to be constantly 0) I was looking for something like that once, too. :)
Idea was to have the full-height char rows be fetched continuously from stack, so those 40 chars could be written with 3 cycles each and auto-decrement using PHA in between two badlines.
Alas, didn't find it at the time. Less than full height (like 7 or 4 pixels), no problem, of course. |
| |
Oswald
Registered: Apr 2002
Posts: 5017 |
Quote: Quoting mankeliOriginally I was thinking if it would be possible to have badlines and normal 8 line tall characters, but have the DMA always load the character pointers from the same address in the selected screen memory. (ie. have VCBASE to be constantly 0) I was looking for something like that once, too. :)
Idea was to have the full-height char rows be fetched continuously from stack, so those 40 chars could be written with 3 cycles each and auto-decrement using PHA in between two badlines.
Alas, didn't find it at the time. Less than full height (like 7 or 4 pixels), no problem, of course.
thats pretty cool, but how do you make stack the first line or align it to a row.
linecrunch 3 rows, but then the stack still starts at char 16, so linecrunch and vsp? pretty fucked up but cool at the same time.
but one can have the screen just at zp, same amount of cycles and less hw fuck. |
| |
Krill
Registered: Apr 2002
Posts: 2839 |
Hmm... what happens if you produce a VSP after each char row (going from idle to badline condition mid-line), but without a shift? (Except the crash-proneness on some machines, ofc.) Too lazy to try myself now. :) |
| |
Krill
Registered: Apr 2002
Posts: 2839 |
Quoting Oswaldthats pretty cool, but how do you make stack the first line or align it to a row.
linecrunch 3 rows, but then the stack still starts at char 16, so linecrunch and vsp? pretty fucked up but cool at the same time.
but one can have the screen just at zp, same amount of cycles and less hw fuck. ZP has a similar problem with $00 and $01, so you need to linecrunch anyways in order to get to a feasible memory range quickly. :)
But there's no need to align anything. Linecrunch to stack, and then all chars are fetched from there, doesn't matter where in the stack you are.
See Softwired for an example. :)
(Char rows have various heights depending on zoom level, but 7 lines max.) |
| |
ChristopherJam
Registered: Aug 2004
Posts: 1378 |
I had the screen in ZP for Jam Ball 2 to get those sweet 3 cycle writes, and to avoid row arithmetic in the video decoder, but if I wrote it again there's a fair chance I'd put it in stack instead.
As for the present conundrum, I think this is what we have to work with.
(for the purposes of this description, I'm going to treat the idle state as a special RC value)
- to avoid copying VC to VCBASE at the end of a line, we need to ensure RC is never (7 or idle) in cycle 58.
- the only way to prevent RC from reaching 7 is to clear it before it gets that high
- the only way we can clear RC is to ensure a badline condition in cycle 14
- if we have a badline condition on cycle 14, an entire row is fetched over the next 43 cycles
Given all that, anything we do to only fetch 40 characters once every eight lines, would also only reset RC once every eight lines.
If we only reset RC once every eight lines, then on cycle 58 of the eighth line, VC will be copied to VCBASE, and we advance to the next row.
Even if we fetch fewer than 40 characters by delaying the DMA, all that does is prevent us from clearing RC (although it does become 0 just by overflowing from the 7 on the previous line); we still reach RC=7 seven lines later, and on cycle 58 VC is still copied to VCBASE, so we still advance to the next row..
Can anyone see any flaws in my reasoning or assumptions? |
| |
mankeli
Registered: Oct 2010
Posts: 110 |
Sounds about right |
| Previous - 1 | 2 - Next |
