It's working! Full motion video on a VIC-20 (+3K)

[JanD]

Hello,
I've just posted a video (see the link below) where I demonstrate full motion video on a VIC-20 (does require a 3K expansion).
I'm super proud of this achievement as I believe that this has never been done before on a VIC-20, so I decided to make a video and share it with you all on this forum.

I use my Cassiopei v2.0 in combination with some experimental electronics connected to the userport. Using some highly optimized code I'm now able to achieve monochrome 192x160 @ 12frames/sec and with 4bit audio @ 12kHz. Because the data is transmitted over the userport it means that all the data is to be handled by the VIC-20 as there is no direct access to the memory. Although the userport seems like a bad choice (cartridgeport would be better perhaps) the userport is partially the same for all CBM computers. There are some differences, but the 8-bit IO used is available on them all. Meaning that this hardware is potentially usable on all CBM models. Therefore complementing the functionality of the Cassiopei itself. Please be aware of the fact that this is all highly experimental and not for sale. Development with this technology isn't finished yet as I aim to use this to make an FMV game. Something that isn't easy considering the low resolution of the system even further reduced by the dithering to create the shades.

I use the VIC-20 in the 24x10 double height character mode. Preparing the datastream towards the userport is done on a PC where I've written a small program to convert a regular video into something a VIC-20 can display. That data is saved onto an SD-card from which the Cassiopei reads it and sends it towards the electronics located at the userport. I did need to do some trickery there as the Cassiopei didn't really have enough IO-pins left to send the 8-bits data. But a simple solution in the form of a shift register proved to be working fine.

Have fun watching and feel free to sing along (in real life the video is best watched by standing approx 2m away from the monitor).

https://www.youtube.com/watch?v=oOowlcsADt4

Kind regards,
Jan

[tokra]

Pretty neat! Congratulations

A few questions:

- does this work on PAL or NTSC (or both?).
- why did you choose 192 x 160? My guess: If I calculate to the pixel-aspect-ratio of the NTSC-VIC (roughly 3:2) 192x162 would give a 16:9 picture. 192x160 is pretty close to that. For PAL the best resolution would be 176x168 if I calculated this right.

I think Mike may be able to help out so that the video can played directly from the SD-card using an SD2IEC. This would broaden the possible user base somewhat.

[JanD]

The VIC-20 I own is a PAL machine but I can't see any reason why this should not be working on an NTSC machine. I'm not sure if it is possible to get an NTSC machine to work with a 24x10 double height character mode. If it does, then it should work "out of the box".

The chosen resolution is simply defined by the way the characters map onto the screen, you cannot define a screen wider wthenthe multiple of the width of a chaarcter. Of heigher then the multiple of the height of a character. The VIC has no real highres mode so you must create one by placing a charset on the screen and then modify the charset. In 8x8 charset mode the screen resolution is always a multiple of 8 in both directions. But since there are only 256 possible different characters in a charset the size of the screen would be small.
Using the double height charset, you get a screen that is a multiple of 8 for the width and 16 for the height.
With 10 rows of characters of double heigth, the height of the screen is simply 10x16pixels= 160 pixels. I would love to have added another row (bringing the height to 11x16pixels=176, but that wasn't possible, because it would require 24x11=264 definable characters, that's more then possible. A charset

I chose the 192x160, simply because thats 24x10, allowing to use up to 240 (double height) characters from the character set, meaning the max amount of pixels on the screen. This resolution has a ratio of 6:5 which is very close to 4:3 (the old format of the screen)
For example:
If I chose 21x10 it would be 210 chars on the screen
If I chose 20x11 it would be 220 chars on the screen
If I chose 20x12 it would be 240 chars on the screen, which would have been fine perhaps but the screen ratio would be 9:10 which simply looks a little odd.

regarding "I think Mike may be able to help out so that the video can played directly from the SD-card using an SD2IEC. This would broaden the possible user base somewhat." I'm not really sure. Video+audio playback requires a relatively large bandwidth, a standard SD2IEC can do, in combination with JiffyDOS, somewhere around 5KByte/sec. Impressive but a factor of 10 too slow for video playback. So there still need to be made something to interface to the userport, as paralell data transfer is the only realistic option. Personally, if there is a large user base to be supported then an SD-card based utility cartridge would be perhaps the best option. But anyway, in both cases we are speaking about an entirely new project for hardware that I do not own. But you do have a point regarding user base

[Mike]

Jan, I suppose when you're talking about the screen resolution and screen size, you're not taking the pixel aspect ratio (PAR) into account. The hires pixels of the VIC-I chip are not square, they're horizontally elongated. With PAL, roughly 1.67x wide as high (or, in small numbers, a PAR of 5:3); with NTSC, roughly 1.5x wide as high (i.e. a PAR of 3:2 in small numbers). Multiplied with the horizontal and vertical resolution, you get the screen aspect ratio - that thing that is normally quoted as screen format, 4:3, 16:9, 2.35:1 or the like.

Now with the pixel resolution of 192x160 you chose, this actually ends up as 2:1 screen format (in PAL) - i.e. the visible area of the whole picture is twice as wide as it is high. This is also clearly visible from your YouTube videos. Surely not too bad for original wide screen format movie sources.

For my MINIGRAFIK tool, I chose the other setup with 240 double-height chars, 160x192 pixels. What you describe as "a little odd" actually ends up near to the well known 4:3 screen format.

...

BTW, displaying 256 characters at once on screen (especially for a bitmap) is by no means the limit. Torsten and I worked hard in 2010 to 2013 to disprove this claim - see our series "New Frontiers in VIC-Hires-Graphics", where we went all the way up to 224x280 bitmapped in PAL, 192x416i bitmapped in NTSC, and for more colourful graphics, 104x256 FLI (i.e. Flexible Line Interpretation) in PAL and 88x400i FLI in NTSC.

These screen modes employ speed code to pump bitmap data from external memory into the internal RAM. It is ensured, that the video chip always has the necessary data available when the electron beam arrives at this point. That method generally puts a high load on the CPU, therefore most of those new modes are only suitable for displaying static images.

Finally I have to concur, that SD2IEC is limited by the bandwidth and - as you write - it is too slow by roughly a factor of 10 to do video replay.

The routines for the new screen modes mentioned above could be changed into a dynamic form, yet still be generalised for file I/O. That idea has been outlined by me several times in the forum, and also was envisioned to be incorporated at least by GCart 2011 (sadly, that project never really took off). That would allow for file I/O of around 150 KB/s - more than sufficient for video replay. If it ever gets realised.

Greetings,

Michael

[Floopy]

Dang, commitment is strong with this one.

Who knows, you could have internet streaming in 1980.

[JanD]

Hoi Mike,
funny... I never noticed the pixels not being really square. But I should have known.
I was so caught up in getting it to work and made it look like modern widescreen format that I didn't even notice it even when the pixel calculation showed a different ratio then what I experienced on the screen. So In short, regarding the ratio... you are right.
But to be honest, I do like the widescreen effect.

When I stated that the 256 chars was the limit I ofcourse meant that for my project. Technically there are indeed some nice tricks to be pulled. But only if you have enough processor time left to do so. In my case there processor is busy for 98% of the time transferring the data. Just to keep a decend framerate and just to maintain 12KHz samplerate for the audio.
Regarding your achievements with pushing the VIC to the limit with those really great hires demos, I can only say that you've done a marvelous job. I watched these images quite a few times and enjoyed the effect with great amazement when I saw it for the first time. And to be honest, it still amazes me. And unfortunately (as you already stated) only really suited for static images. But never say never... as indeed there always is the cartridge option.
All in all, the fun fact is that after 37 years the VIC is still live and kicking.
Cheers,
Jan

[dimebag]

very impressive !!

Cheers

Laurent

[tokra]

Maybe you could add support for the UltiMem-expansion. This has 8 Megabytes of RAM that can be mapped directly into VIC-memory.

[Radical Brad]

Dude, congrats! You really rocked it with that project.
A nice achievement, and being the first you have new VIC-20 street cred!

It's cool to see that 1 bit video is actually quite watchable.
The beach girls in the Miami Vice intro still look good, even though they are made of perhaps a thousand single shade pixels at most.

Brad

[Kakemoms]

Dude, congrats! You really rocked it with that project.
A nice achievement, and being the first you have new VIC-20 street cred!

It's cool to see that 1 bit video is actually quite watchable.
The beach girls in the Miami Vice intro still look good, even though they are made of perhaps a thousand single shade pixels at most.

Brad

At some point we may discover that the Miami Vice girls were actually made out of a few thousand pixel points.. at most.

https://www.scientificamerican.com/arti ... imulation/

Great project! Looks amazing!

[Mike]

Maybe you could add support for the UltiMem-expansion. This has 8 Megabytes of RAM that can be mapped directly into VIC-memory.

Those 8 MB RAM of Ultimem are of no significant help for this application. At a sustained rate of 5 KB/s (SD2IEC with JiffyDOS) it takes 1600 seconds to fill the RAM, nearly half an hour. That's a too much time-consuming preparation - just to be able to see 2 1/2 minutes of video afterwards?

No, the approach of Jan is right: the video (and audio) data needs to be streamed in with the necessary bandwidth.

[LoadError]

I am *very* impressed. Another barrier has been broken.

[eslapion]

I suspected something like that was possible for a long time.

After all, the parallel copiers for the C64/128 take advantage of the user port to read/write complete 1541 tracks (about 8k of data) in 200ms so that's about 40kBytes of data per second.

This video trick uses a somewhat higher data rate and has to generate the sound.

[tonyrocks]

This is madness for sure. You mention wanting to work on a FMV game...why not port Dragon's Lair, or Space Ace? hehe. Should be quite simple.

[Commodorianen]

Wow, really impressive!