Topic: VDC 480x252 8x1 colors - graphics converter

[tokra]

I've spent some time trying to hack together a graphics converter for this graphics mode I recently was able to get to display on the VDC. This is the first result:

The necessary steps for conversion (be aware this is in a very rough stage):
- find or cut a picture to a ratio of 480:506
- resize to 480:253 without aspect ratio correction (the aspect ratio will look weird now, but it will look as before when displayed)
- reduce color resolution to CGA-palette. You can use Photo Shop for this, I only have an old trial version of Paint Shop Pro. This process will create a lot of dithering. Photo Shop may have better options reducing dither in favor of choosing another color, which may look better in the end.
- save as binary .ppm (Portable Pixmap format) - filename: input.ppm
- use my first tool "pgm import128" on the C128 (or preferably VICE in Warp-Mode) to create a file output.vdc that just conists of a file with the color (0-15) for each pixel
- use the second tool "vdc import128" (again VICE in Warp-Mode) to create two files bitmap.v81 and colors.v81 - this does most of the work, counting the colors in each 8x1 block and assigning the most found color to background, and second-most to foreground color. Then it will check each pixel if it has a different color and assign it to either foreground or background depending on its brightness distance to both.
- the two created files can then be displayed on the real C128 (64K VDC RAM) with "vdc81view" - this will take some time (around 15 minutes) and the picture will be unstable until it has been fully loaded and the VDC is put into 8x1 color mode

I've uploaded all the tools, the CGA-palette file and the demo-picture above: Download

I realize the conversion method may not be the best possible and I would love for someone with more knowledge in graphics conversion to improve on it. There must be a better way than dithering to 16 colors and then throwing away colors that don't fit into the 8x1 scheme.

Comments?

[Hydrophilic]

Nice photo!  I've been meaning to try out the 8x1 mode, but have been busy with taxes (yet again), and I was worried that it wouldn't display on my TV as from my understanding of previous post, you can't get true 80-column display... only about 60 columns...
 
Looking at your photo and the size specification of 480x506 (or rather 480x253) tends to confirm this theory.  Of course this does not mean it would not work on my TV... but it seems less likely...
 
Anyway, seeing your photo along with all the work you did to put together a download for us has renewed my motivation...
 
So my only question right now is... the actual image is 480x253 right?  Being way taller than 200 rasters would explain why the image goes from top to bottom on your montior.  And a related question (so that makes 2)... so when you say to start with 480x506 and resize to 480x253, this just 'pre-compensates' for the fact of VDC pixels being about half as wide as they are tall (so called 'pixel aspect ratio' of 1:2) ?
 
Sorry that second question is bit difficult to ask... I'll understand if you have trouble answering it!
 
If the video mode will work on my TV, then I still won't be able to view your image because I only have 16k VRAM.  But I was thinking a half-height image like 480x120 might work...
 
Anyway, nice job and thanks for sharing!

[tokra]

Thanks for your comments. Yes, the picture is 480x253 - actually I think though the last line isn't displayed correctly, which is why I will probably fix this to 480x252 in the next version. This would lead to a nice 40:21 ratio as well.

And, yes, the fact that I take images of 480x506 is exactly to compensate for the pixel-ratio. In fact, if interlace was possible in this mode there would be no pre-compensation needed. However my experiments with interlace in 8x1 mode were unsuccessful, producing some VERY strang results.

The mode may just work on TV. The 60 chars displayed horizontally should be no problem, since I don't touch register 0. The vertical resolution should be 512 rasters, since I set register 4 to 255. This MIGHT just be recognized as NTSC depending on the tolerance of your display. To get real NTSC one would need a value of 261 in register 4. Another trick might be to switch to back to 8x2 mode at the exact right time on the display so that it will come out to 525 rasters. This may be what Risen from Oblivion is doing. However implementing a stable raster interrupt on the VDC opens a whole new can of worms, like measuring how fast your specific VDC chip is and setting the timers correctly and so on.

To get half a picture displayed on the 16K VDC all you will probably need to change is reducing the value of register 20 to 31 and adding 8192 instead of 16384 when writing the attributes to RAM. Oh, and you need to display only half the y-lines of course, so the video RAM won't overwrite the attribute RAM.

Or just increase your VDC RAM to 64K ;-)

[airship]

HP, for goodness sake buy yourself an upgrade board on the eBays - you can get one for about $40! If you can't afford that, we'll take up a collection, but surely your babbies can do without food for a couple of days, can't they? 

[Hydrophilic]

I bought RAM for my VDC some time ago, just haven't installed it yet.
 
I tried the original demo which only draws random lines and should work with 16k VRAM, but the screen just bounces horribly... must be too far out of sync with NTSC specs for my TV ?  I tried several modifications but never could get a stable image...
 
While looking at the latest code in VICE, I found just a few changes needed to get an image in VICE.  Then I made a few more changes to generate a 480x136 image that would fit in 16k VRAM.  Unfortunately, VICE deosn't work like the real VDC.  Actually, I wish the VDC would work more like VICE, because the VDC is just screwy...
 
Anyway, playing around on the real machine, I see why 8x1 mode isn't normally used... because the VDC seems to be stupid and forgets to generate vertical syncs after the 1st frame...
 
I was wondering what that ML part of the program was doing... after the 1st vertical sync, it changes the char cell size to a 'normal' value (taller than 1 raster) and then immediately changes it back to the desired 1-raster height.  This action kicks the VDC in the head so it will 'remember' to generate a vertical sync at the end of the 2nd (etc.) frame(s).
 
When I say the VDC fails to generate vertical syncs, it may be that it never turns off the vertical sync!  I don't really know because I don't have an o-scope to check the actual voltage output... but I do know the 'vertical retrace flag' (bit 5 of $d600) quits working and the screen turns a solid color (the VDC background color, default black).
 
Anyway, the 'reset trick' messes up the pointers, which explains why the attributes need to start 1 row (60 chars) early.
 
But what I still don't understand, is why the bitmap needs to start 34 rows (34*60=2040 bytes) early.  I could understand 1 row (1 raster) when the code triggers... I could even understand 8 rows because in the 'reset sequence' the cell height is temporarily changed to 8... but 34 rows ?
 
I also discovered that vertical total adjust (register 5) must be less or equal to register 9 (cell height-1).  If not, the VDC seems to forget to generate vertical syncs... the same as if you set 8x1 cell size without the 'reset trick' used in tokra's code...
 
See, I was thinking tokra's code was generating a total of 256 rasters, so I was trying to add another 6 or 7 to get a total of 262 or 263... but with 1-raster tall cells, the vertical total adjust must be less or equal to 0... which means it must be 0.  So it seems if your TV/monitor won't sync to 256 rasters then it just won't work...
 
Because 34 rows seem to get added by the 'reset trick', perhaps the VDC is really trying to show 253+34 = 287 rasters ?  Which would mean we need a vertical adjust of -25 for NTSC or +25 for PAL (ooh that's kind of weird) but only the value of 0 is possible...
 
Anyway, I tried playing around with the register settings from tokra's 480x253 code and also from my 480x136 code but never got a stable image.  The one thing I didn't try is to play with the actual 'reset' code... anybody care to guess how it works ?
 

[tokra]

Thanks for your experiments. I've just tried displaying the mode on my projector, thinking it would be recognized as NTSC. To my surprise I got a stable image, but it was recognized as PAL, so it must be closer to 312 line (625 rasters) than to 262...  Very strange indeed.

Regarding the displaying of the mode itself, I just created the ML-routine from scratch taking the hints from this post, which I referred to in my initial post as well.

I don't take any care of the numbers of rasters though contrary to what the post recommends. I presume it must be possible to create a stable raster-interrupt on the VDC (Risen from Olivision-style by counting rasters) and then switching to 8x1 just on a single defined area, so you can make sure that in the end it will come out to the desired total number of rasters (312 or 264). There would be a lot more work involved in this, setting up the raster-routine, calculating the right switch point and register settings (you need to change registers 4,5,6 and 9 at least for the switched area).

Ideally this mode is displayed on an original Commodore Monitor like the 1901 or 1902 possibly. These can adjust the vertical sync. Maybe the 1084(S) would work as well.

In other news: Mike from the Denial-forum was nice enough to update a converter he did for a VIC-20 graphics mode we thought up a while back to this VDC-mode. This does a much nicer conversion by quantising the 8x1 field-colors by brute force (=120 color combinations per field). I hope you agree the result is a big improvement, much less blockiness, the 8x1 fields are hardly noticeable.

[Hydrophilic]

Yes, it does look much better.  When I got the image to display in VICE, I thought the dithering could be improved, but never got that far with my real hardware.  The VICE image is way off from your photo, so it really is neccessary to use real hardware.
 
Thanks for the link to the original post describing the 'reset trick'. This I pretty much figured out.  However, at the end it says,

... At the end of the display area you have to set it back to 8x2 again. Now you have to make sure that there are still 263 or 312 rasterlines displayed in total, and you are done.

That last part is the tricky part!  I see how it would add 1 extra row of attributes, but no clue why it seems to add 34 extra rows of bitmap pixels (rasters).
 
My TV seems to allow some fudging of vertical... so I was supprised it would not generate an NTSC-like image from 256 (or 253) rasters... because of the +34, I was thinking the VDC might be generating more like 287 rasters.  Which would explain my terribly bouncy display.  The fact your projector sees the image as PAL also tends to confirm this...
 
So, I'll play around with the 'reset trick' to see if I can make my TV happy... I would like to see how some of my own pictures show up... anyway, good job with the new image!

[Hydrophilic]

The more I mess with the VDC, the less I understand it!
 
So previously I couldn't get a stable image on NTSC TV because there seems to be too many rasters generated by 480x253 program.  Based on register settings, I guessed that VDC was generating 255 + 4*8 + 2 = 289 rasters, which is quite a bit more than NTSC specs...
 
The 4*8 factor comes (mainly) from the fact that during the 'kick the VDC in the head' routine ('reset trick' for short), as originally written by tokra, would temporarily switch from desired 8x1 cell size to standard 8x8 cell size...
 
So I thought to get fewer rasters, we could switch to 8x2 instead of 8x8... which would in theory generate 255+4*2+2 = 265 rasters... migthy close to NTSC...
 
So I re-ran the original demo by tokra that just draws 'random lines' and to my delight I got a stable image.  Unfortunately the screen itself was a bunch of 'junk'... most likely due to the fact that I only have 16k VRAM.
 
Tokra, if you're reading this, the only change thus far was to change 1 byte in the assembly code... LDA #$E7 --> LDA #$E1... you might try that and see if you're projector will recognize it as NTSC... of course this might cause a need to tweak some other registers.
 
Along the same lines, you should see if other PAL users (not using a CBM monitor) get a good PAL image with your current settings.  If not, it might be that you need to add some rasters and you could try changing LDA #$E7 --> LDA #$EC ... according to my theory this should generate about 255 + 4*13 + 2 = 309 rasters...
 
Of course it just a (real bad) theory and have no way to confirm it without some hardware like an o-scope or data recorder... well, might could use a CIA timer along with VDC v.sync bit for a software guess...
 
Anyway, with a stable NTSC image, I tried my version modified for 16k VRAM.  The initial result is in Photo 1 ('480x136dumb').  As you can see there is a bunch of garbage at the top and bottom of the screen, and the main image looks terrible...
 
It looks so bad because the pixel data is WAY mis-aligned from the color data.  The color data, for reasons yet unknown, has to be offset by 2 rasters (-120 bytes) instead of 1 raster as in tokra's original code.
 
But the bitmap data has to be offset by 152 rasters (-9120 bytes)!  Took quite a while to figure that out... probably would have been faster to install those 64k RAM chips!  Anyway, you can see the result in Photo 2 ('480x136blur').  Now the image in the center looks pretty good, but there is still garbage at the top and bottom of the screen... the 'garbage' (especially at the bottom) has a neat psychodelic look, I think...
 
Anyway, I don't know why the offset of 152 rasters is needed.    The vertical sync position is set at 180... which should be 180 rasters after the first bitmap raster... which should leave 180-136 = 44 rasters below the bitmap... and 265-180 = 85 rasters above the bitmap... neither number is close to 152.  The total border should be about 265-136 = 129 which isn't very close either...
 
I imagine if you change the vertical sync position, the bitmap offset would change while the color offset would remain the same... I was so happy to get the bitmap aligned with the color, I didn't bother to do any experiments...
 
Leaving that mystery aside, the final thing is to remove that garbage.  As should obvious from photo 2, the color just repeats itself below the bottom of the image.  So I just 'blacked out' the last raster (thus having only 135 usable rasters) and the result was...
 
Nothing... still garbage at the top and bottom!  You VDC you 
 
So I 'blacked out' the next-to-last raster, (thus only 134 usable rasters) and finally the garbage at the bottom was gone.  Also some of the garbage at the top was gone... but not all of it!  You VDC you 
 
So maybe I need to black-out the top raster (raster 0) ?  Well, I tried this but it didn't remove any garbage ... it did remove the first 'proper' raster...
 
Okay, so I blacked-out raster -1 ... note this not further reduce the usable rasters because this actually comes out of the last raster already blanked... and, dumb , dumb , dumb ...
 
Still garbage at the top!  You... you... pesky VDC 
 
So I blacked-out raster -2, which also does not reduce the usable rasters because this actually comes from the next-to-last raster already blanked...
 
Finally, all the garbage is gone and we're left with a nice image.  480x134 fixed instead of 480x136 like it should be if the VDC weren't a piece of silicon.  See the last photo.
 
Well, I was too tired after all that to try making my own image(s).  I add some ML code to load the images into VRAM so now loading an image takes just a few seconds.  I put the ML and BASIC progs in a zip for anybody interested.  It was tested on a 16K VRAM machine.  For 64k VRAM, I think you would need to set the RAM size register to the correct value like tokra's original code and you may need to recalculate the bitmap address... remember its a negative offset but I 'poked' a positive value relative to the end of 16K VRAM...  But if you have 64k VRAM, might as well use tokra's "full size" version, right?
 
Anyway, you can ask if you have any questions.

[tokra]

Ok, I've made the change you suggested switching just to $e1 instead of to$e7 in the VBLANK-area. This produces an image that my projector will STILL favor as PAL. I've checked the projector setting and I can manually switch it to either NTSC/PAL, circumventing auto-detection. I still get a stable image when choosing NTSC. So I suppose the "$e1 switch"-mode must be somewhere in the middle with my projector favoring PAL. I've also checked the (original) $e7 setting, which only produces a rolling picture when I choose NTSC.

What you COULD do to find out how many raster-lines a picture is using is setting up a CIA-timer to conicide with the VBLANK-bit and counting the cycles. You do this first for a setting of which you KNOW how many rasterlines it has to determine the time YOUR specific VDC will need for a rasterline (standard C128 setting). That's in fact what Risen from Oblivion does at the beginning. Then try all the different modes available and see how many cycles (= lines) they take. Then find a setting that is close enough to or even exactly PAL or NTSC. Or even switch register 9 at exactly the right place to produce the desired number of lines.

Definitely very interesting, but a little over my ML-capabilities for now. For now I'll play around with the converter a little more, maybe post a polished version on CSDB to make more people aware of this and able to try it out on live machines.

[Hydrophilic]

I've finally made my own images in the 8x1 video mode.  These are reduced vertically to 480x134 because I only have 16kVRAM.  It should run on 64K VRAM machine, but who knows with the crazy VDC...
 
I re-wrote the video encoder for Media Player 128 to generate the images.  When I first wrote the encoder, I thought it was very generic as would support multiple image sizes...
 
But thanks to tokra and 8x1 mode, I've discovered my software was not very generic at all!  It was hard-coded for VIC-II cell height of 8 rasters, and 40 x 25 cells output.  Of course it was also hard-coded for VIC-II palette.
 
Anyway, thanks to tokra's new mode, I was forced to re-write my software and learned a lot in the process.  In the following posts are some of the images I created, and there is also a .D64 with all the images and viewer software in the final post.
 
Today's theme: "Britney & Vehicles"
 
The first is Britney on a motor cycle.  The color is obviously not calibrated correctly on my camera, because the background appears red on my TV, but is more orange in the photo...

[Hydrophilic]

Here are 2 images of Britney on a submerged car.  Unfortunately, neither turned out as nice as Hydro hoped.  You could blame this on my software, or on the VDC itself.  But if you've seen the video "My Prerogative", then I think you should agree the blame goes to the director of the video... the lighting is terrible!
 

[Hydrophilic]

And finally we have Britney in a plane.  I think this one looks the best.  Mostly because the source video was very well done.  Now if only I could get my VIC-II videos to look half this good...
 
Also attached is a D64 with the 480x134 viewer which will work on real machine using either 16K or 64K VRAM.  The D64 includes all the latest images shown here today.
 
The D64 also has a special VICE viewer.  The VICE viewer let's you view the images in older versions of VICE.  The real C128 software will not run in the newest or any old versions of VICE.  However the VICE viewer will run on VICE versions v1.6 up to v2.1.  I don't know about v2.2.  I do know the colors are all messed up in the newest v2.3 ... go figure...
 
I also wanted to ask anybody who has run this software (or tokra's 480x253 viewer) on a real C128... do any of the pixels flicker??
 
This is not interlace mode (see tokra's seperate 8x2 interlace mode), but on my C128, some of the colors flicker while viewing them.  Now this could just be my S-Video converter... but that is a little hard to believe because the result is not consistant.
 
For example, I noticed that dark cyan will flicker whenever there are "high frequency" pixels.  But I don't think this is a problem with Intensity channel because other dark colors do not flicker.  I also do not think it is a problem with the Blue channel, because other shades of blue do not flicker.  Also, bright cyan does not flicker... only dark cyan... and only where there are 'high frequency' pixels (a sequence of cyan,black,cyan,black...).  Anbody else experience this issue ?
 
On a different but slightly related issue, I noticed that if you write files to the FAT file system (as opposed to D64 disk image), the uIEC will have filename issues due to case-sensitivity depending on which operating system you use.  For example, I used my file converter in Windows 98 to generate some images and save them to an SD card... and then used Windows XP to generate some more images using the same software and same SD card... but they ended in different cases on SD card!!  Who know what would happen if you were to write files using a Mac or Linux!
 
Anyway, the viewer program will try both upper and lower case for the file extension.  And you can view the directory (to check the case of the main filename) by typing $ when it asks for filename.
 
Edit
Silly me, I almost forgot.  I thought that the 156-raster offset (very different from tokra's 480x253 viewer) had something to do with the vertical sync (register 7) because I needed to use a much different value than tokra.  But because I wasn't happy with the vertical centering, I changed register 7 and too my suprise, the 156-raster offset did not need to be changed...
 
So now I really have no idea how the VDC is generating this magic number... ideas anybody?

[tokra]

Just a quick reply. Attached please find Mike's converter for the 480x252 resolution. This should give you something to play with. I will create a more fleshed out package with demo-pictures soon. Oh, and I updated my second C128D to 64K RAM yesterday, only took about an hour to finish the job. And most of the time it took to loosen and tighten the screws of the integrated 1571 and cooler. If you have a flat C128 it should only take about 20 minutes total.

[tokra]

I've finally put together a proper release for this:

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