P96 V3.2.2 released (now V3.2.3)

The RTG driver P96 enjoys growing popularity: More then 40 paid downloads (more than a third of them for the full price or more) during the weeks since version V3.2.0 has been published, have taken us over the threshold of 30% cost coverage since we've taken ownership of the software in 2016. We'd like to send a big thank-you to the Amiga community for strong support and detailed bug reports in our support forum, which help us improve the software on a regular basis.

• Version 3.2.2 attempts one more time to deal with broken software: If a program like Descent opens a planar screen mode, but combines it with chunky rendering routines, the new version 3.2.2 can display a correct picture despite this evident software error.
• Sprite colours are now switched if the sprite travels from one screen to another in a split-screen environment. This fixes the colour of the mouse pointer during screen dragging.
• masked blitting of planar bitmaps has been fixed: This fixes the "Palette"-preferences program.
• If a split-screen (dragged screen) is used on a PIV-card, the video-window will not be disabled, but will pan together with the front screen. Note that P96 currently does not support video or memory windows on the back screen.

Quote from jd64

Could there be an option to pay a higher amount e.g. €50 which would allow the customer to have a higher downloads remaining limit or even longer period before expiry?

I'd have to do that manually, as the shop system does not allow any connectio between the chosen price and the download expiry date.

I can set the number of downloads much higher at no extra cost - that's arbitrary and needs to be entered into the shop system to have "some" limit there. I'll set that higher for anyone, anytime.

The expiry date is what's most valuable to you, as it means "longer update period". Just let me know what you're thinking of for those 50,- EUR, and we'll make it happen (if it's not totally outlandish...).

Sure, we can do that.

I'd ask you for the details: Please place your order, then I can make the manual change to the expiry date.

Already handled - thanks!

Funny - the 3.2.1 version is not even on the server any more, the file has been replaced. Please re-check what you've downloaded and unpacked - you may be confusing your own downloads.

New version V3.2.3 just uploaded to the page. Changes:

• P96 no longer attempts to set the beamcon0 register and the vtotal register of the custom chips in case the active video mode is on an RTG board that is not in the display chain.
• Even though bitmaps were locked, memory management could have migrated them off the board if memory was getting tight. This may have caused quite some issues on "close-to-zero" memory situations.
• As BlitMaskBitMap was potentially allocating memory for the mask buffer, it could have migrated the bitmaps it was actually supposed to render, causing all kinds of havocs. To avoid this problem, source and target bitmap for a two-bitmap operation are now locked on the board. This is actually a very old bug that goes back to the 2.x release cycle.
• A possible memory inconsistency in P96Mode was fixed where an incorrect memory pointer was released.
• The Altais and RetinaBLT drivers did not record the state of the monitor switch correctly. As a result of this defect, the SetDPMS() function to enable power saving may have failed, keeping the monitor on all the time.
• The rtg.library may have attempted to switch of the Altais display on a Draco system without ever turning it on again.
• Fixed a very old bug on adjusting the line pattern shift upon drawing into multiple cliprects. This bug was apparently introduced while merging my own P96 version with the last official version by the authors. This bug could have introduced artefacts when drawing "marquee" effects for selecting multiple files in alternative file managers.
• When switching buffers on a double-buffered screens, P96 forcibly reloaded the sprite image, which caused flicker on some RTG boards. This version now avoids reloading the sprite unless absolutely necessary.

We do not provide Mediator drivers. The question should go to Elbox - they are the authors of the card drivers. We're "only" providing the bulk of the work, but Elbox must provice the card drivers. They're just a few lines of code that make sure that the chip drivers get the correct address(es), but with the weird license that Elbox has for their PCI library, it appears that nobody but them is allowed to write a driver.

Funny dual-standard-measurements, as Elbox never paid for the developer license of P96 back in the days. Good thing I have made it all public now, taking them out of this legal grey zone.

I have no intention to work with or for Elbox. If you want to back port this driver, please contact Hyperion and ask if they open up the source (and if they're even allowed to, given the funny licensing that Elbox has thought of for their PCI contraption).