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

Re: Color fringe hires behavior



BLuRry wrote:
BTW, from your original post, I assume this is all being done on
real Apple II's and has *nothing* to do with emulation--correct?


It has nothing to do with emulation... yet.  :-)  I have two things I
want to do.  The first is to generate a best-fit image converter then
understands exactly how different combinations of patterns will appear
when displayed in NTSC.  So in order to know what patterns are
best-fit, I need to have the ability to produce lookups of the
combinations to aid the dithering process.  As a bonus, having an
understanding of why/when the gray dhgr pixels have a slightly green or
red edge to them or how two pixels look when next to each other (e.g.
would the pattern 0011 1100 produce an offset white pixel?)  would
correct the nastiness of my rgb-based approach for the pseudo color
algorithm I wrote previously.  In a sense, a best-fit solution would
take these odd behaviors into account when converting the image and
might take advantage of the behavior.

Once I've gone that far, I might as well add this color dithering logic
to the java-based emulator that's 1/3 completed on my hard drive.
Because, hey, why not? :-)

My point was that there are two *completely different* problems:
1) the mapping of the various Apple video modes to DHR, and
2) the mapping of digital video output to hi-res RGB format so
   that the behavior of an NTSC color monitor is emulated.

The first problem is completely solvable (or not) by considering
the digital logic and the generated video waveform.  This problem
is entirely an Apple-related problem.

The second problem requires the characterization of a "standard"
NTSC monitor and the application of (or approximation of) digital
filtering to mimic the analog processing of the monitor.  This is
a very general problem applicable to *all* digital devices that
generated an NTSC composite signal.

The independence of these two problems strongly suggests that any
emulation should layer the display rendering into a "system-dependent"
part and a "display-dependent" part, so that users could select the
emulated display that they would like to "attach" to the system
emulator, and so that new "displays" could be easily emulated.

-michael

NadaNet networking for Apple II computers!
Home page:  http://members.aol.com/MJMahon/

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