HighGFX screenmode flicker

[TheGoose]

I have been testing out an AGA Indivision card in a A1200 recently and it works / looks really great in all the old NTSC modes.

I've added the HighGFX drivers, and although they come up and look crisp and great, it's like there some odd screen noise, flicker, traces and just oddness about them that does not happen with the NTSC mode - which is rock solid.

How to trouble shoot this - what is to blame? Is this just normal?

Things I have done:

1. tested on 2 different LCD monitors, same issue can be seen with HighGFX

2. shielded the cable with foil and warp - had no difference really.

3. began to think it got worse with time, heat (a cold fresh start, looked good)

4. Downloaded the config software and played with that some.

Got some experience?

[tone007]

I've noticed a bit of ghosting with my Indivision that I attribute to the short length of ribbon cable used to get from the Indivision to outside the 1200, also, while the Indivision is a VERY good flicker fixer, interlaced modes through it (like HighGFX) aren't quite as solid as non-interlaced modes and moving objects (like the mouse pointer) get jagged edges.  These effects seem far less noticeable on CRTs.

[Cammy]

I had the same problem with strange weirdness beginning to appear on the LCD screen over time. Eventualy it became unbearable so I switched back to a CRT monitor, which is fine until it starts having this horrible sync-losing problem where the monitor flashes black, then back to normal, then black again a hundred times a minute.

The Indivision is awesome when it's working, but it's always just a matter of time until it starts going bad and you need to reboot if you're using HighGFX.

[TheGoose]

Yeah, expectations are to just use the modes that prove to work really well ( NTSC High res laced ) I don't want to try and 'fix' a thing that really isn't broken, just has some limitations.

Thanks again guys.

[amigadave]

I had the same problem with strange weirdness beginning to appear on the LCD screen over time. Eventualy it became unbearable so I switched back to a CRT monitor, which is fine until it starts having this horrible sync-losing problem where the monitor flashes black, then back to normal, then black again a hundred times a minute.

The Indivision is awesome when it's working, but it's always just a matter of time until it starts going bad and you need to reboot if you're using HighGFX.

This kind of behavior should be reported to Jens at Individual Computers, just in case he does not already know about the problem.  It sounds like a software problem with the drivers if the Indivision display consistently degrades over time while using it and then reverts to working correctly with each reboot, or cold start.

I have not been using my A1200 w/IndivisionAGA lately to experience this behavior and thought that it might be the LCD monitor's fault when I first read about it, but that does not seem to be the case from what is described in the quote above by the best looking Amiga user in the World. :rolleyes:

[tone007]

As a sidenote, I've tried HighGFX on the rare monitor that does support it without an Indivision, it's seriously unusable, so I have to say the Indivision does a pretty nice job with it.

[omnicron10]

I remember reading about the higher modes causing problems on the AGA chips due to more heat they create.  Putting some heatsinks on the AGA chips might help with the issue.  Before IndivisionAGA these modes were unuseable.

[TheGoose]

@omnicron

I agree. This is what my post is describing... I think:

1. AGA indivision is fine, works great with legacy drivers.

2. HighGFX is problematic. And do think heat is an issue here...

[amigadave]

I remember reading about the higher modes causing problems on the AGA chips due to more heat they create.  Putting some heatsinks on the AGA chips might help with the issue.  Before IndivisionAGA these modes were unuseable.

That makes good sense.  As the chips heat up, or overheat, the image begins to degrade.  If this is the cause then a reboot would only clear the problem for a shorter period of time, as it would take less time to have the chips overheat again, if it took any time at all.  A cold boot would be more effective and last longer, depending on how long the Amiga was allowed to cool down.

With this in mind, it should be fairly easy to confirm that the problem is being caused by heating up of the AGA chips, and fairly easy to resolve with heatsinks and/or better cooling by use of a fan.  I'll have to do some testing when I get a chance.


Edit: If the problem is due to overheating of the Lisa chip that the Indivision is clipped on top of, that may be hard to cool off and resolve the problem.

[tone007]

The whole thing (Indivision) does seem to get pretty darn warm.

[Ratte]

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/BitmapShades

Additional ... 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=Translate

Some CBM notes about the AA-ChipSet:

Code: [Select]

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

[NovaCoder]

@omnicron

I agree. This is what my post is describing... I think:

1. AGA indivision is fine, works great with legacy drivers.

2. HighGFX is problematic. And do think heat is an issue here...

It's not a heat problem, well not directly anyway.  We went through all of this over on EAB, we even got Jens on the case

It's down to one of the numerous AGA MB bugs (which are well documented).  I was getting all sorts of weird visual crap going on until I performed a HW fix on my MB, now my Indivision puts out a rock-solid display in ALL screen-modes

[amigadave]

It's not a heat problem, well not directly anyway.  We went through all of this over on EAB, we even got Jens on the case

It's down to one of the numerous AGA MB bugs (which are well documented).  I was getting all sorts of weird visual crap going on until I performed a HW fix on my MB, now my Indivision puts out a rock-solid display in ALL screen-modes

Care to share what that HW fix on your mobo was with the rest of us?

[NovaCoder]

Care to share what that HW fix on your mobo was with the rest of us?

Yep sure, you can read about the whole sorry story right here

[TheGoose]

That's it. 15-20 mins and I got the issue - dude - Nova thanks for info! My test tonight matches this other thread right on. Still reading...