P96 V3.2.0 released [plus V3.2.1 update]

Caution: Non registered users only see threads and messages in the currently selected language, which is determined by their browser. Please create an account and log in to see all content by default. This is a limitation of the forum software.

Also users that are not logged in can not create new threads. This is a, unfortunately needed, counter measure against spam. Please create an account and log in to start new threads.

Don't Panic. Please wash hands.
  • P96 V3.2.0 has been released today: If you have purchased P96 in the past 12 months, the update is for free - just re-download the file, and it'll be the new version.

    The change log is pretty extensive this time...

    Changes in 3.2.0:

    - P96 now supports a new feature for graphics hardware, dual palette support. On suitable hardware, the palette can be changed mid-screen, allowing to display two 8-bit chunky screens on the same view. This avoids false-color defects on dragged screens on supported hardware. Currently, only the ZZ9000 and UAE emulation support this mode. Note that dual palette is not a feature a typical VGA chipset would be able to offer, i.e. all legacy graphics cards are not able to offer it.

    - A LoadView(NULL) will now re-enable bitplane and sprite DMA as P96 disables them if a non-native screen is displayed.

    - The CGfx emulation returned inconsistent results for the depth of various modes, in particular one of the changes in 3.1.2 broke NetSurf. The latter change was reverted, and the depth values were harmonized.

    - The CVisionPPC driver now also initializes the P5 PCI bridge, using the data from the ConfigDevs in the expansion database if some are found, or otherwise using some default values. Initializing the PCI bridge may be necessary if some tools removed the P5 firmware and thus leave the CVisionPPC uninitialized.

    - The CVisionPPC driver accepts now a new tooltype "MEMORYTYPE". Unfortunately, the CVisionPPC was manufactured with two types of video RAM that require slightly different settings. In case your card does not work with the default setting, add the tooltype "MEMORYTYPE=Old" to the CVisionPPC monitor icon and the driver will switch to the older memory configuration. The default is "MEMORYTYPE=New".

    - LoadView() did not use the same logic when restoring an RTG view from a non-intuition view and thus might have sorted viewports (aka screens) incorrectly. Now LoadView() and MrgCop() are based on the same lower-level function, ensuring that both functions operate alike.

    - While not advisable at all, P96 allows applications to pre-allocate a native bitmap and use this native bitmap as bitmap of a screen to be opened. If this happens, P96 converts planar bitmap data to the chunky VGA representation as soon as the bitmap is loaded to the board. While this is not at all new, some applications still attempt to render into this (now off-screen) bitmap with the blitter as the bitmap is (correctly so) reported as a "standard planar bitmap" by GetBitmapAttr(). P96 now detects this particular (mis-)use of planar bitmaps as backing store for chunky bitmaps and reports them as "non-standard", which helps some applications to avoid blitting by native hardware. Long story short: Don't do that - let intuition allocate bitmaps for you.

    - BltBitMap(), BltMaskBitMap(), BitmapScale() and SwapBitsRastPortClipRect() have been prepared to allow even bitmaps with non-compatible aperture settings on the board such that the P96 management no longer has to through non-compatible bitmaps off the board. While some support for incompatible bitmaps was already present in former releases of P96, support was incomplete and therefore disabled. Re-enabling it may improve compatibility to some applications that assume that their bitmaps always stays on the board - which was actually never guaranteed or ensured.

    - The ENV:Picasso96/DirectColorMask setting was not working, and confused with the debug setting.

    - The BltBitMap function with DirectColorMask=YES did not work correctly for the minterm TRUE = 0xf0.

    - When blitting to a true/hi-color bitplane with a mask, the mask was used inverted.

    - When blitting with DirectColorMask set to Yes to a true/hi-color bitplane, the mask was used incorrectly. The code performs now a (albeit slow) inverse palette lookup, then applies the blit with the correct mask, then blits the result back. Needless to say, this is slow, but correct. Set DirectColorMask to No to get the speedy default operation.

    - BltMaskBitMapRastPort() did not support all combinations of bitmap types and all minterms. Now even blitting from direct color to planar bitmaps work, and some minterms can be accelerated in case the source or the mask is not included.

    - BitMapScale() did not respect the depths of the source and destination bitmap and could have scaled data in the source bitmap that was not meant to be part of the bitmap in first place.

    - BitMapScale() did not reset the temporary bitplane when scaling from a direct color bitplane to a chunky bitplane with a depth less than 8.

    - Blitting from a on-board planar bitplane to a chunky or true-color bitplane did not work at all and could have crashed the machine.

    - SwapBitsRastPortClipRect() did not work with all bitmap type combinations, this was fixed. Note that the call should be avoided anyhow as it can be quite slow and may cause visual disturbance.

    - Due to a timing issue of the GD5446, the PicassoIV scrolled the lower part of a split-screen along with the upper part. This has been fixed.

    - Even though not documented, the GD5446 in the PicassoIV supports 32bit ARGB modes, which were enabled.

    - In case a system bitmap, as for example for the flicker fixer, was allocated with an incompatible bitmap on board, the code forgot to set the board info RGB Format, and thus left the board memory managment in an inconsistent state.

    - Another undocumented feature of the GD5446 is that the chip actually supports the hardware sprite on top of planar memory. Adressing it is a bit tricky, but the driver now supports this. Thus, there is no need for a soft sprite for this particular board anymore.

    - The same trick that allows hardware sprites on planar also works on the GD5434, i.e. the Piccolo64 and related boards, and for that reason, the driver also received an update.

    - The GD5446/PicassoIV video and memory windows are now temporarily disabled while screen dragging is active. The hardware video overlay does unfortunately not respect the screen split position.

    - The PicassoIV GRANTDIRECTACCESS flag was broken on Z-II systems as its absence enabled all blits, even those that require an apperture change. Instead, it should have disabled screen modes that require an aperture change.

    - The PicassoIV check for compatible modes on Z-II systems checked the wrong register and could have returned incorrect results.

    - If the mode of the front bitmap was taller than the height of the back bitmap when screen dragging, some junk could have leaked through at the bottom of the back bitmap. This was fixed by allocating the back bitmap at least as tall as the height of the front mode.

    - The PicassoIV flicker fixer did not turn off a potential screen splitting when enabled.

    - The PIV memory window (and likely the video window) do not work well with double scan modes due to a hardware problem of the Cirrus chip. Vertical interpolation also causes strange effects and is therefore turned off if double scan is enabled.

    - The PIV 32 bit true color modes of the PIV do not seem to allow overlays, and create strange artefacts. Overlays on 32-bit screens are disabled now.

    - BltMaskBitMapRastPort() on planar planes received a special case, speeding up the function somewhat by avoiding the typical double-xor triple-blit, which also avoids flicker for Bobs, e.g. workbench icons, when moved across a planar screen. The special case source plane = NULL also received a special case for planar blits. For chunky blits, the typical cookie-cut masked blit is already speed up.

    - When migrating bitmaps off the card, P96 now migrates the least recently used bitmap first. This helps double buffering applications to keep both their front and their back buffers on the board.

    - On some unlucky coincidence, the intuition V40 bitmap allocation hack that allows old versions of intuition to open an RTG screen could get triggered by accident by applications as well. The whole v40 hack has been reworked and made more carefully. Note that intuition versions beyond v47 (Os 3.2) are not affected as intuition passes the P96 tags into AllocBitMap() anyhow.

    - Fixed a bug in BltMaskBitMapRastPort() which picked the wrong source if the blitter was disabled and the byte-offset into the source bitplane was larger than 64K.

  • Jens

    Approved the thread.
  • Jens

    Changed the title of the thread from “P96 V3.2.0 released” to “P96 V3.2.0 released [plus V3.2.1 update]”.
  • P96 V3.2.0 has a tiny error that will only show with OS3.1.4 or lower, but not with OS3.2, which is what our testers have been using. The error shows in native Amiga screen modes not working any more.

    The new P96 version 3.2.1 is fixing this problem, along with a few other small things:

    - In some cases, when blitting between non-compatible aperatures, the aperture-switch can be avoided because the source, as viewed through the aperture of the destination, is identical to the destination format.

    - Picasso96Mode now also auto-generates double-scanned modes for each regular VESA mode which then generate the classical Amiga Hires 1:2 aspect ratio.

    - In case a mode is changed with the right-hand side gadgets of Picasso96Mode, the mode information in the mode window above is now updated immediately and not only after the mode changes have been accepted. This is much less confusing.

    - If in case of a mode change the maximum pixel frequency is exceeded, Picasso96Mode forgot to update the pixel frequency slider to the maximum possible pixel frequency. Now the proper information is reprinted.

    - The bitmap allocation function did not allow intuition v40 (Os 3.9 or below) to allocate native bitmaps anymore. This has been fixed. Allocation of RTG bitmaps through intuition continued to work. There was no problem with Os 3.1.4 or above.

    - The maximum screen width of the S3 trio and S3 virge chip drivers were limited to 4096 bytes, even though the current algorithm of deriving the value of the row- scan register would allow up to 8184 bytes per row. Thus, the maximum row width was extended, enabling some additional screen modes such as 1024x768 32-bit BGRA.

    Please re-download the file from your order history to get the latest version.