Re: Supercard

mdj wrote:
Michael J. Mahon wrote:

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.)


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.

Actually, the "sliding window" approach, with 8 or 12 bits, would
do a fine job of creating accurate artifacts. This should be
particularly easy to try in an emulator, but it could also be used
with a hardware VGA adapter.

There would only be as many horizontal pixels as there are on an
Apple II, so if you wanted to fill the screen, you'd have to scale
it up, of course (integer multiples are easy).

I'd just like to see a good RGB/VGA emulation of a composite display,
so that many more things would look as they were designed to look.

-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

  • Re: 7 Places Where Mac OS X is Still Behind Windows
    ... >> nVidia had this working in hardware around 1997. ... The technology to do that was well within the accelerator vendors ... because Apple didn't think to make even one single request. ... > primitive's outline, overlaid upon the output pixel grid, the line may ...
    (comp.sys.mac.advocacy)
  • Re: Double hires mode color artifacts
    ... expect of an Apple II, given its resolution and color limitations. ... essentially no change after the window had filled with 14 "dots". ... pixel on host pixel boundaries. ... A filter of 4 bit width in hires should be already sufficent for that. ...
    (comp.sys.apple2)
  • Re: Double hires mode color artifacts
    ... which was with an NTSC display. ... expect of an Apple II, given its resolution and color limitations. ... pixel on host pixel boundaries. ... "sliding window" mode without quantizing x alignment), ...
    (comp.sys.apple2)
  • Re: RGB to VGA on a IIGS (again)
    ... the monitor screen more than two feet away. ... interpreting the pixel widths slightly differently. ... pixels is about 375, and to 560 Apple pixels, 750. ... resolution for 640 pixel SHR mode is 858 pixels. ...
    (comp.sys.apple2)
  • 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)