[Coco] The myth of the Coco3 256 color mode :)

[jmlaw at iprimus.com.au]

Hey John,

>AFAIK, Jason Law discovered this independently around the end
>of 2009.  I saw the postings on coco3.com at that time and asked
>Jason for info about using the mode.  I used that info to produce
>my own slideshow stuff (somewhat similar to Joel Ewy's version).
>Since I was developing my coco video player at about that time,
>I also added support for that mode to the video player

I in no way discovered the CoCo 3 256 artifact colors, nor have I ever 
claimed that. Potatohead's (Doug Dingus of the Atari Age forums) post at 
coco3.com got Briza interested, who in-turn repeatedly asked me to help him 
figure out how to use it until I eventually stopped work on the 1&2 pixel 
horizontal scrolling project to see if, without a NTSC CoCo 3, I could be of 
any assistance. That's how I got involved in it. As part of that, I wrote a 
simple BASIC program that generated an on-screen palette containing blocks 
of byte values from 0-255. This was my best guess of how it may work, but 
that program went untested so I didn't know if my ideas were correct or not. 
Not having a go at anyone, just telling it how it was. Robert Gault (RG) was 
starting to play with palette values on the 640 screen and was also close. 
Potatohead (PH) posted not long after, re-explaining the basic principle 
with the palette values and how they can be set to produce a particular 
palette. PH was working with the Propellor micro-controller which apparently 
had a very similar composite video output to the CoCo 3. He had written a 
simple palette program to display the arifact colors, using blocks of byte 
values from 0-255. So this was the first vindication my best guess was 
correct. The palette values I'd not tried previously as I had no way to test 
their function on the artifacts without a NTSC CoCo 3. I'll have to update 
the facebook post where I detailed this for Glen B, I'd forgotten about this 
next part. PH had taken a screen capture of the Propeller output displaying 
his artifacts palette program. I had updated my BASIC program to the 640 
wide screen with the correct palette values and it too worked. But I 
originally used PH's captures to create a .pal file used by paint programs 
to set the 256 RGB index values of a palette used for such images. I did 
this by blurring the image capture to average the color per block to create 
a 256 RGB palette by color picking from each block. This gave a color 
representation for each index (0-255) that was close to that seen with the 
256 composite artifacts. For those who don't know, a 256 color bitmap 
doesn't store RGB values per pixel, but a byte value from (0-255) to 
reference the color to be used from the palette of 256 colors by that pixel. 
The RGB palette information is stored in the bitmap header, but as the 
artifact pixel colors are defined by their byte value, the header is not 
required (unless you wish to have the CoCo 3 do the conversion, as is the 
case with RG's bmp viewer). If you display the pixel data (0-255 values) 
from the bitmap image in video memory on the CoCo 3, these will closely 
replicate the RGB colors of the same index in the .pal file, but in 
composite. This depends how close the .pal file is to the CoCo 3 artifact 
colors. The colors are simply defined by how the composite display handles 
the bit patterns generated. If the tint is off in the capture, so will the 
.pal files be, and the converted color may not be the best color, as was the 
case originally, the NTSC tint was quite a ways off, but was a starting 
point. Later I updated the .pal files with captures of my palette program 
(much larger blocks) and PH adjusted his tint control for a more accurate 
color reference to what we see with the CoCo 3 artifacts. I've since redone 
them a 3rd time with a high quality capture device to make them even more 
accurate. I'd still like to do some fine tweaking of them before releasing 
them soon. RG created an ML palette program based on the block layout I 
used, with the option to display the byte values by column or row as PH's 
was by column and mine was by row :)

The history of who discovered the CoCo 3 256 composite artifacts first is 
vague at best. Potatohead had mentioned using it to generate fractal 
patterns back in the day. There were two articles in Rainbow that I found 
later and extracted, one of which is on tandycoco.com website. The other 
I'll have to dig through my coco files and see if I can find it. GrafExpress 
by Sundog Systems was probably the best indicator that this was useful in 
games/apps. Though just reading over the manual again today, it seems to 
indicate this method was known and had been used even before this program: 
(p45) "Note: This program, like any 256 color program, does not function on 
RGB monitors...". After I'd figured out a simple way to convert an existing 
RGB image to the artifacts, I sent an email to Sockmaster on the topic as he 
may have been interested re his work on the 256 RGB color project he and 
Nick had pursued. Sock's indicated he knew of it and had written a simple 
paint program back in the day. So others had known of it long before any of 
my work own on it.

As far as my discoveries, a simple way to convert and display an existing 
image to use the artifact colors, that requires no processing by the CoCo, 
but defintetly not the artifact colors themselves. As indicated in previous 
posts, I've continued the development and 'discovered' ways to apply the 
artifact colors to produce a half-byte scroll (half pixel in artifacts, 1 
pixel in 16 colors). Color shifting was the obvious problem here and 
toggling the burst phase invert during VSYNC to try to overcome that just 
lead to a color 'bleeding' issue as I suspected would be the case. I've 
'discovered' a simple way to overcome that. I'd also found a simple set of 
palettes of 1024 (actually more like ~993) different colors, 256 visibile at 
once without HSYNC interrupt tricks. I've since created a palette program 
that displays all of these colors simultaneously, using the fore mentioned 
trick. There's a few other bits and pieces that I'll mention when I create 
the webpage on this topic to detail what I have learned or 'discovered' :)

My apologies that the explanation is long, and probably still vague, but 
there is a lot to the initial development and hopefully it answers some of 
the questions others may have had.

>Since then I have discovered that Jason thinks that I tried to take
>credit for his work or at least that I failed to properly credit him.
>I presume that your video is the source of his angst, although I
>would refer people to watch it (esp. around the 2:48 mark) and judge
>for themselves.  At any rate, from forthwith please let the record
>show that Jason provided me with the info I initially used to support
>that mode in the programs mentioned above.

My issue with it John (and hypothetically if I was your best mate I'd say 
exactly the same) is that using someone else's work to greatly enhance your 
project without credit is unchivalrous. Maybe I'm the only one with the 
ideal of if you use someone else's work in your project, credit them for it, 
even if it's just a footnote. Though I seriously doubt I'd be alone on that. 
Personally, I would have considered it an unspoken code of conduct that 
people in a community like ours adhere to, not expecting too much am I? 
Maybe I am. If it was just some unnoticeable subroutine that did the same 
thing just a little bit faster or better that not a lot of work went into, 
I'd probably not be concerned but this was a major and obvious enhancement 
and contribution to your project for which you gave no credit, other than to 
say 'it's documented on coco3.com'. If you remember, at the time I was only 
sharing the palette files with those who wished to assist with the initial 
development and contribute to the project. Any of us could see the 
potential, but I didn't want to share an alpha version so to speak as the 
intro for most to the CoCo3 artifact colors as this could just deter people 
from ever using it. Do you release your alphas to everyone, no, and for the 
same reason :) The palette files were far from accurate and the initial goal 
was to share the workload (and credit) to develop the CoCo 3 artifacts to a 
point we could all use, then release it to anyone who wanted to have a play 
around with it or use it in their own projects. I didn't want to do all the 
work or receive all the credit, I think the latter was obvious in the posts 
I wrote on coco3.com (no longer there for reasons mentioned in previous 
posts). What you do with it, whether you share back what you learn or not is 
up to you once you have them, but yes I do take issue to not credit those 
who's work contributed a great deal to your project. You even conceded 
recently you could have done more in this regard, my own view is you should 
have. I'm not just saying this for my own work but for the others who also 
contributed. I had raised it with you recently due to you wanting early 
details on another project, but until now, still hadn't been mentioned 
anywhere. Perhaps it was an oversight or you simply don't share the 'ideal'. 
Maybe 'my ideal' is just delusional, I do wonder sometimes. Joel Ewy's 
artifacts slideshow project also relied on the work of others and is what I 
would consider, done the right way. You could argue that credit wasn't 
stipulated in sharing of all that (it wasn't released as such), but neither 
was it when shared with Joel, but for some reason he felt it was the right 
thing to do. Thank you Joel. It's not just all about credit for 
contributions though, others may have seen your video demo and may have even 
been interested to contribute to the development project. I don't want to 
take anything away from the video demo, it was definitely great work!!! I'd 
say to anyone who finds themselves using a big portion of someone else's 
work in their project, just mention them somewhere for the sake of community 
spirit if for no other reason :) Unless you have more to say about it, I'm 
happy to leave it at that.

The emulator support topic is a very interesting (and potentially a very 
lengthy one) and one I've put a lot of thought into. This post is way over 
length as it is so I'll save the rest for another time...

Jason