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

Basic and Machine Language

Moderator: Moderators

Post Reply
User avatar
tokra
Vic 20 Scientist
Posts: 1120
Joined: Tue Apr 27, 2010 5:32 pm
Location: Scheessel, Germany

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

Post by tokra »

Image

Announcement/Download

With the last few releases for NTSC, I thought it was time to revisit the PAL VIC-20 and apply the knowledge I gained in the last months. You can see the result in the two newly created graphic modes presented here.

The first mode FLI96 expands the already known FLI-mode (8x1 color resolution) for the VIC-20 by about 33% (from 72 to 96 pixel width). This was made possible by updating the color-RAM in just the right moment to show the next line, which I will explain further in a later post.

In part 13 of this series the other mode of this little demo is already explained: the 224 x 280 graphics mode which uses the maximum display area the VIC-20 can show with overscan. You will need a display- device that can squeeze the picture vertically as well as horizontally. I use a Commodore 1084 myself. You can also use VICE for this. 224 x 280 is the maximum resolution that can be displayed with "Normal Borders" in VICE, as well.

Mike came through, as always, with his brilliant converters, further improving them along the way. It still amazes me how the converters can decide whether to use a multicolored or hires block for a specific area. Thanks again! The converters work just like in my other demos. You need to create an input.ppm in the appropriate resolution, have it run through the .exe (or .cmd) and then have the VIC-20 do the final conversion to an executable VIC-20-file. For .pgm-files you can use the VIC-20 directly. For both tasks using VICE in warp-mode is highly recommended.
User avatar
darkatx
Vic 20 Afficionado
Posts: 470
Joined: Wed Feb 04, 2009 2:17 pm
Location: Canada

Post by darkatx »

I now wish I had a PAL...looks fantastic guys! :shock:
Learning all the time... :)
User avatar
tokra
Vic 20 Scientist
Posts: 1120
Joined: Tue Apr 27, 2010 5:32 pm
Location: Scheessel, Germany

Post by tokra »

YouTube now available. Or just try it yourself in VICE.
User avatar
tokra
Vic 20 Scientist
Posts: 1120
Joined: Tue Apr 27, 2010 5:32 pm
Location: Scheessel, Germany

Post by tokra »

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?
Last edited by tokra on Sun Mar 31, 2013 12:18 pm, edited 3 times in total.
tlr
Vic 20 Nerd
Posts: 567
Joined: Mon Oct 04, 2004 10:53 am

Post by tlr »

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
Vic 20 Hobbyist
Posts: 148
Joined: Mon Feb 15, 2010 12:31 pm

Post by FD22 »

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.
User avatar
tokra
Vic 20 Scientist
Posts: 1120
Joined: Tue Apr 27, 2010 5:32 pm
Location: Scheessel, Germany

Post by tokra »

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 :-)
User avatar
tokra
Vic 20 Scientist
Posts: 1120
Joined: Tue Apr 27, 2010 5:32 pm
Location: Scheessel, Germany

Post by tokra »

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
Vic 20 Amateur
Posts: 63
Joined: Fri May 31, 2013 10:37 pm

Post by metalfoot76 »

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.
User avatar
Victragic
Frogger '07
Posts: 605
Joined: Tue Nov 14, 2006 5:56 pm
Location: South Australia

Post by Victragic »

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.
3^4 is 81.0000001
User avatar
tokra
Vic 20 Scientist
Posts: 1120
Joined: Tue Apr 27, 2010 5:32 pm
Location: Scheessel, Germany

Post by tokra »

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...
Post Reply