Re: Supercard



Jorge ChB wrote:
Linards Ticmanis <ticmanis@xxxxxx> 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.)

-michael

Parallel computing for 8-bit Apple II's!
Home page: http://members.aol.com/MJMahon/

"The wastebasket is our most important design
tool--and it is seriously underused."
.



Relevant Pages

  • text antialiasing
    ... that reduces to 51 unique different patterns. ... grayscale values, 0-255, for each of these unique patterns. ... center pixel black, and another 51 for the center pixel white. ... Inverse, all eight pixels set ...
    (comp.graphics.algorithms)
  • Re: Coincidence? Or Is Green Hard To Do?
    ... This has patterns for producing solid red, blue, green and white ... And although it doesn't apply to laptops, it has a pattern for aligning the dot clock frequency and phase of analog LCD monitors. ... pixel being stuck on rather than stuck off. ...
    (comp.sys.laptops)
  • Re: Supercard
    ... 113-114-115-116 on a line are no more of a pixel than bits ... The RGB video output generated by a IIgs may well be against your theory ... Instead you'll get a single white pixel for patterns 1&5, ... an analog NTSC monitor will show some soft pastel transitions ...
    (comp.sys.apple2)
  • Re: Supercard
    ... Linards Ticmanis wrote: ... 113-114-115-116 on a line are no more of a pixel than bits ... Instead you'll get a single white pixel for patterns 1&5, ...
    (comp.sys.apple2)
  • Re: Supercard
    ... 113-114-115-116 on a line are no more of a pixel than bits ... this particular case (Apple II DHGR) better be conceptually grouped by 4 ... The RGB video output generated by a IIgs may well be against your theory ... emulating the composite output. ...
    (comp.sys.apple2)