Greater than 16 colour demo on PCjr

[whitaker8088]

Hello, I have been playing with a bunch of ideas and one has been to generate more than 16 colours on the PCjr. I used to have a program in the 80s which would generate 256+ colours on the PCjr and I think it was from Compute! Magazine(at least I found something similar there on archive.org). So I decided to see if I could recreate something similar. It turns out, I don't think I have used the same mechanism as the original program especially if it was from Compute! Magazine as it uses 16 colours and pattern combinations to generate 256 colours. In this demo, I'm actually using the PCjr's ability to flip between multiple video pages.

Interestingly, after I basically got a sample working, I found out that someone else (cjmartin2; "85 Color Demo" ) had done something very similar on a Tandy TL about 10 years back. Oh well. So I have decided to post what I currently have and start looking at other possible ideas, instead.

Give it a spin (will work in both 128KB mode and with extra memory). It's not perfect nor did I completely polish it but I was surprised with the outcome.

If you're sensitive to flicker, maybe avoid this, however, I have strived to reduce any flicker as much as possible.

Later,

Steve

[Trixter]

Always happy to see people experimenting with the PCjr. To be 100% accurate, it might be 16*16 combinations, but there are only 136 unique combinations of those. Also, some of the combinations flicker quite badly (ie. color #0 then #15, etc.). In practice, I found there were between 32 and 48 usable combinations depending on the persistence of the monitor that was hooked up.

If you want to take this to the next level, hook up a composite color NTSC monitor to the composite output jack, then try some combinations in PCjr's 640x200 4-color mode. By using that mode, as well as selecting exactly what 4 colors are displayed via the palette registers, it is theoretically possible to get up to 3840 colors via 2-pixel combinations. The palette registers can be changed per scanline if your assembly code is fast enough. To date, nobody has created an image viewer for that mode...

[whitaker8088]

Thanks.

Correct, by my calculations, there are only 71 unique colours. That's why I state, "greater than 16". When I mentioned 256 that was in regards to the Compute! magazine article. Here's a link:

https://www.atarimagazines.com/compute/ ... C_PCjr.php

It seems that that article uses multiple methods to show a variety of on screen colours (16, 240, 256). Maybe their numbers were overestimated. I think a couple of the examples are similar to your suggestion of using 640x200 4 colour mode.

wrt composite, my intention was to avoid this. IMHO, composite NTSC artifacts end up generating lower resolution images and the colours are much less vibrant. As well I believe many people still use the PCjr 4863 monitor and I don't think have experienced seeing more than 16 colours on these. However, maybe 640x200 4 colour using two palettes might prove me wrong.

wrt flickering between colour extremes (eg 0 and 15), this is pretty much eliminated as I applied a checkerboard pattern between video pages. I originally waited for a vertical refresh before switching pages. This works reasonably well when running above 128KB but when running with only 128KB it caused major flicker. So when running under 128KB I don't wait for the refresh and it works much much better. Potentially the BIOS video page switch function itself is waiting for the refresh?

Thanks again

[Trixter]

Not sure how you came up with 71 colors? 16! = 16+15+14+13 etc. which gives 136 unique combinations.

You might get better mileage out of the checkerboard effect in 640x200 4-color mode, as a real PCjr monitor has such a fuzzy dot pitch that the pixels effectively blend together. However, there's switching the palette every line to deal with, and that also complicates the image converter greatly.

Noticed that you used an error diffusion dither; you might want to try an ordered dither instead to take advantage of any 2x2 patterns that might emerge: https://bisqwit.iki.fi/story/howto/dither/jy/

Waiting for vertical refresh should have worked fine without flicker regardless of running out of slow or fast RAM, but you can't use the BIOS to do that, you have to flip pages yourself manipulating the registers. The PCjr has a vertical retrace hardware interrupt; combined with that, you get rock-solid pageflipping.

[whitaker8088]

Yeah, I have no idea where I came up with 71 (it may have been unique colours for a particular image). But based on some sample code the number of unique combinations is most likely 85. As some colour combinations end up producing the sample result. I guess that's where the 85 colours for the Tandy demo came from. I did not go into gamma correction or anything as maybe that may change things.

FYI. here's four colour combinations which average to the same value:

Code: Select all

#555555(d grey)  + #555555(d grey) == #555555
#00AAAA(cyan)    + #AA0000(l grey) == #555555
#AA00AA(magenta) + #00AA00(green)  == #555555
#AAAAAA(l grey)  + #000000(black)  == #555555

The article you referenced looks interesting. I'll have to spend a little more time reading it in detail but it seemed to be more concerned with the effects of error dithering on animated sequences. As you probably guessed, I just used GIMP to do Floyd-Stienberg.

Yeah, I'm using the BIOS to flip pages (int(10),AH=5,AL=0x82,BH=page). Maybe that's not the proper way?

As always, good suggestions, I'll have to play with these ideas for my next experiments.

Thanks, Steve