IIgs Double HIRES

[Daniel Kruszyna]

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

[Charlie]

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.

Charlie

[Vladimir Ivanov]

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?

[Marc S. Ressl]

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?

With the best wishes,

Marc.-

pd. guess why I'm asking these questions ;-)

[Daniel Kruszyna]

Vladimir Ivanov <vla...@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.

-- Daniel

[Daniel Kruszyna]

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.

-- Daniel

[Geoff Body]

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

[Charlie]

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.

Charlie

[Daniel Kruszyna]

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.

-- Daniel

[Charlie]

Geoff thank you for the patent information. This is the first time I've
seen this representation.

Charlie

[Michael J. Mahon]

As noted, the SHR dot clock is 16.36363MHz.

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

[Vladimir Ivanov]

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.

[Vladimir Ivanov]

How much memory you have available for lookup?

The IIgs simple yet effective mode you can already implement in few hours.
:-)

[Charlie]

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.

> 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. :-)

Charlie

[Vladimir Ivanov]

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:

http://www.softjunk.org/sw/apple2/ra2/files/screenshot/ntsc/bpp/

>> 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. :-)

No, about the IIgs DHGR mode - the non-linear 4-bit sliding window from
that US patent. It's very simple and effective.

[Charlie]

I misunderstood you. Yes the non-linear 4-bit sliding window looks like
the way to go.

Charlie

[Daniel Kruszyna]

For the record, I tested the algorithm in this patent, and it matches the
output of my ROM 1 IIgs.

-- Daniel

[Charlie]

Excellent!

What did you implement it in, a Carte Blanche card, emulator or picture
display program?

Charlie

[Daniel Kruszyna]

Charlie <charl...@vereyezon.net> wrote:
> What did you implement it in, a Carte Blanche card, emulator or picture
> display program?

Unfortunately, I don't own a Carte Blanche. I just tested it on an FPGA
development board I have.

-- Daniel