Re: Alternatives to an applecolor RGB?

[Michael J. Mahon <mjmahon@aol.com>]

MdntTrain <js@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