Re: Supercard

["mdj" <mdj.mdj@gmail.com>]

Michael J. Mahon wrote:
> Jorge ChB wrote:
> > Linards Ticmanis <ticmanis@gmx.de> wrote:
> >
> >
> >>Jorge ChB wrote:
> >>
> >>
> >>>, windowed pixels
> >>>that span 4 bits among consecutive 7 bits "bytes" that happen to
> >>>alternate between main and aux memory banks
> >>
> >>I'd just like to add that these don't exist as such. Bits
> >>113-114-115-116 on a line are no more (or less) of a pixel than bits
> >>114-115-116-117 or bits 115-116-117-118.
> >
> >
> > Linards, I'm not so sure...
> >
> > I believe that the "pixels" shouldn't be sitting across the boundaries
> > of a single cycle of the color reference unless you want odd things to
> > start happening. For example, that the color of your "pixel" becomes a
> > function of the colors of the adjacent "pixels", an odd behavior for a
> > (color) "picture element"... and the reason why the "pixels" should in
> > this particular case (Apple II DHGR) better be conceptually grouped by 4
> > and starting from the first bit, not from the 2nd nor the 3rd nor the
> > 4th.
> >
> > The RGB video output generated by a IIgs may well be against your theory
> > too : I bet that the patterns below won't show on the screen a single
> > white "pixel" moving from left to right, as would be the case if any 4
> > bits could be a single pixel:
> >
> > 1.- 11110000 -> 1 pixel, white
> > 2.- 01111000 -> 2 pixels, 1st yellow, 2nd dark blue
> > 3.- 00111100 -> 2 pixels, 1st orange, 2nd medium blue
> > 4.- 00011110 -> 2 pixels, 1st magenta, 2nd aqua
> > 5.- 00001111 -> 1 pixel, white
> >
> > Instead you'll get a single white pixel for patterns 1&5, and *two*
> > adjacent pixels for patterns 2,3 and 4, of varying colors.
>
> On an NTSC monitor it will show up as a 4-pixel white block,
> shifting by one pixel.
>
> If it doesn't look that way on a IIgs, then the IIgs is not faithfully
> emulating NTSC (not too surprising, since most RGB cards didn't do it
> very well, either).
>
> Actually, an analog NTSC monitor will show some soft pastel transitions
> to white and back to black on the edges, but that's because of bandwidth
> limiting in the color circuits.  (And it's why I suggest using a wider-
> than-4-bit sliding window for color mapping.)

What exactly is the goal here? If the idea is to provide VGA compatible
output to an 8 bit Apple II, then I'm not sure that figuring out how
the IIgs does it is worthwhile - it really does to a very poor job of
emulating the composite output.

I would imagine that the better approach would actually to be do the
colour decoding in the analog domain. This will get a much more
faithful representation of composite colour than any form of digital
domain decoding will. The lack of digital resolution is a real
limitation in this regard (IMHO)

How you go about it depends a great deal on what display you want to
drive. If the goal is to drive modern digital panels, then of course
the approach taken would be rather different.

Matt