Re: Alternatives to an applecolor RGB?

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

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