VIC interlaced video!!!

[hydrophilic]

Edit
The latest version supports both NTSC and PAL thanks to feedback from forum members AmiDog, bacon, and wte.  It offers:

  2 interlaced hi-res bitmaps (320x400)
  2 interlaced multi-color bitmaps (160x400)
  1 interlaced text screen (40x50)

The remainder of this post refers to the original version.
/Edit
I have created a demo for my new video mode, available here.  There is an existing topic in this forum here.  You can read a full description on this web page.

Basically, it creates an interlaced display on the VIC NTSC screen, but includes customization routines so PAL folks can try it out too.  Besides the customization (a neat 'program' by itself), it offers two cheap demonstrations:

A super-hi-res bitmap (320x400) of a circle.

An emulated 40x50 text screen (just another super bitmap) showing the current directory.

Now, somebody make a cool game and/or a bitmap editor!

Note: this requires a real C128 since current emulators do not support 400+ VIC rasters!

[nikoniko]

This requires a real Commodore 128 because current emulators do not support 400 VIC rasters!

Shame on you making more work for emulator authors.

Anyway, congratulations on the birth of your new video mode! :hurra:

[nikoniko]

By the way, this undocumented test bit would also work in the 128's 64 mode, right?

[hydrophilic]

64 mode... what's that?

I haven't tried it, but since it's in the same register as the FAST mode bit (known to work in 64 mode), it should.

[nikoniko]

So, when will you release a VICE patch that supports your demo?

[hydrophilic]

If the developement time of 2MH in VICE is any indication, I would say several years.    

I won't pretend to be qualified to patch VIC (or VDC) video routines, and if even if I were, this is still experimental -- I'm not sure which (if any) of the several methods the program uses is reliable for interlace kludging.  The Atari 2600 which inspired me allows precise control of the start and stop of v-sync and v-blank resulting in a reliable interlace.  My method for VIC, hower, basically cuts half a raster to fake the 2nd field and isn't reliable... that's why there's several presets to experiment with and even an 'advanced' editor.

Looking at more NTSC documentation today and reading about the TIA (the Atari 2600 video chip) specs has got me thinking again... it seems some of my conclusions were wrong... anywho I'll continue experimenting and maybe somebody else will come up with the perfect solution first.

[nikoniko]

Hey, even if it's not perfect, at least you've found a starting point for further exploration. I don't think any of the various tweaked displays the VIC II became famous for sprang up fully formed at once... it took a good amount of study and experimentation to get there, so this is still a huge development that you've put together. I hope you don't mind that I gave the demo sceners a heads up about your accomplishment. I don't think it matters that you don't have any catchy music and dancing logos in your demonstration, as the technique itself is very interesting. And some of those people sleep, eat and breathe rasters, so perhaps between you and them a stable, reliable video mode can be pulled together.

Frankly, your effort appeals to me a lot more than any other tricks I've seen done with the VIC,  as I can picture it having usefulness in real applications and games, sort of a middle ground between the advantages of the VIC and the VDC. And I think it's really cool that it requires a 128 to be realized. :-)

[nikoniko]

Oh, forgot to ask: are color attributes shared between the two graphic screens or separate?

Do you think the technique can be adapted for text modes as well? (Would be interesting designing character sets for that, eh? )

[hydrophilic]

They are seperate.

Text mode works fine if you want 8x16 characters.  If you want 8x8 characters, you'll need an interrupt routine to force a bad line every 4th raster in the text region.  The interrupt routine would also need to switch text screens half-way down the screen.  The 'text screen' in my demo uses 8x8 characters but is really a bitmap.

Update
To see if my video mode was a fluke of my TV, I connected my Commie to my PC's video capture. Well interlace works on my capture card too.

Below are some screen shots.  I have to apologize for the quality.  To begin with, the picture wasn't as good as on my TV (when I build an S-Video cable, I'll try again and see if it helps).  Then when I tried taking snapshots, the capture software wasn't grabbing both fields of the frame :mad:  I was able to capture the interlace for you folks by recording a video and then extracting frames from that.  But that introduces lossy MPEG compression (I think I used 7M/s).  Finally, for the web, the .BMPs were converted to GIF.  That shouldn't have caused any degragation.

Here's the 320x400 circle

And here's the 40x50 'text' screen showing the disk directory


I'm most disappointed with the text as its barely legible in that photo.  MUCH better on my TV.  There are some other phots and an updated description here.

I just thought of something.  I could transfer gobs of data really fast to my PC by encoding the data as a bitmap then reading from the PC with capture software.  Unfortunately gobs of data for the C128 isn't much for a PC.

Or how about encoding data in a wave file on the PC and then have the commie sample the audio?  Like a CD without the disk.  Commies are so much fun!

[Christian Johansson]

I haven't been here for a while (have bought a computer with Linux and tried to get into Linux instead). However, this seems really cool. I must read the referred page and the thread in detail when I get the time. That test bit seems really cool. It is used in Risen from Oblivion for creating more colors than 16 on a PAL screen as well.

[nikoniko]

I've put together a grayscale image for you if you want something else to try. Maybe it'll give you a more extreme test for flicker than less contrasty images. The archive contains two uncompressed Koalas to comprise one 160x400 picture, and a D64 with the same in case that's more convenient.

EDIT: Added a second image (not grayscale) to the archive since I was having fun playing around with conversion. Not great, but not bad.

EDIT2: Last one, I promise. A dithered black and white gradient in 320x400 (Doodle format). The two fields are very different as you can see below. Seems to me it might flicker terribly.

[hydrophilic]

Thanks, I'll try 'em.  They flicker on my non-interlaced 60Hz PC monitor!  In fact, I'd say they flicker more than my Commodore TV circle.  Should be interesting...

[nikoniko]

Yeah, the first two were just fun images, but a bit more contrasty than your previous demonstration screens. The last was the more serious test. It's a litte shimmery on my CRT too, so I'm curious what a TV would do with it. I think in normal 320x200 such a dither would produce some color artifacting, and I imagine it'd be worse with interlace.

I wasn't sure whether the even fields display first or the odd, but in all cases with my files the lines of the first image need to display above the lines of the second -- unless I screwed things up. Well, anyway, if it looks horrible, switch the order. And if it still looks bad, then chalk it up to my poor Timanthes skills. I did follow your directives about alternating odd and even dithering, so hopefully that helps.

Oh, and the wonky eye (and in some places, skin) colors on the Last Ninja pic are due to my conversion, not your TV. I thought they were kind of interesting nonetheless.

[Christian Johansson]

Now I've read your web page, hydrophilic. This sounds really interesting (but I can't see it since I don't have an NTSC C128). It would be interesting to combine this vertical interlace with techniques like IFLI to get even better picture quality.

[hydrophilic]

IFLI would be do-able but would probably have very bad flicker.  On my TV, the flicker is almost not visibile with interlace (30 Hz) and this is probably why normal IFLI is also OK (also 30 Hz).  But if you used IFLI and interlace, that would mean a complete image at only 15 Hz (NTSC) or 12.5 Hz (PAL).  It would probably drive people crazy looking at it...

I started on an improved demo that might work with PAL, and since I am developing it on my PC and VICE (later to be tested on the real C128), this version will have source code.  I have been busy with disk and data transfer issues lately, so I haven't finished it.  But since I'm waiting on some new hardware at the moment, now seems like a good time to finish it.

If I get it finsihed quickly, I'll spend some time to try out IFLI.

By the way, it should be noted that without IFLI, the interlaced mode has increased color resolution (?) 'naturally' although in a very inconvient way.  What I'm trying to say is a normal multi-color bitmap has 3 colors + background in a 4x8 cell, but with interlace, you have 6 colors + background in the same cell area (now 4x16).

Perhaps the way to go is normal FLI.  Normal FLI + real interlaced video.  Maybe this is waht you meant to begin with.

[nikoniko]

I agree, normal FLI sounds more reasonable. Also, I've read that some sort of color blending happens vertically on PAL systems, so the interlace you've created combined with normal FLI should have superior color possibilities, rendering IFLI obsolete.

Or you could compromise and do a hybrid... FLI on one field, IFLI on the other, thus ending up with the first field at 30/25Hz and the second at 15/12.5.

[Mathias Roslund]

I have a PAL C128 ready to try some interlacing once the new demo is finished.

[hydrophilic]

The new demo is ready for PAL testers!  The the full hyper-text mark-up is here and the download is here.  I would have had it for you sooner but me, my 1571, and some floppies had a fight

The new demo includes FLI in a new way for me: text mode!  It works different from the FLI in bitmap mode simply because text mode and bitmap mode are different.  That had a learning curve since the font needs to created in a special way due to the way FLI works -- plus it needs to be split into two fonts for even and odd fields.

The FLI should be easy to adapt to bitmap mode.

And the source code is included although it is quite ugly considering it is meant for demonstration / understanding / experimenting and not as an efficient method.  And also it is based off the code I originally wrote in the C128 ML Monitor so don't expect anything fantastic.

Note the PAL implementation is a complete guess based on the way interlace works in NTSC, some general PAL principles, and a bit of indirectly useful information from the VIC-II article by Christian Bauer.  So some experimentation may be needed.

Any comments from PAL users are encouraged!

[Mathias Roslund]

I've now managed to get my PAL C128 to display a true interlaced image on my 1084 monitor.

The default settings didn't work and just gave a flickering image with weird colors. Not the usual green, not gray, but some other annoying flickering mess Maybe something similar to the way Risen from Oblivion creates some completely new colors, but somewhat interlaced, producing some flickering mixed colors...

Anyway, I first decided to try to get the colors back to normal. I left the even field settings at the default and started changing the odd one. First increasing it without result, then decreasing it. These gave the usual green:

Raster: 298
Cycle: 60
Cut lines: 3

I then modified the even field settings until the circle started looking properly interlaced. I then tried to choose the values which gave the best possible image, and got these for the even field:

Raster: 300
Cycle: 48
Cut lines: 4

If I view the circle image with interlace disabled and switch between fields, it's obvious they both contain some lines one pixel from the upper and lower border. Enabling interlace and those become thinner and are clearly displayed on different lines. Hey, my C128 has got a 400 lines VIC display! Nice Reversing the odd/even fields make the circle look very "jagged", which again shows the interlace is working

Trying the 50 rows text screen. With interlace the 'e'-letters really look like 'e'-letters and are easy to read, without the interlace enabled, they just looks like some blobs

I also looked at the other images, and while the dither one flickers quite bad, it also clearly shows the interlace effect. The pixels get thinner when interlace is working properly and don't just flicker on/off as when it's not...

[hydrophilic]

I'm glad to hear it works on PAL too.  And thanks for the feedback about the correct rasters!!  I knew it would probably be a little off.  So it seems the even field should be 300 instead of 299... off by 1, how typical!

The odd field settings aren't much to worry about since the VIC makes them naturally (they just need to cut some lines to provide symetry while avoiding v-sync).

I plan to update the demo with correct PAL settings so it will work 'out-of-the-box'.  Before I do, can I ask you 3 questions:

1. Would you mind if I quoted some of your results in the documentation for this demo?
2. Could you check to see which Cycle values (besides 48) do work correctly?
3. When the circle is correct, are the fields 'normal' or 'reversed' ?

Regarding 2: On my TV, a correct interlace only happens with a Cycle between 22 and 36 but you used a Cycle of 48.  We may never know if this is due to your monitor or the PAL VIC chip itself, but it sure makes me curious.  For NTSC (my TV anyway) the Cycle is flexible enough that a cycle-exact interrupt is not even neccessary, it would be nice if this is true for PAL too.

Regarding 3: On the menu screen it will say "R to Reverse to fields" if they are 'normal' but will say "R to Reset fields" if they are 'reversed'.  Sorry if that sounds confusing!

Anyway, thanks again!

[Mathias Roslund]

Some more information. With the default settings of the demo, if I reverse the fields, I actually get an interlaced image, but with weird colors.

1. Feel free to quote them :-)
2&3. Ok, some more figures:

Odd as 298, 60, 3
Even reversed: 300, 21-26 (best: 23), 4
Even normal: 300, 44-48 (best: 46), 4

Odd as 299, 26, 4
Even normal: 300, 9-11 (best: 9), 3

Certain other cycle values will give an interlaced but very unsteady (shaking) image. The values above are the one giving a quite stable but still clearly interlaced image. For the first example, if I go further than cycle 26, the interlace effect fades away. It's almost like the cycle will decide the amount of interlace effect, from full (the "best" values) to non at all. Also, only certian cycle values will give the correct colors, most give some weird colors and a few a completely gray image.

Don't know if you've read this about PAL encoding and the Risen from Oblivion demo:

The new colors work because of the PAL color encoding: The color carrier consists of U (blue-yellow color distance) and V (red-cyan color distance) which are simply added together, so C = U + V. Now, because a decoder needs to seperate U and V again, the inventors of PAL used a simple trick: They inverted the sign of V every 2nd rasterline, so you always have C = U + V followed by C = U - V. This way you can simply take the color carrier of the previous rasterline and add or subtract the current rasterline with it. If you add both carriers you get back U, and if you subtract you get V or -V. Now, if you skip an odd number of rasterlines, you get -V where normally would be +V and you get +V where normally would be -V. -> The red-cyan color distance gets inverted.

http://noname.c64.org/csdb/release/?id=2942

[Mathias Roslund]

I should probably try the demo with my TV (29" Sony CRT) some day...

[hydrophilic]

Thanks for providing some more results   I've updated the web page with some of the information you've provided and given you credit for the info.  I still need to update that PAL figure and the demo itself but anyway...

I find it interesting that the odd field needs to be set to start cutting on cycle 60, this means (with 3 cut rasters) that it will resume on cycle 60+3 = 63 which is really cycle 0 of the next raster.  That is it resumes (after the cut) exactly at the start of raster 302 which seems like the start of the equalization pulses (pre-v-sync).

So PAL or the 1084 itself is very sensitive to timing changes -- at least a lot more than my TV.  I wonder if the 1084's sync circuitry is analog?  That would explain some of it.  Hard to imagine for a computer monitor, but Commodore never ceases to amaze me!

Another interesting thing is you get reversed interlace with an even cycle of 21-26 or a normal interlace with an even cycle of 44-48, in both cases the same raster!  Very interesting... neither is near the center (approx. cycle 31) of the raster (the 1/2 mark) but instead at the 1/3 or 2/3 mark (approximately).

If you could try it on your TV, that would really shed some light.  Also, can you get an interlace image (on either display) if you set the odd field to use raster 297?

I don't mean to bother you with this, so it's fine if you don't want to do it.  Anyway, thanks again for all your feedback!

Update
After thinking about it, this makes sense due to the NTSC/PAL differences.

NTSC starts with even fields (and to be similar to BASIC graphic routines I number the rasters 0 to 399 from top to bottom).  On my TV, I get a correct interlaced image when the cycle is between 22 and 38.

AmiDog gets a reversed interlaced image when using a cycle of 23 on a 1084 monitor.  But PAL video starts with odd fields so that explains why the image is reversed.   So I need to change the program to automatically reverse the order for PAL.  In that case, the rasters should be called 1 to 400, IMHO.

In either case, the 'top' field bitmap is at $2000 and the 'bottom' at $a000.

[hydrophilic]

Sorry for double-posting but I wanted to be sure people were aware of this minor update for the documention.

I have updated the image for PAL v-sync diagram based on AmiDog's feedback and additional research on the WWW.



Unlike NTSC, which is 3, 3, 3 rasters for pre-, v-, and post-sync and unlike proper PAL which should be 2.5, 2.5, 2.5 rasters respectively, the diagram / theory is that PAL VIC produces 3, 2.5, 2.5 rasters respectively (I read somewhere that other PAL consoles like the Sony Playstation do this).

I was curious if anyone knows or has an opinion how VIC makes the PAL video v-sync ?

[airship]

I finally got around to downloading and checking out this demo. Hydrophilic, you ROCK! Your interlace mode is incredible! I never thought I'd see images that good on the VIC-II screen. (I'd love to see how it looks on a regular TV set, with the requisite smear and slow phosphors. Unfortunately, I no longer own a small set I can hook up to my C128.)

If this mode had been discovered back in the day (along with the hi-res graphics capabilities of the 64K VDC), the C128 would have remained a viable machine for years, and the C65 would have just been the first of many successors.

It's that good.