P96 3.0.0 (and later) news and support

[Lustmord13]

Hello, where can I check the version I have installed?

[hexaae]

Originally Posted by Lustmord13

Hello, where can I check the version I have installed?

Recent versions (using the installer) put a version file in ENV:

type env:Picasso96/Version

Picasso96API.library 2.455 (29-Lug-2023)
©2023 iComp


REQUEST:
I would like the version to be added also to the string in $VER: (as a comment, before "©2023 iComp"... e.g. "3.4.0 ©2017-2023 iComp") also in LIBS:Picasso96API.library... It would be easier and more reliable than an extra file in ENV: IMHO

[Lustmord13]

Originally Posted by hexaae

Recent versions (using the installer) put a version file in ENV:

type env:Picasso96/Version

Picasso96API.library 2.455 (29-Lug-2023)
©2023 iComp


REQUEST:
I would like the version to be added also to the string in $VER: (as a comment, before "©2023 iComp"... e.g. "3.4.0 ©2017-2023 iComp") also in LIBS:Picasso96API.library... It would be easier and more reliable than an extra file in ENV: IMHO

Thank you.

[mfilos]

Just tried the new version today and all works just fine (as it did with the beta version that Jens send me a while back).
Nice job all and thank you ThoR for your continuous work <3

[Thomas Richter]

As promised, here are the list of bugs this release addressed - and the one mfilos mentioned is one of them.

First of all, the 3.3.3 release included an additional feature to signal DPaint V that the bitmaps are in fast memory. Unfortunately, this hidden undocumented flag fired back as some programs passed the flags back into AllocBitMap(), and P96 refused to allocate such bitmaps. This flag is now ignored.

There is a small extension for BVision and CVision. The driver now supports now the "MEMORYCLOCK" tooltype which allows to set the memory clock in MHz. This is only the clock to the memory, not the pixel clock. P96Prefs is now also aware of this new tooltype.

Then, we have the bug mentioned above - ClearEOL and ClearScreen are two functions that were probably designed to support the console, but the device works completely different and does not (or no longer) use them. They are supposed to erase the bitmap from the cursor position up to the end of the line, by one font height, or to the end of the screen. Why that is exactly useful I do not know - but the functions computed the end of the line from the bitmap "modulo". This, of course, would also erase window borders, and it is incorrect for anything but planar bitmaps. Instead of using GetBitMapAttr(), the function peeked the bitmaps, and that is of course nonsense for non-planar bitmaps. P96 patches now the two functions by work-alikes, but using the proper graphics functions for determining dimensions. Apparently, nobody used these rather exotic functions the last 30 years...

Then, we had the "GRANTDIRECTACCESS" flag which allowed programs (mostly 3D) direct access to the frame buffer. However, switching to planar erases the "CHAIN4" flag of VGA cards, and this reorganizes the memory completely (i.e. the VGA graphics processor becomes active) such that the memory contents will be lost (or look completely different). This is probably unexpected by such programs, and thus planar is turned off if GRANTDIRECTACCESS is set. Then the planar emulation kicks in.

Then, the installer forgot to install the correct cirrus driver for the PicassoIV due to a simple oversight.

There was a useless restriction of the horizontal resolution for the S3Virge. The driver is a bit more relaxed now and also allows higher horizontal resolutions. The chip at least does.

Then, there were a couple of bugs in P96Prefs, a new version was already put in Aminet a while ago. First, it removed or disabled modes of which the pixel clock was too different from the user selected mode. This made the life of the A2410 driver unnecessarily hard. But P96Prefs also generated modes on some cards these cards could not even support.

Finally, there was a quite exotic bug concerning screen dragging. P96 disables screen dragging if the frontmost (dragged) screen is panning. This is necessary because VGA only supports panning above the screen split position. To check for panning, P96 compared bitmap modulo with the mode width. However, this is not quite correct because some cards such as the A2410 require the bitmap modulo set to a particular value. This is a restriction of the video RAM being used and its shift-register size. Now, there is only one card which supports screen dragging and has video RAM, and that is the A2410.

The number of defects is declining, so this is slowly converging ....

[mfilos]

Fantastic post there ThoR! Thanks for the thorough explanation of the changelog!
Update feels rather solid and P96Prefs was always so handy so it's nice that's it's included on the P96 installation
Btw I saw there was a newer version of P96Prefs on Aminet today (than the one on P96 3.4.0 archive). Why's such a great difference in size on the binary? (70Kb of v47.9 vs 125kb of v47.10)

[Magic]

Thank you again for another update!

[Thomas Richter]

Originally Posted by mfilos

Btw I saw there was a newer version of P96Prefs on Aminet today (than the one on P96 3.4.0 archive). Why's such a great difference in size on the binary? (70Kb of v47.9 vs 125kb of v47.10)

Stupid choice of compiler options, thank you. I reuploaded.

[Rotzloeffel]

Originally Posted by Thomas Richter

Stupid choice of compiler options, thank you. I reuploaded.

[crazyc]

Likley that I have done something sily, but here goes. I purchased the latest P96 the other day, and used the installer to install it over a previously purchased version from 2021.
This is running on an a1200 with mediator and Voodoo 3 and with a screen res of 1024x768 (from memory).
Normal icons are fine but icons within WBDock2, ibrowse, and Trident etc are all messed up. Itsa relatively clean installation of AOS3.2

I upgraded to see if it fixed an issue I had when running Raid over Moscow - when exiting the game the pointer remained invisible - managing to launch and then quit another game (via Igame) solved it.
Upgrading P96 also solved it but then created this issue.

Any advice welcome?
Cheers
C

[Thomas Richter]

Originally Posted by crazyc

Any advice welcome?

Try setting the following tool type in the monitor icon:



NOMASKEDBLITS=YES


There is a known defect in the driver that does not interpret the minterms correctly.

[crazyc]

Originally Posted by Thomas Richter

Try setting the following tool type in the monitor icon:



NOMASKEDBLITS=YES


There is a known defect in the driver that does not interpret the minterms correctly.

Fabulous! Just tried it and it has resolved my issue with the newest p96.

I also see there is a newish pci library and voodoo.card on the elbox website, I will need to try them out as well.

Cheers!

[crazyc]

I picked the higher version number? And that and the voodoo.card are now installed. Havent noticed any issues in the short time since adding them. Warp3d still seems to work.

[crazyc]

Newer voodoo.card still requires the fix that Thomas has explained.

[GWhizz]

Cool

[Thomas Richter]

It would actually be much cooler if Elbox would finally get their software fixed...

[Thomas Richter]

The P96 driver API is actually open, so there is nothing hidden. The Os API is equally open. I wonder why Elbox does not simply look into the documentation? What is simply wrong here is the interpretation of minterms when blitting. The issue here, in specific, is that blitting through a mask with BltMaskBitMapRastPort() goes through 3 blit-operations - NotXOR, M and NotXOR - where M is the minterm passed into BltMaskBitMapRastPort().

If you look into the Os documentation for the above function, then M should be set to 0xe0 for a correct blit. From the above blit description then follows that the function "does the right thing", essentially the "double-xor trick". This minterm corresponds to "OR".

However, it seems that Elbox instead implements the minterm 0xc0, which is the usual "cookie cut". That is in most cases - for regular biits - what users typically want, but it is *not* the right thing for masked blits coming through the above Os function. Your blitter needs to be more complete and implement all minterms, and not just some.
If the graphics hardware does not or cannot implement "OR", the driver can also perform a "software fallback", and everything would also be good, there is the possibility of software fallback.

Apparently, Elbox neither read the Os specification of BltMaskBitMapRastPort(), nor the P96 documentation (historically, they just stole it without ever paying for it through the original authors), and now as the specs are freely available, they leave customers alone.

Concerning P96 development, sure it is still under development, though it also depends on customers providing feature requests to drive the direction of development. Due to such requests, screen dragging, multi-monitor-support, EHB emulation and monitor size specification made it in P96.

[Thomas Richter]

Hi folks,

as it seems, the current version of P96 is not compatible with the Draco, and for that reason, I'm looking for Draco owners that would be willing to help me i research and testing.

Thanks,
Thomas

[Thomas Richter]

P96 has nothing to do with 3D, and it does not interface any 3D hardware. It only provides other software with access to the 3D register set. I can only suspect that you are using the wrong video mode for 3D rendering, i.e. try to use a different apperture setting (e.g. try the 16 bit High-color "PC" modes instead of the 16 bit native modes, or vice versa.). Thus, whatever you observe is very likely not related to P96, but only to the settings you have made. Please also study the P96 manual to check how to enable the complete list of video modes boards offer.

Long story short: No, there are "no performance fixes" coming since there is nothing I can possibly fix on my end. Warp3D is a product of a third party, and I neither have the software, nor the hardware.

[Thomas Richter]

As I'm currently on vacation, I had a little bit of spare time and created a new independent P96 driver for the VA2000 graphics card from mtmn. Lukas kindly provided a sample a while ago, so I had something to play with.



https://eab.abime.net/attachment.php...1&d=1704381791


This driver is not based on the reference driver, but a new implementation based on the FPGA logic documented in the verilog sources. The advantage over the reference driver is that it does not only allow a predefined set of resolutions, but you can make your own with P96Prefs. Unfortunately, as I do not have the flicker fixer (the VA2000CX), I cannot test this part and I would need a bit of help, thus feedback welcome.


The driver is configured through tooltypes:


DISPLAYCHAIN=yes|no configures the availability of the flicker fixer. If yes, then it is assumed to be present, and you should be able to switch between the native amiga video and the va2000 output, both appear on the HDMI output of the VA2000. This would need to be tested.


There are unfortunately two firmwares for the card, one that supports a 1280x1024 resolution, and one that supports a 1280x720 resolution. The difference is second pixelclock - both firmwares support a 40Mhz clock, but the second clock is either 100Mhz or 75Mhz, depending on what is flashed on the card. Unfortunately, there is no auto-detection possible, so you have to tell the driver:


OSC2=100000 is the 100Mhz version, for 1280x1024. Unfortunately, 100Mhz pixel clock is too high and does not allow true-color output at this resolution.


OSC2=75000 is the 75Mhz version which supports 1280x720, but also in truecolor (hopefully, I have not tested).


Then, we have a couple of tooltypes that configure the flicker fixer.


CAPTUREWIDTH=<640> is the size of the captured amiga video. 640 is the default.


CAPTUREHEIGHT=<480> is the height of the captured video of the flicker fixer.


CAPTURELEFT and CAPTURETOP are the left and top edge of the captured video.


Finally,



CAPTUREPHASE=-16..16 configures the phase of the amiga video sampling relative to the 7M clock of the amiga. This is board-dependent and need to be configured such that edge-flickering disappears.


A word on the mode configuration: While it is possible to configure custom modes with P96Prefs, the card only has two pixel clocks which means that the small resolutions are "too fast" and the "high resolutions" are too slow. With default parameters, the 640x480 configuration operates at 90Hz, which is too much for most monitors. For that mode, you need to enlarge the horizontal and vertical frame size to provide usable configurations. There is no border since the output is all digital anyhow. For 1280x1024, the 100Mhz pixel clock is too low, and you need to reduce the frame size somehow to increase the refresh rate. P96Prefs is currently not aware of such pecularities, so you have to play a bit with this yourself.


Anyhow, feedback welcome, in particular for the flicker fixer.