** New Frontiers in VIC-Hires-Graphics, Part 15

[tokra]

I'm being a little snooty this time Can anyone guess what the graphic below means?

Winner get's a preview Oh, and Mike is disqualified, cause he knows and would otherwise win this anyways

[eslapion]

Are you trying to make a 6560 replica?

In VHDL or something else?

[Witzo]

A graph showing which memory address is updated by the VIC chip at what point while drawing a screen line?

[darkatx]

Looks like using the illegal opcodes you managed to squeeze in yet another update per line meaning we have a new PAL resolution!

[Wilson]

Are you updating $9000 every 4 lines so you have more time to update the contents of $900e/$900f? Hmm, this is a head scratcher. This is the first time you've used $9000 for PAL right?

[tokra]

darkatx and Wilson are getting pretty close

However illegal opcodes are not responsible for the new PAL resolution. Using $9000 has to do with it.

[FD22]

Hmm.

$9000 means either a change to the visible-area screen x-position, or a flip of the interlace bit. If this is a PAL access diagram, we can discount the latter. So you're tweaking the screen-x position, and afterwards you tell the VIC to look in an alternate location for data and colour...

You're changing the auxiliary and primary colours on every line - so I'm guessing you're 'fudging' an extra colour/data update by rapidly shifting the visible screen in a 'shimmy' effect, using POV to make the screen 'appear' wider than it actually is.

[tokra]

Getting warmer The first $9000/$9002 pair shifts the screen 3 chars to the left and expand the screen by 3 chars. The latter $9000/$9002 pair shifts the screen back 3 chars to the right and shortens the line by 3 chars again.

But why would I do this? What is the advantage? Hint: It's what you DON'T see in the graphic I posted...

[FD22]

IRQ jitter?

On which note, you might find my most recent VIC++ post mildly interesting in a sort-of-related way.

[Wilson]

Looks like you have time before the $9000/$9002 updates to do 3 extra LDA#/STA's. So this allows you to write ahead the color data for the red A,B,C or the purple D,E,F four lines before it is displayed.
Maybe?

[tokra]

Nope If you compare the diagram above to the FLI96-diagram I posted in Part 14 you will notice that both modes update exactly 72 color-RAM bytes during an 8 line area. However while the FLI96-mode updates 12 bytes for 6 lines (with 2 lines being updated during VBLANK), this mode does something different.

Maye I can explain the FLI96-mode a little better:

Lines 0 and 2 of each 8-line block are updated in the 56 lines-vertical blanking area and need (32 eight-line-blocks * 2 lines-per-block * 12 chars-per-line * 6 cycles-per-char LDA/STA) = 4608 cycles for those updates. The VBLANK-area just provides 56*71 cycles=3976 cycles. However each 8 line area still has a little room left after line 7 has been displayed and the next line 0 has not started to display yet, giving the opportunity to update another 5 chars in each of the 32 eight-line-blocks = 160 chars or 960 cycles, which means I need only (4608-960)=3648 cycles of the VBLANK-area. The other lines (1 and 3-7) are updated within the 8 line block and are the 72 color-RAM-bytes I mentioned above (6* 12 bytes).

So with only 328 cycles left during each video-frame the way I do it above, where is there room for improvement? Hint: Look for clues in Part 4 of this series and the Yes VIC can-demo-thread.

[Wilson]

Sorry for forcing you to explain all that. I probably should've just gone back and read/re-read the past parts.
Are you using the column expansion to reveal new characters as a method to get unique colors below red A,B,C without touching their color memory? Must be more to it than that though if it takes 4 LDA#/STA's to do the $9000/$9002 updates versus the 3 you save. I guess you can shift the colors this way if that's any help.

Would this mean D,E, and F get drawn twice? How does the VIC know what screen position it's at when you change the values of $9002 as it's drawing? Does it check at lines with the tops of the characters? So many questions...

And I'm running out of uneducated guesses.

[tokra]

Sorry for forcing you to explain all that. I probably should've just gone back and read/re-read the past parts.

No need to be sorry. The FLI96-mode needed some more 'splainin

Are you using the column expansion to reveal new characters as a method to get unique colors below red A,B,C without touching their color memory?

YES! Exactly! Very nice

How does the VIC know what screen position it's at when you change the values of $9002 as it's drawing? Does it check at lines with the tops of the characters?

Good question From what I found out through experimenting the VIC applies switches to the horizontal position ($9000) and the number of characters per line ($9002) ONCE per line, probably at the very start in the horizontal blank area. However it is possible to switch the video/color-RAM position (also $9002) also WITHIN a line. Since I needed to expand and shift the lower 4 lines of an 8-line block (and back again) I had to make sure those switches are done in the line BEFORE they need to take effect, but not too soon in that line either because of the color-RAM switch taking effect before it should.

Must be more to it than that though if it takes 4 LDA#/STA's to do the $9000/$9002 updates versus the 3 you save.

Actually the "penalty" is only 2 LDA/STA, since the $9002 updates are necessary anyways to switch the color-RAM betwenn $9400 and $9600. It's an added bonus that I need to change the line width as well and can do this in one write to $9002.

Would this mean D,E, and F get drawn twice?

In total they get drawn 4 times, twice of those within the eight-line-block (line 5 and line 7) and twice pre-set in the VBLANK-area or the small area between line line 7 and the next line 0. So I save 6 character updates instead of just 3 per eight-line-display-block. So this means in an eight-line-block I update 4 x 13 chars plus 2 x 10 chars = 72 chars the same number als in FLI96. However this means in order to get 13 characters per line in an eight-line-block I need to update the other 32 chars (of a total 13 x 8 = 104) per eight-line-block in the VBLANK or the "in between"-areas of each such block. You can see in the diagram above I have time for updates in Line4 for position D,E and F in this small area, leaving 32 x 29 = 928 characters to be updated during VBLANK.

Now if you can guess how to update 928 characters in 56 x 71 = 3976 cycles you win this little quest

[Wilson]

Actually the "penalty" is only 2 LDA/STA, since the $9002 updates are necessary anyways to switch the color-RAM betwenn $9400 and $9600. It's an added bonus that I need to change the line width as well and can do this in one write to $9002.

Ohhh, of course. That is the root of most my misunderstandings I think.

Thanks a bunch for all the explanations!

Now if you can guess how to update 928 characters in 56 x 71 = 3976 cycles you win this little quest Smile

Now THAT sounds like a problem. Can you elaborate on what you mean by update? In that amount of time I can't think of anything but some zeropage STA/STX/STY, PHA's, and absolute STA/STX/STY's with a few LDA#,LDX#, and LDY#'s.

edit: I guess that works out to 1536 cycles for writing the zeropage and stack, 1664 for everything else, which leaves (3976)-(1536+1664)=776 for LDA#,LDX#,and LDY#'s. Or 388 immediate loads. If you use each value multiple times before reloading it, that should be sufficient for updating all the locations with arbitrary values.
But I'm still not quite sure I understand what's being updated. Is any of it even in the ZP or stack?

[tokra]

Now if you can guess how to update 928 characters in 56 x 71 = 3976 cycles you win this little quest Smile

Now THAT sounds like a problem. Can you elaborate on what you mean by update?

With update I mean a change back of a byte in color-RAM to it's "initial" value. Specifically line 0 and 2 of each eight-line-block need to be updated in the VBLANK since they are destroyed during the display of each eight-line-block. So these are writes to $9400,$9401,... and $9600,$9601,... (not stack or zeropage)

I guess that works out to 1536 cycles for writing the zeropage and stack, 1664 for everything else, which leaves (3976)-(1536+1664)=776 for LDA#,LDX#,and LDY#'s. Or 388 immediate loads.

I'm not really sure how you came up with those numbers, but...

If you use each value multiple times before reloading it, that should be sufficient for updating all the locations with arbitrary values.

This is essentially it. There are only 16 possible values in color-RAM (8 for each color and the multicolor-bit can be set for each of those). So I only need 16 LDAs from lda #$00 to lda #$0f, and after each of those I need to STA the value to each color-RAM address that is going to have this value in line 0 and 2 of each of the 32 eight-line-blocks in the picture. Giving a total of 928 x 4 (STA) + 16 *2 (LDA#) = 3744 cycles. Leaving 232 cycles free, a few of which are used by the rotuine that waits for a keypress to exit the viewer. Also I need two switches for $9005 after half a picture each, since I use two video-RAMs at $0000 and $0200 and a full 4K char-RAM at $1000-$1fff and this only works with a switch of $9005 in the middle.

All this finally comes together in FLI104-mode: 104 x 256 pixels with 8x1 color resolution as well as background/foreground/auxiliary color per line:



Because of the left shifting for the bottom 4 lines of every 8-line-block there is a 3 character-wide area for those 3 lines that inherits the color-RAM information of the first 3 visible characters of the 4 lines above. Mike mentioned that this resembles the FLI-BUG area of the C64's FLI-mode, albeit for a completely different reason I think 104x256 is a nice format. It is 2:3 and it is easy to find pictures in this format around the web.

With 104x256 FLI-mode exactly HALF of what Mike can do with his VFLI-hardware-mod has been achieved on the PAL-VIC (+24K). The hardware-mod has some more advantages, like not eating up 100% of the CPU-time as well.

Wilson: Good job. PM sent