As a relic of the early 80s, the TRS-80 Color Computer couldn’t display very many colors. By default, the CoCo could only display 8 colors on the screen at a time, but [John] figured out a way to increase the number of colors displayed using a very simple trick that surprisingly isn’t found in original CoCo games.
The TRS-80 Color Computer uses a Motorola 6847 video display generator to produce color graphics on its display. There are several graphics modes available to CoCo programmers, including a high-resolution black and white mode, and two four-color modes using red, green, blue, and yellow or buff, cyan, magenta, and orange.
These color palettes are extremely limiting, and usually switching between these modes produces a lot of flicker. [John] figured out if he switched the color pallets every 1/60th of a second (i.e. during the vertical blanking interval), he could display 44 colors on the CoCo.
It’s a clever little hack to increase the color palette of the CoCo, and in our opinion should be in the running for winning this season’s Retrochallenge. Sadly, [John] is judge for the Retrochallenge this time around, so he’ll have to settle for earning a Hackaday merit badge.
This technique is used at least on the C64, both in old commercial games and demos. As long as you’re careful about which colours you’re blending the results can be quite impressive.
The Atari 800 was king of this particular hill, with it’s 16 hue and 16 shade modes able to be interlaced together, 256 colour images looked pretty good, if a little blocky by today’s standards. http://www.youtube.com/watch?v=pfz-e7iwJTM
http://www.youtube.com/watch?v=e-ZbgXolZQs
I wish I still had mine!
I missed out my compliments to John for what he has achieved with this on the CoCo, not just my Atari trumpet blowing (we all had our favourites back then!). Without luminosity control it is very much harder to get good results and he has done alot more than just flip the mode.
Jay Miner was a genius at designing minimal hardware that performed beyond what others thought it could do. This design acumen came in VERY handy when he designed the Amiga hardware.
Absolutely! If you didn’t follow what had happened behind the scenes, many might have found it odd that the natural upgrade path for Atari 8 bit programming fans was not to buy an ST, but to jump ship to Commodore and get an Amiga!
What? No assembler source? I have two original CoCos the 64k coco2 and 128k CoCo3 and even an emulator and he doesn’t give the source. Drat! Guess I will just need to figure it out on my own.
Is this on a CoCo2. If not this isn’t very impressive. A CoCo3 can do a 256 color image easy with its 16 color pallet which is customizable.
The CoCo2 is the one which can only do 4 colors at a time.
Dude, read the blog before making accusations…or at least learn what ‘git’ is…
And yes, duh, of course it is not a CoCo3 — those have a GIME, not a 6847… In fact the pictures in the display are from a TDP-100, which is a Tandy-produced clone of the CoCo1 which was sold in stores other than Radio Shack “back in the day”.
I know what git is and I use it all the time. The git link was under the post “Retrochallenge Wrap-up” and as I wasn’t interested in the challenge which this project wasn’t even a part of.
No need to be hostile. I enjoyed reading the blog and seeing your steps and was disappointed when I didn’t see any links to downloads. Thanks for pointing out the git address I missed.
As far as my thoughts about the CoCo1 or 2 vs. CoCo3, it was more the HaD article which was lacking. I didn’t mean for it to sound like an accusation. It wasn’t hard to deduce from the HaD article that the CoCo in question wasn’t a 3.
why so negative, why assuming the worst? having bad day?
as mentioned, the source *is* provided. the machine *is* one of those traditionally limited to only 4 colors (in gfx modes, semigfx can do more).
I’ll argue that the Apple //gs was the king of this hill. With horizontal blanking interrupts used to swap 16 color palettes on the fly, 3200 colors were possible. That felt photorealistic back then, even with the limited resolution. Of course, it took around 75% of the CPU to maintain this, so it was generally only used sparingly, or for splash screens, and paint programs. The demo scene loved it, of course, and did some incredible things with it. Combined with the overscan color setting, it was possible to render graphics outside the actual pixel area of the monitor. Google FTA’s XMAS demo for the high point of this art.
Sorry, but that was a 16 bit machine and quite late to the party! You can’t compare apples and oranges you know! It was a good system though.
If we’re talking 16-bit the Amiga could do palette swapping tricks with zero CPU usage. The ‘copper’ graphics coprocessor was perfect for this.
Well, I was only arguing that the //gs was the best at this precise trick (using video interrupts to swap palettes), not that it was a better computer.
Compared to its immediate peers, the //gs was woefully inadequate, in fact. Jobs made sure of that, so as not to cannibalize the Mac. The clock speed was arbitrarily low, and everything except the CPU core was 8-bit. Furthermore, video memory was accessed at 1Mhz, in order to maintain //e compatibility (though there were some tricks to get around that). I loved that machine, but I acknowledge it was measurably worse than its contemporaries. :)
I really hope my comment didn’t rekindle a 30yo platform war, because I never enjoyed those arguments. :)
I have fond memories of those platform wars – they reflect the diversity of choice and design that existed at the time. They also drove people to innovate on each platform so as to match or exceed another platform’s capability. Everything was moving fast and it made for exciting times. Many people buying a computer actually had a go at programming it, even if it was just to type in a BASIC listing from a magazine. And those who really got into it could still realistically hope to produce graphics on a par with commercial software in their garage, basement or bedroom. I feel old now! :)
I have fond memories of the platform diversity, but not the wars. Choices and innovation in the market: good. Teenagers screaming bloody murder at each other on BBSes over which machine could show more colors on a line: not so good. People have an amazing ability to take their technology choices personally.
I never experienced the BBS platform extremists you describe, but then I hardly had opportunity to experience BBS anything back then! I guess I just hung out with the right mild mannered local kids and our ‘war’ was far more measured and diplomatic. And then of course everyone knew an Atari 8 bit with a 1050 floppy was best at almost everything (or else)!
The EGA video adapter for PCs could put 64 colors on screen using this method but it was a bit flickery.
I only ever saw that done with a couple of static image demos, never encountered it being used in a game or other programs.
“pallets” -> “palettes”
The spelling of palette is actually very important if you did any BASIC on the CoCo3. It lets you specify what type of monitor you are using. ;)
The method is far more effective when you’re working with passive matrix LCDs, since the blurring compensates for the flicker. Take a look at the TI calculators, for example. People regularly use this method for 4 to 16 color greyscale on a B/W only LCD, and the only flickering comes from missing the 60 hz LCD update cycles.
FWIW:
coco 1980, EGA late 1984, Apple IIgs 1986.
C= Vic-20 1980, C64 1982
Well before the CoCo, Commodore 64, and even Atari 800 the original Apple II in the second motherboard revision (1978) could multiplex its colors to create a 21 color hires display.
I actually had the first motherboard but upgraded to add the (officially) 6 color hires mode. 21 colors was achieved through a similar method to this article.
Basically this method reinvents the wheel. Nice and certainly worthwhile, but it’s been done before.
“Nice and certainly worthwhile, but it’s been done before.”
Hence the line in the very first post in the blog that starts with “Another technique that others have used…” I don’t recall claiming to have invented this technique.
As for reinventing the wheel, I must have overlooked all the CoCo software making use of this technique previously…?
“As for reinventing the wheel, I must have overlooked all the CoCo software making use of this technique previously…?”
Here is a link to another person who has done this (The SockMaster).
http://www.axess.com/twilight/sock/hicolor/hicolor.html
He has a download of a .BAS ML loader program for a CoCo3.
I am not saying that I am unimpressed. I haven’t heard of it done on something other than a CoCo3 before. Good job.
I did this on the Atari 800 back in its day. Managed to get almost 1,000 colors on-screen simultaneously with minimum flicker, from a DAC only capable of producing 256.