Picasso 96 driver for ECS/AGA

[samplist]

I'm using the P96 native driver in OS3.2 with the P96 install from Aminet and I'm getting these artifacts in images. Does the native driver work with OS3.2 or is there some special setting to make it work?

[Bruce Abbott]

Originally Posted by samplist

I'm using the P96 native driver

Why?

[Thomas Richter]

Originally Posted by samplist

I'm using the P96 native driver in OS3.2 with the P96 install from Aminet and I'm getting these artifacts in images. Does the native driver work with OS3.2 or is there some special setting to make it work?

This surprises me and I wonder whether there is anything else installed on the system, and whether this is a native system instead of an emulated system. The P96 blitter replacement functions which are active here are well-tested.

There should be nothing specific about 3.2 that triggers such defects, but since I don't have 3.2 to reproduce, could you please provide a minimal example on a 3.1 or 3.1.4 system that triggers the problem and I can have a look then.

PS: Please also provide the version of P96. The 2.x in the Aminet has some known bugs. 3.1.0 is the latest, I will only fix bug there. 2.x is "end of life".

[samplist]

This is on a vanilla OS3.2 install on WinUAE, nothing else installed on top.
It even produces these artifacts with the uaegfx driver. I cannot reproduce it on OS3.1.4 so it may well be an issue of OS3.2.

[Thomas Richter]

Problem 1) WinUAE. Please try native hardware. This may be a blitter timing issue.

Problem 2) You still owe me the version of P96.

[samplist]

I tried in my A1200, the issue is still there.
I'm using the version from this archive https://aminet.net/package/driver/video/Picasso96
I've also tried replacing the rtg.library with the one found in http://lilliput.amiga-projects.net/AIAB.htm apparently it is a newer version, but still the same.

[Thomas Richter]

All pre-2.4 releases of P96 have a bug in BlitMaskBitMapRastPort(), which may be the reason for the problem here. This bug was fixed quite a while ago in the 2.4.0 release. The latest release of P96 is 3.1.0, which you can buy here:

https://icomp.de

It would surprise me if beta testing internally would have left such an obvious defect in the code. Hence, please update P96, and then try again.

[PeterK]

Check your P96 settings (PVS) for possible conflicts (i.e. Don't use Amiga Blitter).

attachments removed

[Thomas Richter]

Originally Posted by PeterK

Check your P96 settings (PVS) for possible conflicts (i.e. Don't use Amiga Blitter).

This would also suprise me. All the native driver does (it's not really a driver) is to set "DisableAmigaBlitter" to "YES" and set "PlanesToFast" to "Yes" either.

My best guess I gave above, but please understand that there is no support for obsolete versions of P96.

[PeterK]

Ok, thanks for that info. I didn't know that "Native" enables these two settings by default anyway.

@samplist
Don't use WinUAE beta versions for your experiments, try the latest release of 4.4.0. That should not mean that the betas are buggy, but you never know ...

Update: I've tested a little more and it seems to be a problem with the rtg.library. So either buy a newer P96 or use FBlit instead.

[samplist]

Hey @PeterK, nice that you could reproduce that as well, also I'm using WinUAE 4.4.0 as you suggested .
Thanks for your help and all the info @Thomas Richter and @PeterK
it's also good for others to know that Native doesn't play well using the free version of P96 and OS3.2 and that this is somewhat expected.

[Swe_Kryten2x4b]

Originally Posted by samplist

Hey @PeterK, nice that you could reproduce that as well, also I'm using WinUAE 4.4.0 as you suggested .
Thanks for your help and all the info @Thomas Richter and @PeterK
it's also good for others to know that Native doesn't play well using the free version of P96 and OS3.2 and that this is somewhat expected.

Indeed. I also noticed those weird artefacts in some dialogs using the native "driver" and the free P96 version using 3.2. But since the fee for the registered version is so low I decided to buy it, and that fixed it indeed (using real hardware obviously, A1200 in this case).

[paranoicb]

Originally Posted by nickey

Laszlo 'Pheonix' Torok (developer of MooVid, Savage shapeshifter driver), wrote that a very early version of P96 AGA driver was ready in 1998...

source:
https://groups.google.com/forum/#!to...re/PYixqghlhog

This is awesome if it was somewhere around to test it.
With todays accelerators we have in our hands this would be helpful to develop a native driver for ECS/AGA machines on a nice P96 addon driver. I would pay some bucks to have a native driver to mask RTG modes.
Where is László Török today ? can we contact him for this project ? Is he still around on the Amiga scene ? an email maybe or a FB account ? This project needs a revival. I would love to contact László Török to share some light. any info would be helpful.

[shelter]

I'm trying the native driver instead of using fblit/ftext however I noticed some programs that initializes the cybergraphics.library fail to load with the native driver.
If I remove the native driver, the program runs, but depending how it's written it outputs "failed to initialize the cybergraphics.library" (but starts fine).

Is there any way around this?

[Predseda]

I have a problem with P96 native driver, that was also confirmed by other users. If "native" is in Devs/Monitors, Deluxe Paint (no matter if OCS or AGA version) has completely broken brush function (and some other functions that use line crosshair pointer, like Elipse or Circle). Just try - launch Dpaint, press B for brush (and try to grab something in case of AGA version).

If I remove "native" from monitors and reboot, Dpaint works normally, but I have less chipmem.

Who can I complain / report this to?

My hardware is Amiga 1200.

[Thomas Richter]

Again, tihs would surprise me as I had this tested. Please report the version of P96. Note that the version on Aminet has a couple of defects, though the latest version (3.3.2) should be fine. If you do own the commercial version of P96, open up a defect report at iComp and I can arrange a beta for you (as for all other customers reporting defects, of course).

[Predseda]

Yes, it is a commercial version bought from iComp. I am not sure which one, though. There is a file named "version" in the package that says "(22.04.22) (c)2017-2022 iComp", but the "native" in Monitors has datestamp 14 Jan 2019. I do not remember when it was purchased.

[DaMi]

Same thing, as Predseda noted, happens in DP IV on my setup. My version of P96 is 3.3.1 (06.06.22) ©2017-2022 iComp, version of Picasso96API.library 2.435 (27.5.2022) ©2021 iComp.
My amiga is A1200, TF1260, AmigaOS 3.2.1, Indivision MK3. The problem occures when I have in Devs:Monitors the Native driver (from Aminet). When I remove it, the issue in DP disappears, but I have less Chip ram.

[Thomas Richter]

As always, please proceed as follows:
- Get the latest P96 version (3.3.2),
- open up a bug report at the iComp forum

I can then provide a beta version (if I can reproduce the issue) with defects fixed. Please understand that I cannot verify myself whether or not you hold a valid license, thus the detour through the iComp forum is necessary.

Thanks,
Thomas PS Please note that this problem may or may not be fixable because DPaint goes for some functions directly on the blitter, bypassing the graphics.library. Such attempts will of course fail if the object to blit is in fast RAM and P96 is not given a chance to intervene.

[Thomas Richter]

Some news on this. I had a look at dpaint - the issue is really that it directly accesses the blitter, or rather that the dpblit.library does so. Of course, this cannot work if the allocated bitplane is in fast memory.

Interestingly, dpaint seems to check for the bitplane attributes, though clearing the BMF_STANDARD does not make any difference. Instead, dpaint seems to depend on some undocumented flags in bm->pad, or some undocumented upper bits that may be returned by GetBitmapAttr() the os or P96 does not deliver.

Setting the undocumented flags in bitmap->pad just causes crashes, so it is at this point unclear what they are supposed to express and how a bitmap structure using such flags are supposed to look like.

There is also a dpcpublit.library which may or may not provide functional equivalents of the functions of the dpblit.library. If dpaint makes the selection between the two libraries, it is not through bitmap->pad or the bitmap attributes, or it expects a layout that is not specified anywhere.

Long story short: dpaint does not go through the Os for some blitter functions. This does not stop P96 replacing Os blitter functions, but it prevents relocation of bitmaps out of chip memory.