| |
Digger
Registered: Mar 2005
Posts: 447 |
$d011 trickery duplicated text lines
Does any one know the $d011 trick to repeat the first char row? I am trying to cancel badlines on the 8th line of each charline (between cycles 54-57) but it doesn't work. The first line gets duplicated but only twice. |
|
... 57 posts hidden. Click here to view all posts....
|
| |
Oswald
Registered: Apr 2002
Posts: 5126 |
what if I do the "no badline" row repeat on the last pixel row of a char row, but then manually make a badline in the next raster line ? can this be done ?:P |
| |
ChristopherJam
Registered: Aug 2004
Posts: 1423 |
Sadly not. The issue is that each “no badline” row repeat secretly updates the row pointer to the next row, so the moment you do a DMA you’d get a later row than what you want,
(Useful for other effects of course, like double buffering half res d800) |
| |
Oswald
Registered: Apr 2002
Posts: 5126 |
what you describe sounds like the normal behaviour ? rc to 0 and next row read up. |
| |
ChristopherJam
Registered: Aug 2004
Posts: 1423 |
Yes, except it doesn't actually fetch the characters, so the internal row buffer remains unchanged. |
| |
Oswald
Registered: Apr 2002
Posts: 5126 |
ok while we're at it can you explain last row stretch with internal counters? I'm staring at the VIC article but the more I stare at it the less sense it makes. like RC is never incremented after reaching 7 by these rules:
"In the first phase of cycle 58, the VIC checks if RC=7. If so, the video
logic goes to idle state and VCBASE is loaded from VC (VC->VCBASE). If
the video logic is in display state afterwards (this is always the case
if there is a Bad Line Condition), RC is incremented."
so RC=7, we go to idle state, thus RC is not incremented hence it is only incremented in display state.
I'm thinking of stretching the last pixel row, to get the 8 high char line I want.
ok not possible hence my last is 7th not 8th, and that stretch only works on 8th.
only straw left is repeat 1st line but that adds only a badline, urgh. |
| |
Oswald
Registered: Apr 2002
Posts: 5126 |
ok I guess I get it, if *sometime later* there is badline then will we go back to display state and increment rc. whenever. |
| |
ChristopherJam
Registered: Aug 2004
Posts: 1423 |
Yup, exactly.
Lft's done a nice PDF of the timing, you can find it at https://www.linusakesson.net/programming/vic-timing/ |
| |
JackAsser
Registered: Jun 2002
Posts: 2038 |
Quote: Yup, exactly.
Lft's done a nice PDF of the timing, you can find it at https://www.linusakesson.net/programming/vic-timing/
Yes. Do read this. It takes a while to understand how to interpret it but once you learn it all VIC-tricks are easy to figure out. |
| |
Oswald
Registered: Apr 2002
Posts: 5126 |
already used this pdf, but not the how rc /vc works part, that still needs a lot of thinking :)
fex, I can not explain how/why last row stretch works. |
| |
Rastah Bar
Account closed
Registered: Oct 2012
Posts: 336 |
I noticed something strange, could someone explain this to me, please?
I create a badline after cycle 14 on every 4th rasterline, starting on line $30. I also opened the borders. In text mode you can see the memory wrap around: the last 5 rasterlines on the text screen start with the characters in memory locations $07e8 and so on, with colors from $dbe8 and so on.
On rasterline $30 the last byte from each character in $0400 ... is visible, but in the colors from $dbe8 and so on. This caught my attention since I expected the screen ram and color ram memory addresses to match.
If I do the same thing in hires bitmap mode, rasterline $30 now shows the colors from rasterline $f8, but in bitmap mode these colors are determined by screen ram.
So in plain text mode data from $0400 ... is shown in rasterline $30, while in bitmap mode data from $07e8 ... seems to be used.
I'm seeing this in VICE 3.5, Hoxs, and micro64. |
| Previous - 1 | 2 | 3 | 4 | 5 | 6 | 7 - Next |
