HighGFX is only another 35ns screenmode, compare it with Super72 800x600 ... the problems are reproducible.
But here are some HighGFX hints (works even with Super72 or other SuperHires-modes):
The best compromise between color and speed is a 32 Color (5BP) workbench.
If you use FBLIT with HighGFX (or any other 35ns mode) keep in mind, that FBLIT is a hack and not HighGFX.
If you have problems with FBLIT and flickering, change the setting QBSBlittPatch -> "inline", the old presetting "beamsync" seems to be problematic.
Some of the early A1200 also have problems with 35ns modes in combination with bright colors, here is a software-workaround:
http://aminet.net/package/util/misc/BitmapShadesAdditional ... use some kind of "Borderblank" tool. Its better for the Indy to catch screenmodes with BB activated.
The CBM Lisa is producing higher temperatures than the HP Lisa ... HAM8 is sometimes problematic, keep your Amiga-ChipSet cool.
There is a new firmware-update for the IndyAGA on the way ...
http://babelfish.yahoo.com/translate_url?doit=done&tt=url&intl=1&fr=bf-home&trurl=http%3A%2F%2Fwww.a1k.org%2Fforum%2Fshowthread.php%3Fp%3D273155&lp=de_en&btnTrUrl=TranslateSome CBM notes about the AA-ChipSet:
Here is a collection of notes from the AA project. Some of these bugs have been
fixed.
Known AA bugs:
o Blitter problems in 7 bitplane 35ns modes. The cause of this is unknown, but
there are no software ramifications. It's a pure Chip bug.
o VBlank seems to be starting one line too early, and finishing one line too
early. This has to be proved to be a Chip bug by the chippies, but it does
appear to be so. The problem only exists for programmed Beam Sync modes.
Leaving this problem unsolved causes a few problems:
1) A single line at the bottom of the display which is in colour 0 of the
highest screen in the display (ie, the colour set up in copinit).
2) The top line of one of these displays is not visible, but is hidden in the
vertical blanking region.
Both of these are cosmetic problems.
3) Because of this, the WaitTOF() code seems to be confused into thinking vblank
has finished when in fact it hasn't. For example, switching from a NTSC
interlaced screen to a VGA Productivity screen can cause the display to be
blank, even though an examination of the copper lists shows no problems. I have
sort of worked around this by altering the characteristics of the monitor in the
monitor's TOOLTYPES to start vblank one line early (the last line of the
display), and finish one line early. However, I consider this to be a temporary
kludge, especially as this seems to cause problems when some of the monitors are
used in interlaced mode.
[THIS WORKAROUND IS STILL IN PLACE, AS THE BUG WAS NEVER FIXED]
o FMode not reset at power up. This is relatively harmless, as all AA systems
will ship with 3.0 which resets the fmode properly. However, anyone with a AA
system that decides to power up into 2.0 (eg with an old devs:kickstart) will
get two pointers.
[I THINK THIS WAS FIXED]
o BPRUN problems: With R1 of Alice, 16 and 32 cycle modes (Hires 4x, Lores 2x
and Lores 4x) were holding the internal BPRUN line for too long. In the 32
cycle, this ran on through to the next line and confused the internal chip
state machine (the chippies could tell you better than I can what the problem
was). This they have 'fixed' in the R2 Alice by terminating BPRUN after the 16th
cycle of the 32 cycle for the last fetch. However, this does not fix the other
problem which is this - When horizontally scrolling a large screen that is
overscanned all the way to the far right, I need to set the DDFSTOP value to
0xd8 in the 16 cycle, and 0xc8 for the 32 cycle. Taking the 0xd8 case, if BPRUN
were to end after the 16th cycle (as it currently does), then BPRUN runs through
until cycle number 0xe8, which is greater than the magical number 0xe2, the
number of cycles in a standard NTSC or PAL display. This confuses the chip's
state machine. However, if BPRUN were to end after the 8th cycle (which is all
that's needed to fetch all the data), then BPRUN finishes at cycle 0xe0, which
is legal. This is similar for the other case. The consequence of not being able
to set the DDFSTOP value as far as I need is that in a scrolling NTSC screen
overscaned to the far right, at certain horizontal positions, a vertical bar of
the background colour is displayed instead of the bitplane data. This is
visually ugly, and may have software problems if some gadgets are in that area
which the user is unable to see.BR
Andre
