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

Re: Making the ][+ better



Rubywand wrote:

>Rob Jones writes ...
>> 
>> Although the ][+ is already a great machine, is there anything that
>> can be done to make it better? I have added an SSC card, 16K RamCard
>> for a total of 64K, and another floppy drive (2). I am planning on
>> making and adding the Hard Disk (IDE) card. The 6502 is a good
>> processor, so that will not need to be changed, but Video leaves much
>> to be desired: I am looking into a way of tapping the video area of
>> memory ($0400~$0C00, $2000~$8000) and with a controller of some sort,
>> make HGR / HGR2 display proper colours (without the fringes), as well
>> as permanent 80-column capability.
>> 
> ....
>
>     I do not know how hard it might be to modify the hires display to
>eliminate bleeding. Since most game displays are designed to work around the
>problem, fixing it probably would not result in much improvement in showing
>current games.

Since "bleeding" occurs because there is only one "color set" bit
per 7 pixels, the only way to "fix" the problem is with another hi-res
screen read out in parallel, containing one color set bit per pixel in
the "actual" hi-res screen.  This, of course, would be completely
non-standard, and unsupported by any existing software.

Effectively, this kind of solution would be using a DHR-like mode
to display non-color set-restricted HGR.  Theoretically possible,
but far inferior to actual 16-color DHR color.

>     The kind of fringing you get when displaying stuff like white figures
>and Text in hires is built-in by the way color is encoded. A single ON
>pixel-- one that is not next to another ON pixel-- is going to have color.
>
>     You have the same problem when displaying Text mode Text in the area
>beneath a hires or lores screen because color is still turned ON. However,
>since you know you want all 4 lines of Text in that area to be in B/W, you
>can get rid of fringing there by turning OFF color during that time.
>
>     The catch is that there seems to be no way for the Apple II to turn OFF
>color in mid-screen. It looks like once a composite color monitor gets the
>Color Burst signal, color is ON for the entire frame.

Color monitors are built to detect the presence of color burst to signal the
presence of a chroma subcarrier.  The time constant of the chroma oscillator
controlled by the burst is relatively long (so that it is stable within a
frame),
and the detection mechanism also has a time constant which is on the
order of one or more frames.  There is no video standard for frames that
are encoded partially in color and partially in monochrome.

-michael

Check out parallel computing for 8-bit Apples on my
Home page:  http://members.aol.com/MJMahon/