VIC 20 in Black and White mode

Mike · Post by **Mike** » Sun Nov 22, 2009 4:21 pm

Here we go. (download)

A +8K RAM expander is required. In the *.d64, just load and run the file BOOT, and there you go.

The demo loads a picture, waits for a key press, then starts the raster engine, and the remainder of the BASIC program sets up the tables for greyscale output. Finally, a second key press returns to the READY prompt.

Greyscale output is achieved by mixing green, and purple for a dark grey, light green and light purple for a light grey.

The raster engine splits the auxiliary colour register off-screen, and the background/border register during flyback (to provide for the next border colour), *and* at the left, and right edge of the display window! This now allows for a separate definition of the "border" colour within the image from the border colour itself (I could have made left, and right border different as well, but there's no real use in that). Two different tables are used on alternate frames.

Both PAL, and NTSC versions of the raster engine are provided. I'd very much appreciate feedback whether the result on a real NTSC VIC-20 is in order - I could only test within VICE.

For the adventurous ones, try SYS15104 after the program has returned to the READY prompt.

Greetings,

Michael

Edit (2019-10-18): uploaded a slightly improved version and reflected the changes in the post here.

Wilson · Post by **Wilson** » Sun Nov 22, 2009 6:41 pm

Mike, you are incredible! MINIGRAFIK is truly a product of pure brilliance. Well done!

carlsson · Post by **carlsson** » Mon Nov 23, 2009 1:49 am

I would test on my NTSC VIC-20 if it wasn't for the fact neither of my TVs or monitors can produce a colour image to start with, so the image is already grey scale. Well, my PC video capture card does NTSC in colour so perhaps I can test it that way...

saehn · Post by **saehn** » Mon Nov 23, 2009 9:16 am

WOW! I will test on my NTSC VIC-20 tonight. Very impressive, Mike!

orion70 · Post by **orion70** » Mon Nov 23, 2009 9:51 am

Wilson wrote:Mike, you are incredible! MINIGRAFIK is truly a product of pure brilliance. Well done!

Quote

.

carlsson · Post by **carlsson** » Mon Nov 23, 2009 1:52 pm

It looks nice, but it helps if the user turns down colour saturation a bit on the monitor. I like the screen you get after SYS 16384 too. The dark cyan is a nice touch.

Interestingly it seems to flicker less on NTSC than PAL, or maybe it is due to I can only get B&W image from my NTSC VIC-20. It could also be a matter of each VIC has its own kind of video output, which we kind of already knew.

Mike · Post by **Mike** » Mon Nov 23, 2009 2:40 pm

carlsson wrote:It looks nice, but it helps if the user turns down colour saturation a bit on the monitor.

Some people are more sensitive to colour flicker than others. It's the same matter with video beamers, where a red, green, and blue image are projected.

I like the screen you get after SYS 16384 too. The dark cyan is a nice touch.

That should be the same light grey as in the image ... ? Maybe the yellow border contrasts to the grey, and fools one into seeing cyan as complementary colour.

I more meant to try it because of the timing issues. Both normal text screen, and MINIGRAFIK screen are supposed to be centered, but the raster engine takes its timings from the bitmap screen. Therefore the "outer" border colour definition should extend one whole character into the text screen on both sides (20 vs. 22 columns). Likewise, the effect should start 4 raster lines earlier, and end 4 lines later than the text screen (24 vs. 23 rows). And, of course, BASIC still can be used, the program listed, etc.

Interestingly it seems to flicker less on NTSC than PAL, [...]

Well, NTSC has an already higher frame rate to begin with. 60 Hz vs. 50 Hz give a noticable difference.

...

This kind of programs is highly sensitive to emulator issues:

In VICE 1.16 (that's the version I still mostly use), the effect stops working (even though it doesn't crash the VIC) after - in PAL - ~65 minutes. In that time, 2^32 machine cycles pass. Then, the emulated VIC and VIA chip suddenly get out of sync! While I didn't really expect something like that to happen, I had added a check within the IRQ server, whether the delay between IRQ and the entry into the IRQ routine was outside a sensible range - and then the effect is disabled.

The newest VICE beta has yet another problem. Here, the splits don't anymore happen on character boundaries, or in the half of each character, but somewhere else.

carlsson · Post by **carlsson** » Mon Nov 23, 2009 3:35 pm

Hm, am I seeing colours that are not supposed to exist?

Sorry for the poor sharpness. I really need to get myself a better PAL VIC-20 since internal adjustment or replacing the 6561 did no difference. Actually I have at least one more loose VIC with better image but it doesn't load from disk (Ruud suggested replacing the 7406 next to the 6522 but I haven't got to that yet).

Mike · Post by **Mike** » Mon Nov 23, 2009 4:05 pm

Thank you for the picture!

Indeed, I had only VICE available at the moment ...

You might be onto something. Even without colour interlace in place (cyan and light red exchanged between even and odd rasters every frame, same with purple and green), many colours already show up slightly different on even, and odd lines. That might be exaberated if only even, and/or odd lines of one colour are shown.

Mike wrote:The newest VICE beta has yet another problem. Here, the splits don't anymore happen on character boundaries, or in the half of each character, but somewhere else.

I must confess, "problem". The timing on your PAL VIC also is shifted slightly to the right. Darn. There go my plans using horizontal raster splits to create the Archon board, or the like.

The raster engine already is timed out to one machine cycle. I truly expected them to obey the character boundaries. How am I supposed to shift the timing 1 or 2 pixels to the left again? Do other VIC-20's show the same timing?

Looking sharper, the text screen indeed shows, that border and background colour vs. the reverse video bit are not updated within the VIC chip at the same time!! At first the border/background colour are changed, (not quite) obeying the character boundary; and then 1 or 2 pixels later, the reverse video bit (one machine cycle are 4 pixels). Indeed good food for thought for the VICE team ...

Finally, the version at the bottom left had been most probably exposed too short, showing only one of the two alternate frames.

...

I really must get my VIC out of the closet.

Final Edit: The VICE 2.1.16 beta indeed shows the border/background change shifted by one pixel, and the reverse video bit change takes effect 2 pixels later! I had turned on reverse video by chance when I defined the outer border, with bit 3 clear. This is pretty close to carlsson's photos.

Maybe I can live with that 1 pixel offset ...

eslapion · Post by **eslapion** » Mon Nov 23, 2009 4:51 pm

Black and white in programming? Hummm... dunno.

The way that I know of disabling the color information is by disconnecting pin 2 of the 6560, possibly with a switch.

Disabling the color information has the added benefit of making the color appear as shades of grey on a much sharper display.

Mike · Post by **Mike** » Mon Nov 23, 2009 5:09 pm

eslapion wrote:The way that I know of disabling the color information is by disconnecting pin 2 of the 6560, possibly with a switch.

Yep. That's what I also suggested in one of my posts above. However, this would incur a hardware change, and make that VIC "nonstandard" - in the same way as those VIC's, which carry piggyback chips to fill $0400 .. $0FFF, making that memory also available to the VIC chip.

Disabling the color information has the added benefit of making the color appear as shades of grey on a much sharper display.

Granted. However, IMO Jeff just wanted to desaturate the colour display - he didn't expect a sharper display. I thought up a way by mixing complementary colours, both through raster line interlace, and time interlace.

That experiment showed up with - for me - unexpected and interesting internals about the VIC chip timing, which the VICE team now seemingly has the emulation got quite near to.

Mike · Post by **Mike** » Tue Nov 24, 2009 3:00 am

Hi, Shane!

Did you try out the program on your VIC? And could you provide a screenshot similar to carlsson's one?

Additionally to the question, how the image shows on NTSC VIC's, it would also be interesting to know, how the S-Video mod affects the display. The cross-hatch patterns tearing single pixels show up pretty badly on the photo.

Michael

carlsson · Post by **carlsson** » Tue Nov 24, 2009 3:32 am

I could take some pics of my NTSC display, but it would be B&W to start with. As mentioned I could use the video capture card but it only operates in lowres due to (??) my relatively weak 800 MHz Athlon.

Regarding the cross-hatch, I have at least one more 100% PAL VIC-20 which I could fish out and compare video output from.

tlr · Post by **tlr** » Tue Nov 24, 2009 11:55 am

Mike wrote:
Mike wrote:The newest VICE beta has yet another problem. Here, the splits don't anymore happen on character boundaries, or in the half of each character, but somewhere else.
I must confess, "problem". The timing on your PAL VIC also is shifted slightly to the right. Darn. There go my plans using horizontal raster splits to create the Archon board, or the like. The raster engine already is timed out to one machine cycle. I truly expected them to obey the character boundaries. How am I supposed to shift the timing 1 or 2 pixels to the left again? Do other VIC-20's show the same timing?

Looking sharper, the text screen indeed shows, that border and background colour vs. the reverse video bit are not updated within the VIC chip at the same time!! At first the border/background colour are changed, (not quite) obeying the character boundary; and then 1 or 2 pixels later, the reverse video bit (one machine cycle are 4 pixels). Indeed good food for thought for the VICE team ...

Changes to $900f and $900e colors appear 1 hires pixel late with respect to char (or half char) boundaries and changes to the reverse mode bit appear 3 hires pixels late.
This "anomaly" appears on both my 6561-101 and 6561E VICs.

Like you noted this is emulated correctly in the current VICE trunk. In the previous release it was only emulated correctly for cycles close to a char boundary, and not for half char boundaries.

nojoopa · Post by **nojoopa** » Wed Dec 02, 2009 12:02 pm

Mike wrote:In VICE 1.16 (that's the version I still mostly use), the effect stops working (even though it doesn't crash the VIC) after - in PAL - ~65 minutes. In that time, 2^32 machine cycles pass. Then, the emulated VIC and VIA chip suddenly get out of sync!

This bug was fixed in r21622 (between v2.1.18 and .19). As a sidenote, I'd really like to know why anyone would stick with such an old version of VICE

Anyway... neat concept, good work!