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

tokra · Post by **tokra** » Sat Mar 30, 2013 6:52 am

Ok, here is the promised explanation of how the 96-pixel wide FLI-mode works. As you may remember from part 10 of this series in the 71 cycles a PAL-rasterline has I can update 9 byte in the color-RAM (using LDA# STA $) which take up 9 * 6 cycles = 54 cycles. Also I need 2 * 6 = 12 cycles to update $900f and $900e and another 6 or 4 cycles to switch the video/color-RAM pointer after each line for a total of 71 cycles per line in average. So where is the raster-time for updating 3 more bytes per line?

This is accomplished by a different setup of the color-RAM. See the following table:

Code: Select all

Cycles
         1         2         3         4         5         6         7
12345678901234567890123456789012345678901234567890123456789012345678901

                              00112233445566778899aabb
                              ************************
       rrrrrrhhhhhhssssss0000001111112222223333334444445555556666667777   Line 0 (pre-set during VBLANK) $9400
77rrrrhhhhhh888888999999aaaaaabbbbbb00000011111122222233333344444455555   Line 1 Begin Update Line 4

5666666777777rrrrhhhhhhtttttt000000111111222222333333444444555555666666   Line 2 (pre-set during VBLANK) $9600
777777rrrrhhhhhh888888999999aaaaaabbbbbb888888999999aaaaaabbbbbb0000001   Line 3 finish Upd Line 4/Begin Upd Line 6

11111222222rrrrhhhhhhssssss00000011111122222233333344444455555566666677   Line 4 (pre-set by L1/L3 Updates) $9400
7777rrrrhhhhhh888888999999aaaaaabbbbbb333333444444555555666666777777rrr   Line 5 finish Update Line 6

rhhhhhh888888999999ttttttaaaaaabbbbbb0000001111112222223333334444445555   Line 6 (pre-set by L3/L5 Updates) $9600
55666666777777rrrrhhhhhh888888999999aaaaaabbbbbb                          Line 7


s/t = switch $9002
r = Auxiliary $900e
h = background/border
0-b = byte in color-ram
(6 cycles each)

Line 0-7 represent an 8 row area on the screen. Each of these areas (32 in total for 256 lines) is set up the same way. When displaying line 0 all the updates for line 1 will be done in memory. I start with these updates as early as possible. Also for each line you need to set $900e and $900f at the right time. With this setup you only need to swtich $9002 every 2 lines so this save some cycles. The saved cycles need to be used to pre-set lines 4 and 6 respectively so a full 8-row area can be displayed.

Still with all these tricks I was initially coming a little short of just a few cycles to increase the width to 12 bytes (=96 pixels). But there is one more trick to be used which is combining the update of a color-ram byte (#7 in my case) with the update for $900e. This is possible because color-RAM only uses the low nibble of a byte while the auxiliary color only uses the high nibble. This saves one LDA#-instruction = 2 cycles per line, which was what I needed. The side-effect of this trick however is that the volume-register which resides in the lower nibble of $900e is set to the same value as byte #7 of each color-RAM line and this is why you can hear the buzzing noise when these pictures are being displayed, since volume-register change always will create a short cracking noise.

Questions?

tlr · Post by **tlr** » Sat Mar 30, 2013 11:14 am

tokra wrote:Still with all these tricks I was initially coming a little short of just a few cycles to increase the width to 12 bytes (=96 pixels). But there is one more trick to be used which is combining the update of a color-ram byte (#7 in my case) with the update for $900e. This is possible because color-RAM only uses the low nibble of a byte while the auxiliary color only uses the high nibble. This saves one LDA#-instruction = 2 cycles per line, which was what I needed. The side-effect of this trick however is that the volume-register which resides in the lower nibble of $900e is set to the same value as byte #7 of each color-RAM line and this is why you can hear the buzzing noise when these pictures are being displayed, since volume-register change always will create a short cracking noise.

Questions?

Nicely done!

Perhaps you could use a SAX $900E to get rid of the noise?

FD22 · Post by **FD22** » Sat Mar 30, 2013 12:16 pm

I was thinking that too. I also wondered whether any of these extended graphics mode are making use of undocumented opcodes in general? I know I've benefitted significantly from the use of LAX, SAX, SLO/ASO amongst others in VIC++ particularly to maximise screen update speed in the 40x25 display logic.

tokra · Post by **tokra** » Sat Mar 30, 2013 2:32 pm

Thanks for the suggestion. None of the graphic modes use illegal opcodes. I was actually thinking about using ones like LAX or SAX to save cycles, but when programming my first draft I was still using pre-set x and y register for the $9002 updates. I don't use these in the final version and should be able to free the x-register to pre-set it with $f0 to avoid the noise using SAX. Did not think of this before. Please stay tuned

tokra · Post by **tokra** » Sun Mar 31, 2013 12:14 pm

Ok, please try this:

Download

I was able to replace the STA $900e by SAX $900e and pre-set the X-register instead of a wait-command in about rasterline 2. I just needed to change another wait-loop from using the X-register to the Y-register. So, the code is exactly the same length and as such can be dropped in as a replacement in the PPM-import tool. I have included this as well as the silent version of the .d64 in the .zip-file above.

metalfoot76 · Post by **metalfoot76** » Wed Aug 21, 2013 10:48 pm

I pretty much registered on this site to tell you how blown away I am by your VIC graphics demos. I never would have believed a VIC20 could do so many custom graphic modes with the original VIC chip. Wow.

Victragic · Post by **Victragic** » Mon Sep 09, 2013 8:20 pm

I've lurked for a while on this project, but want to echo the sentiments that others have already expressed.

The work you guys have done on this is fantastic, and it's one of the main things that rekindled my interest in the Vic after a few years' absence. It started me wondering how I could implement my own (albeit simpler) graphics modes in new ways.

To see what start as far-fetched ideas turn into reality is a joy. This is far beyond what many of us are capable of doing for our beloved Vic, but it is gratifying to know that there are dedicated people out there who are generous with their time and efforts to bring this to the Vic community.

tokra · Post by **tokra** » Tue Sep 10, 2013 11:29 am

Victragic wrote:I've lurked for a while on this project, but want to echo the sentiments that others have already expressed.

The work you guys have done on this is fantastic, and it's one of the main things that rekindled my interest in the Vic after a few years' absence. It started me wondering how I could implement my own (albeit simpler) graphics modes in new ways.

To see what start as far-fetched ideas turn into reality is a joy. This is far beyond what many of us are capable of doing for our beloved Vic, but it is gratifying to know that there are dedicated people out there who are generous with their time and efforts to bring this to the Vic community.

Thanks, metalfoot76VIC and Victragic. It's really nice to see how we keep the scene alive and that our finding some quirks and tricks to squeeze more resolution or color-resolution out of the VIC inspired someone else to use a similar technique to create a full game with it. This is kind of like reliving the early C64-days when your jaw would drop when you saw the first game that used more than 8 sprites or openend the borders. A little later this was common knowledge and used by everyone to create better games. Who knows what secrets the VIC will reveal next...