I have had this very same problem since I first got my BVisionPPC card in 2001! I've fiddled with the connection, tried every setting combination there is and it wouldn't go away.
Since then I have ascertained that in my case 2MB of the SGRAM (the 5th and 6th from the base) is faulty in some way - data written to that address range gets garbled up.
I have tested this by writing a small & dirty C program that directly accesses the BVision gfx memory and does a simple write/read/compare loop (which trashes the display even more than the vertical lines
For those of you that get this problem during scrolling/window sizing/moving etc, the problem is caused by the the allocation temporary surfaces in the affected area during blitter accelerated operations. This is especially true if you use smart refresh which saves and restores 'about-to-be-temporarily-overdrawn' areas using blits.
So, what can be done?
In my case, nothing fixes the problem. However, I have a work around that effectively eliminates 99% of the time.
Note - you may have a different address range causing problems so experiment with these values.
1) Open a large WB screen (actual area size, not resolution) sufficient to fill the lower unnafected area. In my case that's 4MB - 1600x1280x16bit is just right.
2) Open a second screen sufficient to fill the affected region. In my case thats 2MB, so 1024*1024*16 is just right. MUI's Public Screen Inspector is pretty handy for this job.
3) Change the WB screen back to your favourite size.
Afterwards, the second screen sits in the affected region and wont move (unless you open several large screens and it gets paged out). This means no more temporary bitmaps are allocated in the affected region and your other screens stay clean.
Before anyone worries that this sounds too much work, the above can be put into a little AmigaDOS script and dropped into your startup draw.
You'll need *something* like this
; Fill the lower unnaffected region with huge wb screen
screenmode >nil: sys:prefs/presets/fillitup.prefs use
; Open our screen in the duff gfxmem area
mui:psi >nil: dudscreen open
; restore wb screen
screenmode >nil: envarc:sys/screenmode.prefs use
...where fillitup.prefs was created using screenmode and dudscreen defined in PSI
NOTE - Im not sure if the above is totally correct - Im at work and nowhere near my miggy!
Anyone needing more info can email me and I'll look it up properly
Make sure it has the highest priority above anything else in there.
I hope this helps you out.
Happy 2K3,
Karlos
