Ancient School - new VIC20 demo!

Sdw · Post by **Sdw** » Mon Sep 15, 2008 7:38 am

Thank you all for your comments!

gklinger - Here's some backstory on the demo:
I got my first VIC-20 about a month ago, found a memory map online somewhere (I think it was from the programmers reference guide) and started messing around!
The whole demo was crossdeveloped on PC using Kick Assembler (very good macroassembler, also has quite powerful table-generating functions etc.) To test it on the real hardware I used my C64 with MMC64 to write a D64-file to disk, and then moved over to my VIC-20 to test-run. I found out that I needed to do this quite a bit more than when developing on C64, VIC-emulators still are not perfect!
For the parts where the built in KickAsm table-generation didn't cut it, I used Processing, very nice for prototyping stuff and getting instant visual feedback. This was used for example to precalculate the vector-rotations for the 3D-part.

carlsson · Post by **carlsson** » Wed Sep 17, 2008 2:55 pm

All those nay-sayers at Pouët who complain that the demo doesn't add anything new and even has the nerve to use an old music (with permission!) should buy themselves a new computer and within one month of purchase release something of equal quality or better.

I'm sure Sdw will reach even higher artistic levels once he has learned the features, tricks and limitations on the VIC-20. Frankly I'm too tired to even start thinking about how you get the bobs on top of background graphics, but perhaps it is easier than it looks.

Mike · Post by **Mike** » Thu Sep 18, 2008 12:49 am

Maybe Sdw 'forgot' to set bit 3 (value eight) in 36879.

hawk · Post by **hawk** » Thu Sep 18, 2008 1:09 am

Great Demo Sdw, well done.

I really love the way you've used simple techniques to create striking effects...the multi-colour screen wipe, and the overlapping character blocks. I'd never twigged that the overlapping colours would produce other colours that are available in the palette.

Very cool.

I don't think that demo's need to come up with new techniques all the time. Reusing known techniques to create new artistic effects is fine. Ultimately, it's the demo coders expressing their artistic bent, and learning how to implement the techniques for themselves.

eslapion · Post by **eslapion** » Thu Sep 18, 2008 3:26 am

carlsson wrote:All those nay-sayers at Pouët who complain that the demo doesn't add anything new and even has the nerve to use an old music (with permission!) should buy themselves a new computer and within one month of purchase release something of equal quality or better.

I'm sure Sdw will reach even higher artistic levels once he has learned the features, tricks and limitations on the VIC-20. Frankly I'm too tired to even start thinking about how you get the bobs on top of background graphics, but perhaps it is easier than it looks.

Yeah, I read some of the comments posted on Pouët... such losers... What in god's name do they have against RAM expansion??

Somebody should make a big beautiful demo that only runs when it detects 16K of RAM or more and only displays "Losers can't afford extra RAM!" when started on an unexpanded VIC... just for these guys.

nbla000 · Post by **nbla000** » Thu Sep 18, 2008 6:45 am

eslapion wrote:Somebody should make a big beautiful demo that only runs when it detects 16K of RAM or more and only displays "Losers can't afford extra RAM!" when started on an unexpanded VIC... just for these guys.

Yes, i do not understand why a demo must be only for unexpanded vics, if someone made a good demo for 16k vics, which is the problem ?

Normally to by-pass the unexpanded vic memory limits demo coders made multipart programs using loader routines so which is the difference if i wish to made just one program for a 16k vic ?

carlsson · Post by **carlsson** » Thu Sep 18, 2008 7:50 am

Many commenters probably has no clue about the VIC-20 architecture, thinking that more RAM means more room for graphics. While it gives more workspace for calculations and temporary graphics storage, everything needs to be moved to the built-in memory anyway to be displayed. Well, unless you make effects out of the unconnected address space, then it doesn't matter.

Sdw · Post by **Sdw** » Thu Sep 18, 2008 8:33 am

I don't pay much attention to those few negative comments on Pouet - the overwhelming majority seems to have liked the demo (and it also actually won the compo at Sundown!).

To be honest, the extra memory did help me quite a bit for many of the graphic effects, as it allowed me to use a double-buffer.
Dots, DXYCP and vector all use this system, with a textscreen at $0200 and then swapping between two charsets at $1000 and $1800, so I use about $1100 bytes (=4352 bytes) for graphics. It would be kind of hard to fit in the rest of the code on an unexpanded VIC then!

adric22 · Post by **adric22** » Sat Oct 04, 2008 3:50 pm

I liked this demo too and I wish I could see more demos for the VIC-20 that use 16K or 32K. One thing that you just absolutely can't do on a 5K VIC is display a full-screen graphics image. The one on this demo looked pretty good (although I had to cut that screen out for my vic-20 documentary due to the nudity)

I don't think in this day and age that we should be concerned about supporting 5K VIC-20's because I think anyone who still uses one today has an expander, or they are running the software in VICE. Even if they don't have an expander, they can be bought or built very cheaply.

Sadly, I have a 32K expander for my VIC but I still watched the video in VICE because it it too much of a pain to copy the files over to the real hardware when I can pull it up in VICE in seconds.

carlsson · Post by **carlsson** » Mon Oct 06, 2008 12:02 am

Please define full-screen graphics. At least the VIMMII demo displays a 100x160 pixel (4000 bytes) graphics image on an unexpanded machine, but it takes it to be booted from a loader using up almost all of the low 1K, thus not really Basic friendly.

adric22 · Post by **adric22** » Wed Oct 08, 2008 4:39 pm

carlsson wrote:Please define full-screen graphics. At least the VIMMII demo displays a 100x160 pixel (4000 bytes) graphics image on an unexpanded machine, but it takes it to be booted from a loader using up almost all of the low 1K, thus not really Basic friendly.

Wow.. I hadn't heard of this demo, I had to go google it. Once I saw the pictures I was very impressed. I bet if I had seen that on a demo unit running in a store in 1981 I would have passed out.

Is it possible to use the C64 trick for making "FLI" graphics on the VIC-20? I realize a ram expander would be required.

carlsson · Post by **carlsson** » Thu Oct 09, 2008 1:31 am

I'm not entirely sure what FLI does on a C64, although I've heard the term a number of times and seen demos incorporating it in different ways.

Mike · Post by **Mike** » Thu Oct 09, 2008 2:27 am

FLI on the C64 creates additional "bad-lines" that stop the CPU. In that way, the VIC chip re-reads the attribute data from a different source, in thus enhances the colour-resolution, when using a hi-res screen (the text map defines two colour sources in that case).

On the VIC-20, in effect, all lines are already bad-lines. The VIC chip always first reads the current text-character in the second half of the preceding character, and then it reads the pattern from character ROM, or RAM, to display the first half of this current character. The CPU need not be stopped, because of the lower overall bandwidth needed.

But in general, this cannot be used for an advantage, as there is no hires mode, that uses the text map as colour source. Also, the VIC chip can only access the built-in RAM.

The sole exception might be the slightly enhanced colour resolution that can be gained by providing two identical text maps for VIC's double-height character hi-res mode in $0000, and $0200 - switching between them every 8th raster, and thus tricking VIC to read different portions of the colour RAM.

Michael

drvanthorp · Post by **drvanthorp** » Fri Oct 10, 2008 1:02 am

nbla000 wrote:Yes, i do not understand why a demo must be only for unexpanded vics, if someone made a good demo for 16k vics, which is the problem ?

It might be an ethos from the early days of computing, when the geeks would talk up the capabilities of their favorite machine.

The Apple II guys would always claim that their machine could beat Atari 800, C-64, etc, because thousand dollars or two, they could buy a graphics or sound expansion board that would upgrade the machine to commercial grade.

So it became the ethos that the machine's capabilities should be judged based on its stock unexpanded standard equipment. And since a demo was foremost a demo of that machine's capabilities, to use extra hardware of any kind was a cheat.

drvanthorp · Post by **drvanthorp** » Fri Oct 10, 2008 1:12 am

Mike wrote:FLI on the C64 creates additional "bad-lines" that stop the CPU. In that way, the VIC chip re-reads the attribute data from a different source, in thus enhances the colour-resolution, when using a hi-res screen (the text map defines two colour sources in that case).

On the VIC-20, in effect, all lines are already bad-lines. The VIC chip always first reads the current text-character in the second half of the preceding character, and then it reads the pattern from character ROM, or RAM, to display the first half of this current character. The CPU need not be stopped, because of the lower overall bandwidth needed.

But in general, this cannot be used for an advantage, as there is no hires mode, that uses the text map as colour source. Also, the VIC chip can only access the built-in RAM.

The sole exception might be the slightly enhanced colour resolution that can be gained by providing two identical text maps for VIC's double-height character hi-res mode in $0000, and $0200 - switching between them every 8th raster, and thus tricking VIC to read different portions of the colour RAM.

Michael

You could use this technique in multi-color mode to change the background, border, and auxiliary colors on each line. Would it be possible to write to 22 bytes of color memory during the horizontal blanking interval?