P96 UAEGFX / PicassoIV LoadView

[arcanist]

I have a program which replaces RTG view with classic copperlist and restores the old view afterwards. It works fine with P96 + UAEGFX but with PicassoIV emulation the screen goes black and fails to restore.

LoadView(NULL) and back with ActiView works with PicassoIV (sort of: the mouse pointer disappears). Any non-NULL View I attempt to load results in the black screen.

The RGBBoxes.c example from here fails in the same way: https://wiki.amigaos.net/wiki/Classi...ics_Primitives

Mostly I just want to know if this works on real RTG cards. UAEGFX is what I'd otherwise be using.

[Toni Wilen]

Test binary required. (I am not going to compile anything )

PicassoIV is quite special because it does not have physical switcher but uses SVGA chip overlay feature to show native Amiga screen. Emulation won't bother with it and switches modes normally. Which means switching behavior probably isn't exactly same but normal LoadView stuff should work.

[arcanist]

I've attached the compiled example from amigaos.net. It will LoadView to show some colored boxes, wait three seconds, then restore the original view.

With a clean OS 3.1 install + P96 2.0 (default install options) + PicassoIV emulation in 800x600x24 I see the new view, but restore fails and leaves a black screen. Works with UAEGFX.

[Toni Wilen]

For some reason driver only disables "video capture" bit (used to capture native display) but it never restores original RTG mode SVGA chip registers contents.

I think I have noticed this previously too. It probably is emulation problem because it would make even whdload to not restore the display.

[arcanist]

Great, thanks for the feedback.

On a possibly related note the same test fails intermittently (roughly 1/4 times from clean boot) in a CGX + PicassoIV setup. The display sometimes fails to switch out of RTG (stays on Workbench). This also occurs with a simple LoadView(NULL).

I'll assume it's probably not indicative of something that occurs on real hardware.

[Toni Wilen]

It is possible it is Picasso IV weirdness because normal native/RTG switches work fine, also it works correctly if do LoadView(NULL), wait for mouse button, then LoadView(oldview), from native and RTG mode.

Does example program work if you call LoadView(NULL) before calling LoadView(oldview)?

[AC/DC HACKER!]

Originally Posted by arcanist

Great, thanks for the feedback.

On a possibly related note the same test fails intermittently (roughly 1/4 times from clean boot) in a CGX + PicassoIV setup. The display sometimes fails to switch out of RTG (stays on Workbench). This also occurs with a simple LoadView(NULL).

I'll assume it's probably not indicative of something that occurs on real hardware.

Yup, my real A4000 Picasso 4 and Picasso96 2.0 - the screen and colored (or coloured) boxes stay on the screen. I meant to check your program some time ago, glad I did now. The screen only closes when I press LAmiga+N or M.

Edit: I don't know anything about LoadView(NULL) / LoadView(oldview)...so I'm not commenting about that.

[Toni Wilen]

Thanks. This confirms there is some kind of Picasso IV P96 driver bug and it is not emulation related (except black screen vs showing "last" native image but thats most likely due to PIV Flifi still having last frame stored in flifi frame buffer).

[AMIGASYSTEM]

Toni if I run RGBBoxes on a screen UAE Zorro III disappears the mouse arrow

[Toni Wilen]

Only if hardware sprite is in used. Does not seem to be emulated related either.

Perhaps this is (partially) related to above PicassoIV bug because uaegfx Picasso96 SetSprite is called to deactivate hw sprite when rgbboxes starts but it is not reactivated when rgbboxes exits. Sprite stays hidden.

[AMIGASYSTEM]

Toni, I'm not a developer but I think the problem is only in the file that doesn't have a "return".

If you try to run RGBBoxes with a Run >NIL: everything works perfectly with both Picasso IV and UAE Zorro III, no black screen with Picasso IV, no disappears the mouse arrow

Run >NIL: RGBBoxes

[AC/DC HACKER!]

I just ran..

RGBBoxes

with PicassoIV set, then checked between RAM and Z3 mapping modes (all 3) and it ran for a few seconds (not 3 seconds, due to Fast CPU being active..) and not a screen change at all.

Running:

Run >NIL: RGBBoxes

produces..a quick return to the CLI. I'm only looking at all this from Workbench.

"Thanks. This confirms there is some kind of Picasso IV P96 driver bug and it is not emulation related (except black screen vs showing "last" native image but thats most likely due to PIV Flifi still having last frame stored in flifi frame buffer). "

You're welcome. -- Hmmmm...Cool. Thhhhhat's why RGBBoxes shows a black screen with OS 4.x with PicassoIV active, and the WB screen becomes trashed a bit. Seems the bug still exists.

Only for display information.. With OS 4.x, and ignoring SDI hits, with RAM Z3 mapping set to Real Shogo will load and look as it should with 3D Gfx board. Correct colors.

With RAM UAE set PicassoIV isn't even noticed and screens aren't delectable. But this points to the bug you found in Picasso96, I'm betting, which they cleaned a bit.

So, with OS 3.x, stay with UAEGfx..only for time being. Good to know. We all appreciate you checking into it, Toni.

[Toni Wilen]

This is fixed in latest Picasso96 update (July 2019, V2.4.2)

[hexaae]

Originally Posted by Toni Wilen

This is fixed in latest Picasso96 update (July 2019, V2.4.2)

Uh? Where is ti?
Is it free? Where can I buy/dload it?

[Toni Wilen]

Latest versions are not free: http://eab.abime.net/showthread.php?t=95574

[hexaae]

Weird: https://icomp.de/shop-icomp/de/shop.html#filter=* can't find it in their shop.

[DamienD]

I'm sure it's mentioned in another thread... you need to create a login first, then login and now you'll be able to see it in the shop.

[hexaae]

Originally Posted by DamienD

I'm sure it's mentioned in another thread... you need to create a login first, then login and now you'll be able to see it in the shop.

Thanks! It worked...