P96 V3.3.0 released

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.
  • The new version of the RTG driver P96 is available for all existing and new customers. New features include:

    • This release of P96 adds one new feature, namely in-screen mode switches. This allows on advanced graphics cards mixing of high-color/true-color/true-alpha and chunky modes, depending on the flexibility of the hardware. This requires from the driver to implement extended interface functions.
      • PicassoIV allows mixing high-color and chunky modes on the same screen. True color and true-alpha modes cannot be mixed with each other or any other modes. Hi-color modes mixed with chunky screens have pixels of twice the width.
      • CVision3D supports very flexible mode switching as almost any modes can be mixed. The only exception is that double scanned, interlaced, double-clocked (very high resolution) modes or modes with more than 4095 bytes per line do not allow mode sharing. The pixel aspect ratio is not affected.
      • As a side effect, the CVision3D supports now also draggable True-color screens. They could not be dragged before.
      • The UAE emulator supports flexible mode sharing of all modes without any restrictions, leaving the pixel aspect ratio alone.
    • P96 3.3.0 comes with a driver for the Retina (Zorro-II version) graphics card based on the NCR77C22E+ chip. Please do not confuse this card with the RetinaZ3BLT, which is a different card which was supported already. This driver requires mmu.library to be installed, because the Z2 version of Retina uses banked memory access.
      • The Retina Z2 offers a hardware sprite, hi-color and true-color support, but no hardware acceleration. The sprite is not functional in true color mode (or rather, would only offer shades of grey as colors).
      • If you receive the error "Direct MMU setup failed to work" from the MuEVD shapeshifter driver with the RetinaZ2, update MuEVD to release 47.1 or edit the ENVARC:MuEVD.Prefs file and include there the option "REF=Yes". This turns off remapping of the MacOs screen to the RetinaZ2 framebuffer.
    • P96 3.3.0 also comes now with a driver for the Visiona graphics card based on the INMOS IMSG300 chip.
      • Note that this card is notoriosly hard to configure and hard to use, as its output is not complying to the VGA standard, but rather to TV standards. Many LCD displays may not be able to show the signal generated by this card, though older CRTs should be able to show its signal. Your LCD may require to support either composite sync or sync on green, and it may be required to cut the "VSync" output of the card and connect HSync to the composite sync input.
      • Visiona (and the IMSG300 chip on it) do not support a sprite nor offer a blitter, thus operations may be relatively slow. Neither does the chip offer panning, nor does the driver currently support interlace. The latter is due to a restriction of the chip which requires particular display width for interlaced screens.
      • The Visiona driver is configured through the "SYNC" tool type, which can be either set to "tesselated" (default, recommended), "composite", "separate" or "green". The latter activates sync on green. Unfortunately, the "separate" sync signal is not VGA compatible and thus not suitable for most modern monitors.
    • The S3 Virge chipset driver on the CVision3D has been extended again and now also accelerates planar to chunky conversion.
    • The vertical position of S3 based double-scanned views was computed incorrectly and doubled the vertical position. You may have to adjust your double scanned modes a little bit.
    • The S3Virge allows unfortunately not to enable double scan on double-clocked modes. Thus, double-clocking is now kept disabled for double- scanned modes, which limits the resolution of double-scanned modes to approximately 1152x432. 1280x512 is not possible without overclocking, but 1280x1024 remains available as it can be double-clocked.
    • The S3Virge stream processor is (at least for some steppings) not able to generate pictures wider than 4095 bytes. In this case, the stream processor is turned off and display generation is forwarded to the legacy VGA engine. This also requires disabling memory windows on such modes.
    • The hardware overlays of the S3 and PicassoIV checked whether their apperture settings were consistent with the apperture setting of the screen they appear on. However, this check is no longer required as the 3.2.x release series supports on-demand apperture switching.
    • Due to a missing bracked, the P-IV video window (e.g. for PalomaTV) was initialized incorrectly on the first pass, leading to incorrect clipping. Once the window was moved, everything was fine again. This problem has been fixed.
    • Screen dragging support for the RetinaZ3Blt was broken, and probably never worked. This should hopefully work in this release now. The same problem goes for the Altais card which is based on the same chip driver.
    • The CPU-driven chunky to planar conversions have been rewritten and as such got hopefully somewhat faster. The old roxl-based approach has been replaced by a "folding" algorithm.
    • The CPU-driven planar to chunky or direct-color blitting algorithms have been rewritten and hopefully accelerated. The roxl-based algorithm has been replaced by a table-based algorithm.
    • The CPU driven masked planar to chunky or planar to direct blitting has been rewritten and is hopefully faster than before. This code now also supports interleaved sources without kludges.
    • The logic that re-enabled DMA when a previous RTG screen had turned it off as it wasn't still quite right. It did not turn on DMA if the new view to be loaded was non-NULL, but a native view, and it turned on the sprite DMA even though it should not.
    • P96 now turns the display off when switching between planar and chunky modes. This avoids some color distortions while switching.
    • If a task changed the colors of an off-monitor screen, P96 erraneously changed the colors of the front-most screen of the same board.
    • When double clicking on a mode in P96Mode, the mode now also becomes the active mode being edited, and all mode informations are updated accordingly in the gadgets below.
    • When the display was switched away from a board with a flicker fixer such as the P-IV, though the target board was not in the display chain, the flicker fixer got disabled, even though it should have stayed on to mirror the native screen that then remains visible.
    • When modifying or testing a mode with P96Mode, it could have happened that the mouse could not be moved within the entire screen. This was due to a defect in the rtg.library when creating a temporary mode.
    • In case a board does neither provide a mouse cursor nor a blitter, but apperture mapping, P96 incorrectly passed the pointer to the mouse cursor through the aperture mapping algorithm, potentially damaging the mouse pointer colors, or even main memory.
    • p96BestModeIDTagList() also delivered modes smaller than the requested view. While possible, smaller modes should be penaltized more and thus the algorithm was slightly modified.
    • The cgxBestModeID() function did not handle modes smaller than the requested modes properly either because it worked with the dimension difference as unsigned rather than signed number.
    • P96 now includes a substitute of the BestModeID() function of the Os which provides a suitable ModeID under constraints given by the caller. Unfortunately, the Os function makes assumptions on the suitability of a mode due to its pixel speed, which is irrelevant for the purposes of P96. Also, the Os function only allocates modes within a given class of monitor IDs, whereas P96 allocates a separate monitor for each resolution and thus would not find a mode of a size different from that of the monitor provided.
    • The P96 guide has been reworked, the list of tool types monitor icons take have been extended and checked, and the list of environment variables have been extended and checked as well.
    • The P96 guide contains now considerably larger section on the P96Settings program and how to create your own video modes.
    • The P96 guide now also contains an FAQ (frequently asked questions).

    We'd like to remind everyone that P96 is commercial softweare. Distribution on "warez" sites or file sharing is illegal and endangers future development of P96. We'd like to express our gratitude to members of the Amiga community who have stopped some violations even before they have been published.

  • Thanks for releasing driver version 3.3.0.

    After I installed the drivers under amiberry 5.1 on my Raspberry Pi 4, as always,

    I was amazed to get this error message after a reboot:

    This selection screen is new to the installation:

    I didn't select either of these the first time as I had previously selected the Picasso IV driver.

    Under Devs/Monitors I then renamed the driver to uaegfx and set "BOARDTYPE=uaegfx" in the properties.

    While the first time I updated an existing version, the second time I did a clean install after previously uninstalling

    the existing driver. The error was the same.

    The third time I selected "Retina" in the selection screen and then renamed the Retina driver to uaegfx etc., but had

    no success.

    Before each attempt, I uploaded a backup copy of my HDF file. I used AmigaOS 3.2.1.

    There were no problems with the Picasso driver version 3.2.4. From this version I had also tried the updates.



  • We also have a report about WinUAE not working correctly, and it seems like there's an error in the core UAE, which (to my knowledge) is also what you're running on the RPi4. Toni is on it, but I wouldn't know who to talk to for the RPi/Linux version.

  • We also have a report about WinUAE not working correctly, and it seems like there's an error in the core UAE, which (to my knowledge) is also what you're running on the RPi4. Toni is on it, but I wouldn't know who to talk to for the RPi/Linux version.

    Hi Jens,

    I'm the developer of Amiberry, which runs (among other platforms) on the RPI as well.

    I usually merge in any upstream changes from WinUAE directly into Amiberry, so if Toni is working on a solution perhaps it's best to wait until he publishes that, then I can merge it from there.

  • That sounds great - the error Toni is working on is about screen dragging with different resolutions. I haven't looked into the discussion on EAB - busy with other things.

  • Funny that someone is actually asking, when we got so much criticism about the splash screen that Indivision shows :-)

    However, I don't think something like this belongs into P96 itself - it should be a tool that you put into your startup-sequence.

  • Anyone experienced flickering with the game Napalm: The Crimson Crisis? Looks like a double-buffered screen is switching buffers at the wrong time (in the game, it just exchanges the playfield with the load game list rapidly). It was ok with P96 V2.

    Using Minimig actually, but I wonder if it works with other drivers in P96 v3.3.1?

  • The last reply was more than 365 days ago, this thread is most likely obsolete. It is recommended to create a new thread instead.