Re: Alternatives to an applecolor RGB?

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

MdntTrain <js@cimmeri.com> wrote:
> 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).

That's right. The desktop is an alternating pattern of light blue and
black--the video signal is an 8MHz squarewave. 

If all of the signals were band-limited, say with small capacitors to
ground, then that aliasing would be greatly reduced. 

-michael - NadaNet 3.1 and AppleCrate II: http://home.comcast.net/~mjmahon