Re: Alternatives to an applecolor RGB?

[MdntTrain <js@cimmeri.com>]

On Oct 19, 4:08 pm, Michael J. Mahon <mjma...@aol.com> wrote:
> MdntTrain <j...@cimmeri.com> wrote:
> > On Oct 9, 9:12 pm, "Michael J. Mahon" <mjma...@aol.com> wrote:
> >> MdntTrain wrote:
> >>> On Oct 7, 1:37 pm, Alex Freed <alex_n...@alexfreed.com> wrote:
>
> >>>> On 10/7/2011 8:08 AM, Michael J. Mahon wrote:
>
> >>>>> Are you saying that a SecondSight or Carte Blanche will correctly render an
> >>>>> Apple display in which a "window" of a different video mode (say, hi-res)
> >>>>> is created by synchronous mode switching within a page of a different mode
> >>>>> (say, text)?
>
> >>>>> That's a pretty tall order...
>
> >>>> Can't comment on the Second Sight but the CB is definitely capable of
> >>>> this. Not sure if it will work with the default configuration - it's
> >>>> been a while since I designed it an I don't quite remember what made it
> >>>> to the release.
>
> >>>> The simplest possible approach I used in the very first FPGApple was
> >>>> re-implementing the original Apple video hardware in configurable logic.
> >>>> No buffers needed - just scan the video buffer and display it. As long
> >>>> as the emulated 6502 is cycle accurate this should re-create all the
> >>>> video effects perfectly, switching or not.
>
> >>>> The problem is that this requires a video monitor that supports 16 MHz
> >>>> line rate. Not many did in those days. So the next step was to double
> >>>> scan the lines at 32 KHz. Worked great with an analog VGA monitor, but
> >>>> looked horrible on LCD - the pixel clock of 14.xx MHz didn't map well to
> >>>> any VGA rate. The solution was to buffer each line and scan at 25 MHz.
> >>>> This of course sacrifices compatibility with trick video modes even more
> >>>> but provides great text and standard graphics on an LCD.
>
> >>>> If I had to implement as good an emulation of the video as possible
> >>>> today on modern LCDs I would probably target the new breed of
> >>>> TV/monitors. In addition to DVI and VGA some have component video
> >>>> inputs. Generating RGB (or YPbPr) at Apple native NTSC rate with
> >>>> improved sync it not hard at all.
>
> >>>> -Alex.
>
> >>> As an aside, and as M. Mahon got me interested in looking at, the IIgs
> >>> analog RGB video is easily converted to analog Component (YPbPr) via a
> >>> simple analog RGB->Component converter.
>
> >>> For those who haven't seen these before, here's some photos I took
> >>> awhile ago of this conversion done into a Samsung 192MP LCD monitor
> >>> with analog Component inputs (which natively can handle standard 15khz
> >>> 480i video).  Note the advantage that the monitor is upscaling the
> >>> video to 480p on its own.
>
> >>>www.cimmeri.com/js/download/RGB1.JPG
> >>>www.cimmeri.com/js/download/RGB2.JPG
> >>>www.cimmeri.com/js/download/RGB3.JPG
> >>>www.cimmeri.com/js/download/RGB4.JPG
> >>>www.cimmeri.com/js/download/RGB5.JPG
> >>>www.cimmeri.com/js/download/RGB6.JPG
> >>>www.cimmeri.com/js/download/RGB7.JPG
>
> >>> The crappy GSOS desktop (#5) is due to what M. Mahon has been talking
> >>> about all this thread about aliasing / dot clock sync issues, as well
> >>> as a Component input being too high a bandwidth input (as it also
> >>> needs to handle 480p right on up to 1080i and 720p).  Remember, the
> >>> IIgs analog color mixing depended on the IIgs RGB monitor's analog
> >>> bandwidth limitations.  Had the monitor been too good, striping would
> >>> have been visible.
>
> >>> By comparison, an LCD monitor with SCART RGB (also native 480i 15khz
> >>> video) such as the Samsung 910MP (USA and worldwide) eliminates the
> >>> need for a RGB->Component converter, and is already by definition
> >>> analog bandwidth limited.. thus I get near perfect IIgs video on that
> >>> monitor.
>
> >>> Summed up, the IIgs relies on effects best done in the analog world.
> >>> I haven't tried it yet, but bandwidth limiting that Component video
> >>> signal set *before* it goes into the monitor, if it can be done with
> >>> an roll-off curve similar to that of an old RGB monitor, might do the
> >>> trick.  But now, we're no longer in the plug-and-play domain.
>
> >>> The only three plug and play solutions (that I'm aware of) that
> >>> produce near perfect, 480p upscaled results for the IIgs are:
>
> >>> - SCART cable -> SCART monitor;
> >>> - Highway 100 (Scart input) -> VGA monitor;
> >>> - Hirsh's CYP device (I've no experience with it).
>
> >>> If you don't being in black and white for 640x200 mode (or
> >>> alternatively, don't mind color stripes), then converting the IIgs to
> >>> Svideo gives you a very nice signal that works with many modern
> >>> monitors (at least, the ones I own), but again, this is not plug and
> >>> play.
>
> >>> - jS
>
> >> Those are great pictures.
>
> >> RGB5, RGB6, and RGB7 are perfect examples of what happens when the
> >> monitor itself resamples the video to match its discrete pixels.
>
> >> No other resampling is being done, since the RGB-->component conversion
> >> is in the analog domain.
>
> >> -michael
>
> >> NadaNet 3.1 for Apple II parallel computing!
> >> Home page:  http://home.comcast.net/~mjmahon/
>
> >> "The wastebasket is our most important design
> >> tool--and it's seriously underused."- Hide quoted text -
>
> >> - Show quoted text -
>
> > Michael,
>
> >    Wouldn't it be the case that even if you had perfect dot sampling
> > at the dot clock frequency, you'd still run into the problem of lack
> > of IIgs dithering with an LCD or a fairly good analog VGA screen?  An
> > *accurate* rendition would show stripes, whereas on a IIgs RGB screen,
> > these stripes would be blurred (dithered) into a new color due to its
> > 8mhz bandwidth.
>
> >    So having a really good LCD with several pixels per Apple pixel
> > isn't going to solve all the problems.   A dithering re-creator stage
> > is still needed.  An early, cheap VGA screen (640x480 max resolution)
> > might have the same bandwidth limitations as the IIgs RGB screen, and
> > thus effect the dithering ok.
>
> >   The only lucky reason the Highway 100 converter works so well with
> > LCD monitors is that it is bandwidth filtering its RGB input, such
> > that the LCD's characteristics are not an issue.
>
> > - John
>
> The "stripes" that are so coarse and obnoxious are the resampling aliasing
> stripes, not the alternate-pixel dithering stripes. I doubt that many would
> find those distracting.
>
> However, they can be eliminated easily by bandwidth-limiting the analog
> video signals (in *any* coding: RGB or YCrCb). This can be easily tried by
> placing shunt capacitors to ground across the video lines. A more complex
> filter could be used to achieve perfection, but that is unnecessary to
> prove the point.
>
> -michael - NadaNet 3.1 and AppleCrate II:http://home.comcast.net/~mjmahon- Hide quoted text -
>
> - Show quoted text -

So, what's creating the occasional black, vertical stripes in RGB5.jpg
is the misaligned dot sampling, hitting the black space between the
active dots of color?   I'm not sure where the black is coming
from.    I remember awhile back, you'd hooked up your scope to the
IIgs to observe the video output -- would you refresh my memory?  On a
solid blue background such as the GSOS desktop, does the video signal
go off (black) between each of the 640 active dots, or would it stay
on all the way across the screen, with 640 total possible (but unused)
spots for color changes?   (I don't have access to my own equip at
this time).

- JS