Re: Alternatives to an applecolor RGB?

[Egan Ford <datajerk@gmail.com>]

On Oct 7, 5:40 pm, "Michael J. Mahon" <mjma...@aol.com> wrote:
> Alex Freed 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.
>
> Right--fine for many uses, but not for displaying "vapor-lock"
> mixed-mode graphics displays.
>
> > 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.
>
> Agreed--though it still leaves you at the mercy of the monitor's
> resampling of the video signals.  If it phase locks to 14.3MHz, then
> the result should be great.  If it doesn't, then not so good...
>
> The problem with digital (LCD) monitors is that the pixel clock of
> the Apple must map with some integral ratio to the LCD's pixels,
> or there will be potentially significant aliasing artifacts.
>
> In general, this means that in addition to phase locking the sampling
> clock to the Apple dot clock, the width of the active display must be
> adjusted to map one Apple pixel to an integral number of LCD pixels.
> I don't know of any display that permits this degree of freedom.
>
> Since Apple II (not SHR) video has 560 "dots" per 40usec line
> of a 52,6usec active video interval, that corresponds to an NTSC
> monitor horizontal resolution of 560 x (52.6 / 40) pixels, or
> about 736 pixels.  So a 768-wide LCD should be adequate if it is
> "underscanned" appropriately.
>
> None of this is an issue with an analog display (a display without any
> pre-defined pixels of its own).
>
> A good (but possibly expensive) alternative is to use an LCD display
> with many pixels per Apple pixel, so that aliasing would be much
> reduced.
>
> -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."

~Soon we will have low cost ~300 DPI displays.  Emulating vector
graphics will look awesome, so I expect that emulating an analog
display will be less challenging.