Post by Doug Dingus
Iconix was exactly the thing I needed. I wanted to take a quick look at
the GS through it's composite video output. Apple has the pixel clock
just a shade off from being aligned with the NTSC color cycle. The
little color sample program did what I was looking to do quick and easy.
I have had fun and often great results doing artifact color on every
machine I've gotten hold of. Was hoping the GS was more like the CoCo 3,
where on that machine the 640 pixel mode, with the palette set to black,
white and two greys, will deliver a nice, 8bpp color screen, one byte per
pixel. Programming that machine, in this way, is a lot of fun. Simple
bytes makes things easy.
The GS will do the pixels and palette, but the alignment is just a shade
off, which gives a rainbow effect for some combinations, and a varying
hue effect on many others.
Now my curiosity is satisfied quick and easy. Wanted to take a peek at
this one for a long time.
Thank you again.
Post by Antoine Vignau
Yes, it is Iconix by So What Software. Get it at
Thanks! I got the image and will fire it up. Really, I am into CRT
displays and such right now and just want some simple "programmer",
"tester" type graphics to understand what I'm seeing better.
Re: GS Languages
I saw those and really didn't want to wade into the QuickDraw
environment at this time. I was about to just write a little '816
routine to turn the screen on and drop values into RAM and call it good.
Maybe later I can revisit QuickDraw. I've never used it.
My machine is a ROM 1, I think. 256Mb style GS. It had a Transporter
card in it, and a partially populated 1Mb memory expansion. Not enough
to run most recent GS OS at this time. For now, I want to basically
tinker with it some, maybe do some '816 programming, etc...
Unlike the 8-bit Apple II’s, the composite video output of the IIgs is not
a directly generated digital signal.
The IIgs is a natively RGB machine, and the composite video is generated by
an MC1377 RGB-to-NTSC converter chip. In the non-SHR modes, the typical
Apple video signal is first processed by a built-in RGB “card”, whose
output is then converted *back* to composite by the MC1377.
This causes the composite output for traditional HGR modes to be subject to
two sequential sources of error: first, the digital video to RGB
conversion, which always fails to convert the subtle artifacts in pursuit
of “sharpness”, and second, the chroma matrixing of the MC1377.
There is no way the pixel clock of the traditional modes can be off in
frequency, since all signals are directly derived from the master
oscillator at 14.3818MHz, exactly 4x the NTSC color reference frequency.
The exact phases of the pixel pulses relative to this reference are
determined by shifting out four bits per subcarrier cycle, so their
relative phases are also “baked in”.
Of course, no crystal oscillator is precisely on frequency, but it will be
well within the chroma lock range for any monitor designed to accommodate
the standard subcarrier frequency tolerance.
-michael - NadaNet 3.1 and AppleCrate II: http://michaeljmahon.com