VIC 20 in Black and White mode

[tlr]

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]

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!

[Mike]

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

Oh, thanks!

Even though, the main effect isn't performed by MINIGRAFIK itself in that case. MINIGRAFIK really only employs the built-in no-frills display capabilities of the VIC chip, with easy access from BASIC. So it doesn't get in the way, if one wants to add raster bars.

And, as library with just ~1K size, it doesn't take away much memory from the programs that want to use it. Just showing raster bars or rectangles with the new colours without a nice picture would've been a bit boring, no?

As a sidenote, I'd really like to know why anyone would stick with such an old version of VICE.

As I already had written elsewhere, VICE after 1.16 suffered from creeping featurism. Lots of small improvements, sure, but also quite some show-stopper bugs (like freeze on RESTORE, etc.). With the recent versions, the project seems to be back on track.

[...], the effect stops working [...] after [...] ~65 minutes

This bug was fixed in r21622 (between v2.1.18 and .19).

That is good news. I'm eagerly waiting for VICE 2.2.

As a side note, last Saturday I hooked up my VIC-20 with Mega-Cart and uIEC/SD to load that Avril B&W demo. It used to work a few days earlier, but no matter how I tried the VIC returned ?SYNTAX ERROR when trying to run the second program in the load sequence. [...] I will try it again some day, perhaps transfer the D64 file again.

Could you resolve that issue in the meantime?

Greetings,

Michael

[PaulQ]

Of course, you could always just buy a black and white television .

Skip the B&W television and go for the old monochrome green Amdek monitors. Those were awesome. I actually used to use one of those on my Amiga 500 in the early 1990's on the composite out port for several months after my 1084 had an unfortunate accident. Even though I missed having color, I realized that the Amdek was quite a bit sharper than the 1084 and text was much crisper and easier to read.

I did the exact same thing for my Amiga 500, except I used a Samsung model SM-12SS31A6. I agree with you about the sharpness. I'd switch to it whenever I was BBSing, and used the 1084s as a television connected to my VCR. I loved that set-up.

I recall a program in Compute! for the Vic 20 that allowed it to generate what appeared to be a "Pulsating" text on a black and white TV by cycling through the colours as though they were shades of gray. I'll see if I can find it and post it up.

[Mike]

I recall a program in Compute! for the Vic 20 that allowed it to generate what appeared to be a "Pulsating" text on a black and white TV by cycling through the colours as though they were shades of gray. I'll see if I can find it and post it up.

Like this one?

Code: Select all

1 A$="{BLK,BLU,RED,PUR,GRN,CYN,YEL,WHT,YEL,CYN,GRN,PUR,RED,BLU}"
2 FORS=1TO14:PRINT"{HOME}"MID$(A$,S,1)"TEXT":FORT=1TO30:NEXT:NEXT:GOTO2

[carlsson]

Mike, I will try to load the program again. I just don't know when I will have my next VIC-20 session, hopefully some time before Christmas. The machine is setup and ready at my kitchen table, but it doesn't mean it is easier to find quality time to hang around with it.

Gee... imagine if I had a girlfriend sitting on my kitchen table, ready and waiting for me and I kept telling her I'm too busy to do more than look at her when passing by the table. I'm sure I'd be back to being single very quickly. Fortunately my VIC is a bit more forgiving for neglecting it for weeks.

[saehn]

Interesting. I just tried it tonight on my NTSC VIC-20 (old-style, sideways power switch, two-prong power supply). The "dark" grey is definitely grey, but the "light" grey is more purple than it is grey. No flicker is visible. Avril is still attractive, nonetheless.

[Mike]

I just tried it tonight on my NTSC VIC-20 (old-style, sideways power switch, two-prong power supply).

The photo also shows, that the NTSC 6560 also has the same 1 pixel delay as the PAL 6561 until a change in the background register becomes visible.

The "dark" grey is definitely grey, but the "light" grey is more purple than it is grey.

For light grey, cyan, and light red are mixed. Even though they are complementary colours with nearly the same luminance, they do have different saturations. This might be the cause the mixed colour isn't completely desaturated.

In total, with two different of the 16 available original colours, 120 new colours can be mixed. Some of them will flicker a lot (like white/black), but other combinations might be a better approximation of light grey.

...

I find it quite interesting, that the pixels in the photo seem to vary in size - some of them look as small as hires pixels. Is this a VIC-20, which has been modded with the S-Video hack?

Greetings,

Michael

[saehn]

For light grey, cyan, and light red are mixed. Even though they are complementary colours with nearly the same luminance, they do have different saturations. This might be the cause the mixed colour isn't completely desaturated. In total, with two different of the 16 available original colours, 120 new colours can be mixed. Some of them will flicker a lot (like white/black), but other combinations might be a better approximation of light grey.

That would be interesting, for graphics purposes. Maybe there would be some way for the user to cycle through the color combination after the picture has been drawn onscreen?

I find it quite interesting, that the pixels in the photo seem to vary in size - some of them look as small as hires pixels. Is this a VIC-20, which has been modded with the S-Video hack?

No, no S-video hack. I guess you're seeing a combination of the camera artifacts and TV blurring?

[Mike]

That would be interesting, for graphics purposes. Maybe there would be some way for the user to cycle through the color combination[s] after the picture has been drawn onscreen?

I could provide another demonstrator which displays two different bars of mixed colours - alongside information, which two base colours are mixed for each bar. f1, f3, and f5, f7 are supposed to cycle through the colours.

No, no S-video hack. I guess you're seeing a combination of the camera artifacts and TV blurring?

Indeed I had suspected your VIC is unmodded, and just wanted to be sure about it. I don't think there are camera artifacts involved here, besides the fact, that the lower half of the photo only shows one of the two different frames, with the four colours clearly visible.

Some months ago IsaacKuo wrote about a "subpixel" rendering method, which might appear in a variant here: In one post he mentioned, that in NTSC pixels jitter horizontally on alternate frames. Complementary colours behave in diametrically opposite ways, i.e. a vertical line of light red pixels might appear as:

Code: Select all

**       **
 **     **
**       **
 **, or **
**       **
 **     **

in odd (left), or even (right) frames, a cyan line shows exactly the other way round.

The Raster Engine now additionally not only changes the colour in every raster, but also exchanges the appearance of even, and odd lines in every frame! Ultimately this cancels out the jitter completely, as at a fixed x-coordinate only either the left or right pixel variant of both colours ever is shown - and so leads to even less flicker than normally is visible - at the "cost" of colours.

But this also means there might appear two different "versions" of the image, depending on which frame the raster engine was started, even or odd, with half wide pixels at different positions.

The above thoughts only apply to an unmodded NTSC VIC-20. With the S-Video mod in place I suppose all pixels are then the same width, but the colour mixing still works as intended.

[saehn]

But this also means there might appear two different "versions" of the image, depending on which frame the raster engine was started, even or odd, with half wide pixels at different positions.

DrazLace for the C64 does something like this in the editor... there are two "multicolor interlace" shifted locations, and you can toggle between them.

That's a PAL version that can be used with WinVICE, but I have a NTSC fixed version if you need it.

[Mike]

Ah, yes. The two Drazlace versions I know of do multicolour interlaced, optionally with X-Shifting. They use two bitmaps, but only two identical copies of the text-screen for colours 1 and 2, and the single colour RAM for colour 3.

But ultimately, this is quite different from the (interlaced) MG+RE display: that one still uses a single bitmap, but different background, auxiliary, "inner" border, and outer border colours each line, and for even/odd frames.

These two different versions of the displayed image, that I meant, I suppose to appear at random - depending on which type of frame the raster engine happened to start. I'd be interested if you could confirm that behaviour. There are some parts of the image that look like this:

Code: Select all

**....
....**
**....
....**
**....
....**

with '*' being light grey, and '.' being dark gray. When the program is restarted, they might appear like this:

Code: Select all

.**...
...**.
.**...
...**.
.**...
...**.

... which really doesn't alter the overall appearance of the image, but gives small changes in details.

The difference might not easily be noticable, and with the S-Video mod it shouldn't appear anymore. In any case, it can't easily be controlled from a program as there seems to be no provision to discern whether the VIC currently displays an even, or odd frame.

[carlsson]

My issue is solved. It was a classic case of ?OPERATOR ERROR the other week. I simply tried to load files in the wrong order, which of course does not work as intended. After loading MINIGRAFIK followed by RASTER DEMO which loads all the rest by itself, the demo runs as it should.

I wonder if I could blame the operator error on too much alcohol or a plain brain fart?