Denial

Albert's VIC-Pic already changes the background, border and auxillary colour once every scan line. Only the foreground colours need to be fixed for 8x8 pixels.

drvanthorp wrote: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?

Rasterbars are not FLI.

Altering the colour RAM on the fly doesn't work. A LDA/STA pair needs 9 cycles for transferring a single byte. A horizontal line amounts to 71 cycles available to the CPU.

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.

Fine. A stock VIC-20 doesn't have any storage device built-in.

You really don't expect me to type in a demo before showing it, yes?

Michael

Mike wrote: Fine. A stock VIC-20 doesn't have any storage device built-in.

You really don't expect me to type in a demo before showing it, yes?

Michael

Haha! Right on! So why do people accept demos requiring a disk drive (which were an extremely unusual accessory for the vic-20) and not ram expansions (which almost everyone had)...

drvanthorp wrote: 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.

Let's just say the demo is for the vic-21 then:
http://zimmers.net/cbmpics/cvic1.html

Btw, there are tons of Amiga500-demos requiring expansion memory and Amiga1200 demos that requires turbo boards with memory...

Mike wrote:

drvanthorp wrote: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?

Rasterbars are not FLI.

Altering the colour RAM on the fly doesn't work. A LDA/STA pair needs 9 cycles for transferring a single byte. A horizontal line amounts to 71 cycles available to the CPU.

Michael

There might be another way. I've noticed that some of the most impressive VIC20 demos used the vertical screen positioning register to reposition the screen on each scanline, thereby shuffling the order of pixels rows on the screen. The same technique could be used to shuffle the color mapping (and the character mapping with it). Maybe someone could develop an algorithm (that would probably run on a PC for cross developement) that could reformat full color images into the weird constraints of a scanline-shuffled VIC20 multi color mode screen.

It's been a while. I can't remember if the VIC20 also had a horizontal screen position register. Might be useful for displaying half-screen-width characters with shuffled pixel rows.

I have a thought.. Not sure how valid it is.

I've always been told that the Atari 2600 and the Timex Sinclair generated the screen image via software control only. If that is the case, couldn't you do the same with the VIC-20? I would think you could just have the CPU control the general background color register and time it perfectly to generate the signal. I realize it would be a little more complex due to the fact that the VIC chip is creating the timing to the screen output so you'd have to stay in sync with that. But that would give you a full 16 colors for every pixel.

Adric: Viznut of PWP (and perhaps other VIC-20 coders) already experiments with those techniques, by pointing the VIC chip to unconnected address space so it will pick up what is on the CPU bus. I'm not sure what benefits it has though.

adric22 wrote:I've always been told that the Atari 2600 and the Timex Sinclair generated the screen image via software control only. If that is the case, couldn't you do the same with the VIC-20? I would think you could just have the CPU control the general background color register and time it perfectly to generate the signal. I realize it would be a little more complex due to the fact that the VIC chip is creating the timing to the screen output so you'd have to stay in sync with that. But that would give you a full 16 colors for every pixel.

Won't quite work.

The 2600 had graphics hardware that produced a sinlge line of blocky background and single-line sprites, and it was up to software to change the graphics output on each scanline, but that single line was mapped to about a dozen bytes of memory so that the slow proccessor didn't need to change much.

The Sinclair had funky hardware that tricked part of the CPU proccess into driving the video output, but the heavy lifting was still done by specialized graphics hardware.

So in both machines, the CPU plays a part in the display, but harware does most of the work. 1980's era CPU's just didn't have the speed to change a raster value 100 or more times each scanline. You'd be lucky to get just a few blocky pixels per scanline.

But this is not an unviable idea for newer, faster CPU's. Try doing a Google search for microcontroller video generation.

If you want to experiment with software video generation, you might try this:http://www.xgamestation.com/view_product.php?id=12

Mike wrote: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.

Vicpic uses 16-line characters with 8-line color cell resolution. Hires mode is not a requirement. My unexpanded demos use 16-line color cell resolution because they have to have the display code (and music and loader) in memory as well, so there's no space for the other video matrix.

In the end, it always comes down to one thing: the VIC-I can only address the internal RAM, 5.5kB when taking the color memory nybbles into account. With expansion memory you could probably extend the display by a couple of rows by swapping data between internal and expansion memories, but I haven't done the math to see how much larger picture you would get.

Also, multicolor mode pixels can have color from color memory or VIC-I registers, so any amount of color memory magic can only change one of the four colors, and it is much easier to change the other 3. To make it worse you can only have colors 0-7 in the color memory.

It is totally different in C64 where you only have one common color for the picture, and three for each cell to begin with (without FLI). With FLI you can freely select two colors for every 4-pixel wide groups, a common color for the cell, and a background color for each line.

Mike wrote:Altering the colour RAM on the fly doesn't work. A LDA/STA pair needs 9 cycles for transferring a single byte. A horizontal line amounts to 71 cycles available to the CPU.

LDA #imm + STA abs should be 2 + 4 = 6 cycles, and assuming the same color change is to be done for several chars, the amount of LDA's could be reduced... Would allow some color changes atleast. Probably quite hard to draw using such a mode though, but a converter might be able to benefit...

Someone had a PC linked up to a big projected at Eurocon over the weekend, so there was a time when people were playing random videos. I decided to put on this and Robotic Liberation, I think people were rather impressed given it was the Vic...