Has anyone documented the method that the IIgs uses to determine
color in double hires mode? A search of the archives brings up
some discussion, but not any findings...
> Has anyone documented the method that the IIgs uses to determine
> color in double hires mode? A search of the archives brings up
> some discussion, but not any findings...
> -- Daniel
The Apple IIgs Hardware Reference gives a small amount of information less than a page and half including the usual table for figuring the color pattern. A more in-depth description is in the Apple IIe technote #3 (revised in 1988 to include the IIgs).
Having said this I would like to hear of something better myself as I have struggled to understand the double hires mode.
On Sun, 12 Feb 2012, Charlie wrote:
> On 2/12/2012 5:00 PM, Daniel Kruszyna wrote:
>> Hello All,
>> Has anyone documented the method that the IIgs uses to determine
>> color in double hires mode? A search of the archives brings up
>> some discussion, but not any findings...
>> -- Daniel
> The Apple IIgs Hardware Reference gives a small amount of information less > than a page and half including the usual table for figuring the color > pattern.
The Hardware Reference claims 4-bit sliding window.
There's also a bit in a register controlling B&W or color mode for Double Hires.
> Having said this I would like to hear of something better myself as I > have struggled to understand the double hires mode.
> On Sun, 12 Feb 2012, Charlie wrote:
> > On 2/12/2012 5:00 PM, Daniel Kruszyna wrote:
> >> Hello All,
> >> Has anyone documented the method that the IIgs uses to determine
> >> color in double hires mode? A search of the archives brings up
> >> some discussion, but not any findings...
> >> -- Daniel
> > The Apple IIgs Hardware Reference gives a small amount of information less
> > than a page and half including the usual table for figuring the color
> > pattern.
> The Hardware Reference claims 4-bit sliding window.
> There's also a bit in a register controlling B&W or color mode for Double
> Hires.
> > Having said this I would like to hear of something better myself as I
> > have struggled to understand the double hires mode.
> What exactly is troubling you?
Btw, I have a question that has been bothering me for quite some
time... what is the pixel clock for IIGS Super HIRES?
I understand that the pixel clock for HIRES and DHIRES is the famous
14.31818 MHz, and this gives you 560 pixels. As Super HIRES has 640
pixels, is the pixel clock the same (thus video shows with more
width), or is it stretched so 560 DHIRES pixels look like 640 SHIRES
pixels? What about the horizontal count, does it still go 0, 0x40,
0x40, ..., 0x7f as in the Apple II modes? And does visible video go
from 0x58 to 0x7f?
Vladimir Ivanov <vlad...@xxxyahooxxx.com> wrote:
>> The Apple IIgs Hardware Reference gives a small amount of information less >> than a page and half including the usual table for figuring the color >> pattern.
> The Hardware Reference claims 4-bit sliding window.
Hmm, my observations suggest that it uses 5 or 6 bits. Also, the color of
certain pixels appears to depend on whether _future_ bits are set. I would
expect a "normal" sliding window to consider only the past bits.
For example:
1000 0000 gives a single blue pixel followed by black pixels
1000 1000 gives five blue pixels followed by black pixels
1000 0100 gives five blue pixels, followed by one green pixel, followed by black pixels
In the last two cases, adding a 1 to the second block of four causes the space
in between to be filled. I would expect to see black in between the blue and
green in the third case, and four blue pixels in the first case.
I've written the bits as they appear at the output of the shift register. The
fact that the actual bytes in video memory may be different doesn't seem to
matter.
The hardware does appear to use some sort of sliding window as the same
behavior occurs if the patterns are shifted over 1, 2, or 3 bits -- just the
actual colors are different.
> Btw, I have a question that has been bothering me for quite some
> time... what is the pixel clock for IIGS Super HIRES?
According to the archives, Michael Mahon measured an 8/7 * 14.31818 MHz
dotclock. I haven't duplicated this exact measurement, but have some
supporting evidence:
The main reason is that the MegaII still controls the video address scanner,
even in super hires modes. The scanner is always clocked by 14M. It's just
that in super hires, all 8 bits of the video data are used instead of 7.
To me the patent US4786893 appears to relate to possible IIGS video
conversion from NTSC bit stream to RGB output and may help.
The Super HIRES mode appears to be the same screen size as the older
modes, therefore it needs to output 8 bits for every 7 of the old
mode.
If you look at patent US4823120, Fig 2 ref 39 it would appear to be
related to 8MHz vs 7MHz for standard video modes.
>> On 2/12/2012 5:00 PM, Daniel Kruszyna wrote:
>>> Hello All,
>>> Has anyone documented the method that the IIgs uses to determine
>>> color in double hires mode? A search of the archives brings up
>>> some discussion, but not any findings...
>>> -- Daniel
>> The Apple IIgs Hardware Reference gives a small amount of information
>> less than a page and half including the usual table for figuring the
>> color pattern.
> The Hardware Reference claims 4-bit sliding window.
> There's also a bit in a register controlling B&W or color mode for
> Double Hires.
>> Having said this I would like to hear of something better myself as I
>> have struggled to understand the double hires mode.
> What exactly is troubling you?
I've tried to implement this 4-bit sliding window some years ago in a program I wrote to display DHR pictures on a PC. Although, it produces a picture that is recognizable it really only seems to work for stretches of the same color. I again ran into the same problem when I implemented DHR on the Carte Blanche card. When moving from one color to a different color on the line the sliding window seems to break.
Now It could well be my programming skills that are not up to the challenge but in speaking with others and reading all I could find. I have yet to see an algorithm that correctly produces a DHR picture. The exception being those who used very large look-up tables to cover every case of color changes. That's something I don't have the luxury of in the Carte Blanche card.
Geoff Body <gbo...@bigpond.com> wrote:
> To me the patent US4786893 appears to relate to possible IIGS video
> conversion from NTSC bit stream to RGB output and may help.
Thanks, Geoff, this is it!
I'll have to study it more tomorrow, but the gist is that there is a 4 bit
sliding window with some extra circuitry to check when the 4 bit pattern
changes. The input to the sliding window is compared to the oldest output bit
-- this makes a total of 5 consecutive bits considered, which is consistent
with my observations.
When a change is detected, the current color value is frozen until the new
value in the sliding window stabilizes -- also consistent with my observations.
> To me the patent US4786893 appears to relate to possible IIGS video
> conversion from NTSC bit stream to RGB output and may help.
> The Super HIRES mode appears to be the same screen size as the older
> modes, therefore it needs to output 8 bits for every 7 of the old
> mode.
> If you look at patent US4823120, Fig 2 ref 39 it would appear to be
> related to 8MHz vs 7MHz for standard video modes.
> Geoff
Geoff thank you for the patent information. This is the first time I've seen this representation.
Daniel Kruszyna wrote:
> Marc S. Ressl <mre...@gmail.com> wrote:
>>Btw, I have a question that has been bothering me for quite some
>>time... what is the pixel clock for IIGS Super HIRES?
> According to the archives, Michael Mahon measured an 8/7 * 14.31818 MHz
> dotclock. I haven't duplicated this exact measurement, but have some
> supporting evidence:
> The main reason is that the MegaII still controls the video address scanner,
> even in super hires modes. The scanner is always clocked by 14M. It's just
> that in super hires, all 8 bits of the video data are used instead of 7.
On Mon, 13 Feb 2012, Daniel Kruszyna wrote:
> Geoff Body <gbo...@bigpond.com> wrote:
>> To me the patent US4786893 appears to relate to possible IIGS video
>> conversion from NTSC bit stream to RGB output and may help.
> Thanks, Geoff, this is it!
> I'll have to study it more tomorrow, but the gist is that there is a 4 bit
> sliding window with some extra circuitry to check when the 4 bit pattern
> changes.
Yep, there was non-linearity now that this patent is mentioned and my memory is refreshed. With a very simple circuit they handle passably most of the cases.
We have discussed this somewhere in the past, distant enough that I couldn't remember it quickly. I even had provisions for this mode (IIgs RGB) in my RA2 code. IIRC (obviously not to be trusted), IIgs RGB mode is much better than simple 4-bit sliding window, which in turn is better than simple 4-bit non-sliding window. The last one, again IIRC, was used in our Pravetz-8C color output, but it was normally not populated on the motherboard out of the factory.
On Sun, 12 Feb 2012, Charlie wrote:
> I have yet to see an algorithm that correctly produces a DHR picture. > The exception being those who used very large look-up tables to cover > every case of color changes. That's something I don't have the luxury > of in the Carte Blanche card.
How much memory you have available for lookup?
The IIgs simple yet effective mode you can already implement in few hours. :-)
>> I have yet to see an algorithm that correctly produces a DHR picture.
>> The exception being those who used very large look-up tables to cover
>> every case of color changes. That's something I don't have the luxury
>> of in the Carte Blanche card.
> How much memory you have available for lookup?
The Carte Blanche card has 250Kbytes of SRAM but that isn't practical to use for a lookup table since we're using it to read/write some of the video buffer. The internal FPGA BRAM is only about 24KBytes and that's virtually all used.
> The IIgs simple yet effective mode you can already implement in few
> hours. :-)
If you are talking about the SHR mode it's already done. :-)
On Mon, 13 Feb 2012, Charlie wrote:
> On 2/13/2012 7:37 AM, Vladimir Ivanov wrote:
>> On Sun, 12 Feb 2012, Charlie wrote:
>>> I have yet to see an algorithm that correctly produces a DHR picture.
>>> The exception being those who used very large look-up tables to cover
>>> every case of color changes. That's something I don't have the luxury
>>> of in the Carte Blanche card.
>> How much memory you have available for lookup?
> The Carte Blanche card has 250Kbytes of SRAM but that isn't practical to use > for a lookup table since we're using it to read/write some of the video > buffer. The internal FPGA BRAM is only about 24KBytes and that's virtually > all used.
Too bad. My experiments showed that 9-bit lookup vector is quite nice looking for NTSC emulation. This needs 4 tables of 512 entries, each entry being your DAC triplet output (12-bit or less, I assume).
Check sample 6, 9, 12 and 24-bit lookup vectors here:
>>>> I have yet to see an algorithm that correctly produces a DHR picture.
>>>> The exception being those who used very large look-up tables to cover
>>>> every case of color changes. That's something I don't have the luxury
>>>> of in the Carte Blanche card.
>>> How much memory you have available for lookup?
>> The Carte Blanche card has 250Kbytes of SRAM but that isn't practical
>> to use for a lookup table since we're using it to read/write some of
>> the video buffer. The internal FPGA BRAM is only about 24KBytes and
>> that's virtually all used.
> Too bad. My experiments showed that 9-bit lookup vector is quite nice
> looking for NTSC emulation. This needs 4 tables of 512 entries, each
> entry being your DAC triplet output (12-bit or less, I assume).
