P96 V3.1.2 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.
  • Although the last update of P96 is less than a month old, we have a huge round of updates for new and existing P96 customers. The update is free if you have purchased your license of P96 in the past 12 months. To access any downloadable file in our shop, please log into your user account and navigate to the "order history" page. Please note that download products are not shown without logging in, as a guest does not have the "order history" page.

    • In case the display was switched from a display that is not in the chain to the native output, connected to another card that is in the display chain, then P96 did not de-activate the monitor switch of the other card, and hence the display remained blank.
    • Added the 320x240 and 320x200 mode templates to P96Mode.
    • The vesa mode templates of P96Mode lacked the sync polarity information. They have now been added.
    • In case allocating an additional screen buffer for screen dragging does not work, V3.1.1 failed. V3.1.2 now falls back to an earlier method of migrating the front viewport and re-allocating it, requiring a roundtrip of the display contents through system RAM.
    • In case the board did not indicate the presence of the blitter, memory reorganization for screen dragging might not have worked at all, and thus screen dragging may have failed. This also hurt the ZZ9000 which, besides having a blitter, does not indicate its presence to P96.
    • In case the native Amiga output does not have any visible screen, it is now turned off and the background color is set to black.
    • The flicker fixers are now only turned off if a board on the display chain becomes active. Otherwise, the native display generation remains untouched.
    • In case no active screen is available anymore on a given monitor, the corresponding monitor is now blanked.
    • When allocating the frontmost bitmap, the memory handling only migrated front and back bitmap if no blitter was available for moving memory around. It now migrates all bitmaps.
    • The picasso96api.library now returns the CVisionPPC big-endian modes with increased priority to ensure tools use these modes with priority. This may help to get some programs to work that assume a particular display organization without checking what they get or need.
    • The same modifications have been made to the emulation.library, which is responsible for emulation of the villageTronic API and the cybergraphics API.
    • Note that while the above modifications make big-endian modes preferred modes, not all graphic modes may be available under all situations. In particular, if GRANTDIRECTACCESS is set, modes that require an "aperture switch" are not. In particular, the ARGB mode on the CVisionPPC requires such a switch to be made, and is thus not available, unless GRANTDIRECTACCES is not set.
    • The CGfx emulation indicated the depth of the ARGB modes as 32bit, though the original CGfx API indicates depths of such modes as 24 bit. This got fixed, and alpha is not included in the depth computation for emulation purposes.
    • Some programs seem to call LoadView(NULL) in supervisor mode. Note that this function is not supervisor-callable, though P96 now adds a workaround that executes at least some of the code in supervisor code. (*)
    • The P96 Installer script now explicitly sets the user level to "Intermediate" before continuing with the question whether to install the software. This is necessary as the "novice" user will never be asked, and therefore the user will never be asked, looping/waiting forever for confirmation.

    Please mind that some of these updates are an effort to work around bugs of other programs. Especially (*) was an attempt of getting basically-broken software to work. In detail, a few demos have been reported that use this function call. However, our workaround was not successful, but also not harmful to compatibility with good software. Please note that this is not a standard thing for iComp to try - the prime directive should be to fix broken software at the source, and not add workarounds where they don't belong.