[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Supercard

sicklittlemonkey wrote:

Eric Smith wrote:


"Michael J. Mahon" <mjmahon@aol.com> writes:


Actually, I think it would be pretty simple today--but no one
has done so AFAIK.


Trevor Blackwell's "Apple ][" screesaver that is distributed as part of
xscreensaver does it.

http://www.jwz.org/xscreensaver/screenshots/
http://www.trevorblackwell.com/software.html



I had a look at this out of curiosity, expecting to see the usual
artifacting hacks.

But no, you're right, and thanks a lot for this link! His patch is most
*illuminating*! He emulates a typical NSTC display, but far from
idealizing it, includes all the nasty things that often distorted the
resulting image.


Yes, but he actually goes a little overboard in this area, and gets
a few things just plain wrong.

For example:

1) The "color shift instability" that in some cases caused the hue
   to vary across the width of the screen was not caused by instability
   of the Apple's oscillator, but by a frequency difference between the
   Apple oscillator (/4) and the monitor's color reference oscillator.
   This difference causes the phase to drift progressively between
   color burst resynchronizations.

   I've never observed this distortion myself, though I did have
   an Apple II whose crystal was far enough off that the monitor
   would not color lock at all, creating a monochrome display.

2) The blooming is backwards, and the explanation of its origin is
   incorrect.  Blooming in a CRT display as brightness increases is
   a result of sagging of the HV supply, caused by increase loading
   because of higher electron beam current (not by increased loading
   of the horizontal "oscillator"--here he means the horizontal output
   amplifier).  When the HV sags, the width of the horizontal scan
   *increases* (not decreases) because the velocity of the electron
   beam decreases, making it easier to deflect.

   This distortion is present to some degree in virtually all CRT
   monitors, and can be easily observed by diaplaying a white border
   on an otherwise black screen, then alternating that with an all
   white screen.  The boundaries of the raster, both horizontal and
   vertical, can be seen to move out on the white display, and you
   can see why it's called "blooming".

3) He claims that "compression and brightening" on the right side is
   a result of the Apple using "so much of the line width" that it was
   necessary to decrease the width of the scan to avoid cutting off
   the rightmost characters.  Actually, the Apple II uses less than
   40 cycles of the display line, of which 51 microseconds are typically
   available for video.  So the Apple video was meant to work with more
   than 20% overscan--on the high side of what was typical for monitors.

   No doubt the occasional TV set needed to have its width reduced a
   little, but any resulting non-linearity could be adjusted with the
   horizontal linearity coil.

   So, my verdict is that this is a largely gratuitous distortion, but
   one which might have been visible on a really cheap B&W TV.  (Like
   the horizontal retrace lines that he mentions wanting to add, but
   hasn't.  ;-)  He's just got the reason for the horizontal nonlinear-
   ity a little wrong--it's actually the cheap monitor, not the Apple.

4) When discussing the YIQ --> RGB matrix, he mentions in passing that
   sometimes it's done in the CRT itself.  I've never seen this, and
   would be interested in a reference to a "native YIQ" CRT.  Doing
   so would present interesting complications for background adjustment
   of R, G, and B guns.

Don't take this the wrong way--I'm not nit-picking so much as reviewing
what he says at the level of detail at which he states it.  ;-)

I think that overall, it represents a fine example of how to go about
simulating a "real" display--something which I haven't seen elsewhere
in the emulation world (and never in a hardware RGB adapter ;-).


Outstanding. It's well commented too, including this
chestnut:

+    /* Now filter them. These are infinite impulse response filters
calculated
+       by the script at
http://www-users.cs.york.ac.uk/~fisher/mkfilter. This is
+       fixed-point integer DSP, son. No place for wimps.

You should be right at home Michael! I'd be interested in your
comments.


He certainly takes the direct approach--appropriate I suppose for
todays high performance processors.  And the use of DSP filters
is entirely appropriate, though there may be simpler methods.

I'd be more inclined to precompute the relevant cases into a
palette table, and use the "sliding window" approach, as I've
noted.  This involves some approximations, but I think the result
would be very good with much less "real time" computation.

If you look at only 4 bits at a time in a sliding window, you can't
take into account any context below a frequency of 3.5MHz.  As you
widen the window to 10 bits, you can handle context down to 1.4MHz,
which should be enough to handle most artifacts faithfully.  If
12 bits are used (for a 4096 entry palette), then it should be
possible to "filter" down to 1.16MHz, which should allow excellent
fidelity to low-bandwidth chroma processing.


This is the kind of stuff that NewRisingSun was doing, and has been
incorporated into various other emulators, but I've never seen it well
documented. Not being a DSP guy (well, I get the basics) the step by
step comments here are very useful. Pity he didn't write the other half
of the emulation! Luckily, we have that already ...


Yes, and it's a good example of what an "NTSC emulation layer" would
be like.  It could be shared by all systems in a multi-system
emulator.

-michael

Parallel computing for 8-bit Apple II's!
Home page:  http://members.aol.com/MJMahon/

"The wastebasket is our most important design
tool--and it is seriously underused."