P96

From IndividualComputers
(Redirected from Picasso96)
Jump to: navigation, search

Contents

General

P96 used to be called "Picasso96", but since the family of Pablo Picasso does not like this name, we refer to it as "P96" for now and all times. P96 is an RTG software package for the Amiga. It is commercial software, protected by copyright laws. You can purchase a license in our shop. Re-distribution of the new package is not allowed.

The shareware status of P96 V2.0 remains active: Re-distribution of this archive remains legal, as long as no money is charged and no claim about registration is made. The only source for a legal registration of the P96 software package is iComp's web site. This specifically includes the old V2.0 version, which is also the property of iComp GmbH.

A pre-existing license betwen the P96 authors Tobias Abt & Alexander Kneer and Hyperion has been turned into a co-ownership of P96: Hyperion owns and maintains the PPC port of it, which is part of AmigaOS4 and successors. This means that P96 in Hyperion's PPC-based OS does not need separate licensing.

Update V3.4.1

  • P96Prefs was updated. The following defects were addressed: In case a board is ghosted, P96Prefs now prints a reason under the (assumed) board name, either providing information that the board driver is not loaded, the monitor icon was not found, or the settings are not assigned to a board.
  • P96Prefs now requests a reboot in case a board assignment changed implicitly because an installed board was assigned to an already existing preferences setting.
  • P96Prefs now also loads the monitor dimensions from the EDID data and fills them in. Setting the knob position of numerical tool types was not always set to scale correctly.
  • Due to inverted logic, the installer code did not install P96Prefs correctly for newer versions of the Os, but only for older versions.
  • P96Prefs was updated to also support the new VA2000 driver and create modes for it. As the chip has only two pixel clocks, mode-generation is a bit unorthogonal.
  • The Sync-on-green flag of the A2410 board was unfortunately configured with inverse logic. That is, if it was set to NO, it was unfortunately enabled, not disabled.
  • The TMS34010 driver for the A2410 board had an issue with setting up the descriptors for the shadow frame buffer if the page size was small, as on 68030 processors.
  • The TMS34010 uses now a somewhat smarter MMU refresh within which updates due to blitting no longer trigger an MMU refresh, thus potentially speeding up processing a bit as less time is wasted within refresh.
  • The 3DLabsPermedia chip detection is now a bit more careful and protects itself from bus errors when attempting to read the PCI ID from it. This prevents a potential bus error in case the chip is not present.
  • If the P5Init MMU tool is run as part of the MMU-Configuration and there detects a 3DLabsPermedia chip, this information is now also used by the P96 Permedia driver and provides for some configurations a more robust chip detection mechanism.
  • The Draco patches on OpenScreen() and OpenScreenTagList() are now also removed before they are replaced by their P96 counterparts.
  • The Altais card of the Draco did not necessarily enable the video output. This updated release changed the logic for the switch slightly.
  • ReadPixel() run into a hard-coded WaitBlit test in the kickstart, which did not work on Draco. P96 now replaces ReadPixel completely, and patches WaitBlit() to a no-op on the Draco.
  • Draco support should have improved a lot. The Altais card now no longer disables interrupts as the graphics card vertical blank interrupt is used to emulate the native vertical blank interrupt. I'd like to thank Toni Wilen for helping me to trace down this issue.
  • Even if the Amiga blitter was disabled, P96 still used the native WritePixel() function on planar graphics. Now this function is also replaced by a CPU function if the amiga blitter is disabled.
  • The planar version of WritePixel() could not handle screens wider than 2048 pixels. This defect is probably also present in the kickstart implementation of WritePixel().
  • Thanks to an agreement with its its authors, a re-implementation of the GBA-PII++ driver is now included in the distribution and P96 supports now this card from scratch. Thanks, folks!
  • The distribution now also includes an independent reimplementation of the VA2000 driver which is now also selectable from the P96 installer script. This driver supports user-configurable modes and offers hardware-accelerated off-screen to screen blits.
  • Due to an unnecessarily careful check, allocating a bitmap for a video or memory overlay in a YUV pixel type failed. This broke essentially video overlays of the Picasso-IV. Should be fixed now, hopefully.
  • DisplayAlert() now keeps the boards locked, hopefully avoiding that some program trashes the displayed alert while it is being displayed.
  • The Installer script was updated to also offer a Novice user level in which everything is automated.
  • The Installer now also provides a UAEgfx monitor icon if the UAE card is found present.
  • The installer script is now also aware of the new drivers that became available as part of the latest update, namely the GBA-PII++ and the VA2000.
  • The installer did not create default settings for any of the new boards that have been added under iComp supervision. This was because the "AttachSettings" helper program was never updated. This was fixed, and the program now also knows all new boards. However, "AttachSettings" is rather primitive, and P96Prefs should be preferred to create new modes.

Update V3.4.0

  • Added emulation for Extra Half Bright mode. It is enabled along with the planar emulation, see also the release notes of the 3.3.3 release.
  • Planar emulation is now disabled if the board does not support a chunky mode required for planar emulation. This should be really rare, though.
  • Allocation of bitmaps failed in case the bitmap flags still contained the magic DPaint flag that CPU blitting is necessary.
  • Prevents now a crash in case a driver forgot to set the pixel clock of a mode to a non-zero value.
  • The CVisionPPC card driver accepts now the MEMORYCLOCK tooltype which specifies the memory clock in MHz.
  • The graphics.library functions ClearEOL() and ClearScreen() are broken from scratch, including AmigaOs 3.2.2. Luckely, they are rarely used (and should probably be avoided altogether). P96 includes now a re-implementation of the functions that should be safe.
  • If the GRANTDIRECTACCESS tool type is set, P96 now disables the planar mode as it requires switching the Chain4 mode and thus modifies content under the feed of a potential user of the direct access. In such cases, the planar emulation can be used.
  • The installer forgot to install the Cirrus5446 driver for the PicassoIV board.
  • The S3Virge driver installed a maximum horizontal resolution of 1280 for everything beyond highcolor. This limit was increased to 1440 pixels.
  • P96 disables screen dragging on autoscroll screens because VGA chipsets cannot pan the dragged screen below the screen split positions. The current logic for determine autoscroll screens compared the bitmap width with the width of the video mode. This is not quite correct as bitmaps on some cards may be required to be wider than the mode width. On cards using VRAM, the line size must be a multiple of the VRAM shift register size.
  • The CVision3D driver now also supports horizontal resolutions wider than 1280 pixels for high-color modes.
  • P96 now supports even more graphics boards. This time, the RainbowII frame buffer and the CBM A2410 was added to the list of supported boards.
  • The RainbowII is not very exiting as it only supports 32bit TrueColor in either PAL or NTSC, interlace or progressive, thus modes cannot be freely defined.
  • RainbowII was also marketed as FrameMaster from BSC and Elaborate Bytes, the driver supports all three boards.
  • The A2410 was CBM's only graphics board, originally designed by the University of Lowell. It is based on the TI TMS34010 chipset. The chip is an oddity as it does not provide direct access to its video RAM. Thus, its driver needs to play some tricks with the MMU and requires the mmu.library. The TMS34010 chip includes blitter functionalities the driver uses when possible, though still needs to render by the CPU itself into a "mirror framebuffer". Thus, everything will be pretty slow. *Again, note that you need the mmu.library for the A2410*
  • The physical dimensions of the monitor in millimeters can now be put into the monitor icon tooltypes as MONITORWIDTH and MONITORHEIGHT. This allows P96 to compute the resolution of all modes on the monitor. Note that the tooltypes are in millimeters, not in pixels.
  • The P96 distribution includes now additonal contributions:
  • The P96Prefs program is the new style preferences editor. It replaces the Picasso96Mode if the target operating system is Os 3.2 or better.
  • Additonal contributions are the Native monitor driver and the P96ScreenCX commodity.
  • P96Prefs did not compute the monitor limit frequency correctly, fixed.
  • P96Prefs did not check whether the board type as indicated in the board is correct.
  • P96Prefs accepted to create modes the P96 core would refuse to create if they are beyond the bounds registered by the driver.
  • P96Prefs disabled modes if the requested clock frequency differed too much from the actual clock frequency. This is no longer the case.
  • In case more than one board was installed, P96Prefs could have shown a dummy resolution of 320x200 pixels that is only for internal use.
  • Updated the installer script to also install contributions and localizations.
  • Again, I want to thank Samir and Javier for updating the Italian and Spanish catalogs of P96Prefs.

Update V3.3.3

  • Removed installer procedures for the Inferno card as the card driver was apparently never developed. The Inferno is otherwise based on the well-supported Cirrus chips, but information on the card is missing.
  • Apparently, some buggy software expects that the Draw() system call preserves register a1. To avoid compatibility problems, the rtg.library now also restores this register.
  • WritePixel() under a simulated sprite pointer in planar modes might not have worked correctly.
  • In case allocating an interleaved bitplane failed, P96 would have attempted to allocate a planar bitplane, but forgot to clear the magic indicator that the bitplane is interleaved.
  • In case non-displayable bitmaps were relocated to fast memory, brush operations in DPaint 5.0 failed because the program was not aware that the brush bitmap was no longer in chip memory. P96 now sets for bitmaps in fast memory a non-documented flag such that DPaint uses the CPU for blitting. Note that earlier versions of DPaint do not provide CPU-blitting as fall-back mechanism and use the blitter natively, there is unfortunately no way how P96 could intervene.
  • In case a board became inactive because the view went to another board or the native video, the monitor hook was not informed on this change. This may have broken tools such as the indiswitcher, i.e. the indi may have not been turned on again.
  • Conversion blits such as chunky to hi-color required P96 to allocate a temporary buffer. This buffer is now statically allocated upfront and re-used if possible, avoiding unnecessary memory fragmentation.
  • In case planar displays were reorganized due to screen dragging, the planar bitmap could have been damaged, then causing a complete display breakdown.
  • This release of P96 provides a new feature, namely the emulation of planar screens of depth > 4, even on graphic cards that do not support planar. To enable this emulation, set the environment variable EmulatePlanar to YES, e.g. enter the following command in the shell: 
 setenv SAVE Picasso96/EmulatePlanar Yes

and reboot the machine. The "4 bit" modes in the screen requester now offer up to 256 colors, or even appear on graphics cards that would not provide them otherwise.

The purpose of this planar emulation is to promote legacy applications that are not aware of chunky bitmap organizations to RTG screens. For that, configure your preferred mode promotion utility to redirect native screens to the (new) "4 bit" screen modes. This should allow you to run legacy applications on a graphics card, regardless of the graphics card offering planar modes, and regardless of the VGA limitation to at most 16 colors.

  • The function that attempted to remove CybervisionPPC boot ROM patches was not critial enough and might have replaced perfectly fine ROM code with nonsense, then creating crashes. This happens most prominently if a ROM module has been replaced by LoadModule. This error may have created sporadic illegal exception alerts (80000004) in some configurations.
  • If the amiga blitter is not disabled (DisableAmigaBlitter=No) but planes are directed to fast memory (PlanesToFast=Yes), then Bobs such as icons dragged on the workbench screen were not rendered correctly. P96 can now detect such cases and then renders the icons itself instead of depending on the native graphics function.
  • When allocating a displayable bitmap, P96 did not check whether graphics card actually even supports the RGB format requested. The bitmap allocator now fails if a RGB format is requested for a displayable bitmap the card does not support.
  • Some board drivers do not implement blitting through a (spatial) mask correctly, i.e. BltMaskBitMapRastPort() creates artifacts.This Os function is used to "cookie-cut" a shape through a binary stencil. If you see defects on such functions, please add the following tool type to the Monitor icon: 
 NOMASKEDBLITS=YES

Then save the icon, and reboot. This tool type instructs P96 to perform the cookie-cut blit by the CPU in software. Note that "MASK" relates to a spatial mask, and it should not be confused with the mask that selects which bitplanes are affected. The hardware accelerated mask is only used if all planes are included in the blit.

Update V3.3.2

  • The init function of the Visiona driver used one wrong register. This did not do any harm as the erraneous register was populated with the correct value by coincidence.
  • The Visiona driver did not initialize two pointers of the boardinfo structure and could thus not initialize the video RAM caching mode ideally.
  • ReadPixelArray8() should be much faster now as it avoids iterating over lines but performs a full bitplane copy in one step.
  • ReadPixelLine8() should also be faster in case the source rastport has no layer as several levels of the call tree are now skipped.
  • Blitting from a chunky or planar screen with a min-term that combines source and destination into a high- or true-color screen goes now always through an inverse color lookup as otherwise the result is not quite what you would expect. Inversion, direct and inverted copy are still accelerated. For example, the locale preferences were broken in direct color modes (16 bit, 24 bit, 32 bit) due to this unexpected blit result.
  • P96Mode now avoids creating interlace modes. If the vertical rate is below 45Hz for a hand-made mode, P96Mode attempts now to increase the pixel clock to avoid interlacing the mode.
  • P96Mode will now use the templates for Vesa modes also if the user attempts to create a custom mode whose size fits that of a known VESA mode. P96Mode previously used a heuristic to create such modes.
  • Added support for another graphics card, this time the rather exotic GVP 110 EGS, the high-end graphics card from GVP based on the INMOS G364 chip. The card supports a hardware sprite and 8 bit chunky and 32 bit true-color modes. Unfortunately, the 15 bit and 16 bit modes and the 1-4 bit packed pixel modes are not compatible to anything P96 would be able to support. Note that its smaller and later cousin, the GVP EGS 24 aka GVP Spectrum is already supported since a long time.
  • Due to a very ancient bug in WritePixel(), drawing on layered rastports could have failed on TrueColor off-hardware screens only. This broke the 3.1.4 screen mode preferences test screen partially because ellipse drawing was erraneously bypassed.
  • Read/WriteRGBPixel() functions reading pixel values under a softsprite read the wrong pixel position because the width of the mouse save buffer was incorrect. This was another very ancient bug.
  • When installing a Visiona or GVP EGS 110 card, the installer now requests the type of synchronization to configure the INMOS chip to.
  • The monitor driver requests now a larger system stack.
  • Overlapped masked blits from one bitplane to another were not handled correctly if the target position was below the start position.
  • The planar blitter emulation for BltBitMap() was reimplemented and gained some speed. This may help the Native P96 utility a bit to improve performance even on non-RTG installations. In some rare cases, the previous implementation may have crashed the system, probably due to a bad minterms parameter. The new implementation should be more robust.
  • The BlitPattern emulation for planar target bitmaps was reimplemented as well. In case a mask is involved, e.g. for drawing filled polygons, the implementation also gained some speed.
  • The rastport AreaPattern fill logic failed to grab correct pens for high and true-color modes in some cases. This is another ancient bug that has been fixed.
  • The PiccoloSD64 crashed in case it failed to detect any valid video RAM because it forgot to remove its interrupt server before exiting. Thanks to Toni Wilen for reporting this defect.
  • The same bug was also fixed in the Retina, GVP Spectrum, Piccolo, Retina BLT Z3, Altais and PicassoII card.
  • The CVisionPPC handler now only adds the interrupt handler to the system if the interrupt is enabled. This may help to avoid compatibility problems.

Update V3.3.1

  • The CirrusGD5434 driver did not switch correctly from a direct color mode back to a chunky color mode. This was due to experimental support of DAC-switching support.
  • While WinUAE indicates that it supports DAC-Switching, it not always supplies the necessary call-back functions to implement the feature, and then crashes. The 3.3.1 release includes now a workaround and supplies default call-backs.
  • The installer script now puts the P96 version information into ENV:Picasso96/Version.
  • The bitmap management has been simplified and cleaned up.
  • The Visiona supports now panning for bitmaps not wider than 2048 bytes. This limits panning to chunky bitmaps of at most 2048 pixels, or 512 pixels for true-color displays.
  • The Visiona includes now experimental support for interlace. Similar to panning, the screen width is limited to 2048 chunky or 512 true color pixels.
  • Screen flicker while reloading color registers or panning the screen of the Visiona can now be mostly avoided by syncing both operations to the vertical blank. Unfortunately, the vertical blank is not always long enough to write all registers, so a complete palette change may take several vertical blanks now, unfortunately. The same fix also avoids complete system hangs due to the not quite operational "anti sparkle logic" of the chip.
  • Due to offloading critical changes to the vertical blank, the Visiona card is now a lot more stable.

Update V3.3.0

  • 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.

The following lists the boards that support this feature:

  • The 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.
  • The 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 drag-able 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.

New Drivers:

  • 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.

WARNING! YOU NEED A WORKING MMU AND THE mmu.library FOR THIS CARD

  • A new driver pair for the Retina (Z2 version) and the NCR77C22E+ chip has been added. This chip is special in the sense that it does not offer a linear address window, but only a segmented memory mode. The MMU and the mmu.library is required to use this chip as P96 expects a linear frame buffer, and the MMU can simulate one.
  • 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.
  • The 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.

Other changes:

  • 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 turns now 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 includes now 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).

Update V3.2.4

  • Removed the manual MMU hack. Any MMU table modifications require now the availability of the mmu.library.
  • The previous release broke the VBlank interrupt of graphics and might have loaded the VerticalTotal hardware register with nonsensical values.
  • The S3Virge blitter has a bug and "freaks out" if one attempts to perform blits of particular widths. The Virge driver now adds a workaround by avoiding problematic bitmap widths.
  • The S3Virge blitter can process at most 4064 bytes per row. Before, the limit was set to 4095 bytes, causing wrong blits on some large screens.
  • BltMaskBitMapRastPort() did not work correctly if the target screen did not have the full depth, i.e. if a chunky mode was opened with a depth smaller than 8. This was another old bug left over from the 2.x release series.
  • BltMaskBitMapRastPort() did not use the right modulo for the mask if the source bitmap was interleaved and planar and the destination bitmap was chunky or direct color. The mask was used correctly for interleaved or non-interleaved planar to planar blits.
  • Users of the oMNiBus card beware! The card driver may use the TsengET4000W32 chip driver, even with earlier releases of the Tseng chip that do not include a blitter. In such cases, attempting to blit will fail or hang the system. To prevent usage of the (then non-present) blitter, set the tooltype NOBLITTER=Yes in the monitor icon of the oMNiBus monitor. Note that this is not a new restriction.
  • Quite a number of improvements have been performed on the Merlin and TsengET4000w32 drivers as listed below, however

NOTE THAT THE MERLIN CARD HAS A COUPLE OF SERIOUS HARDWARE ISSUES THAT CANNOT BE WORKED AROUND COMPLETELY BY SOFTWARE, AND THAT THIS CARD MAY CRASH OR HANG YOUR SYSTEM, DESPITE OUR BEST ATTEMPTS TO AVOID SUCH PROBLEMS. NOT EVEN MERLIN BOARD UPDATES WILL COMPLETELY ELIMINATE ALL SUCH ISSUES, AND YOU SHOULD REPLACE OR UPDATE THE MERLIN CARD BY A MORE ROBUST DESIGN.

Fixes in detail:

  • Fixed a MuForce hit in the Merlin card driver.
  • Due to bad routing, the clock generator of the Merlin card cannot feed clock rates higher than 80Mhz into the chip, even if this clock is later on divided down in the Tseng chip. Thus, the default setting of the card now disables all settings of the clock generator that generates pixel clocks beyond this limit. If you really want to try higher clock frequencies (on your own risk), set the tool type OVERCLOCK=YES in the monitor icon.
  • Due to hardware design issues, the TsengET4000w32 chip may see false data on write requests to its registers, causing hangs or blitting defects on its screen. The new Tseng driver is now extra careful to verify that the correct data has been written for some particularly critical registers, though not for all registers. particularly critical phase are mode changes, which should be avoided if possible.
  • Due to hardware issues, previous Tseng chip drivers may have hung the system while waiting for the completion of a blitter operation. The new driver attempts to work around this problem as much as possible.
  • The Merlin and Tseng drivers now disable the display while modifying some of the chip registers. This helps to minimize hardware hangs of the chip, but does not eliminate them completely. Again, this is a hardware design issue, not a driver issue.
  • The Merlin card driver no longer indicates to use a more aggressive MMU table mapping; instead, the most conservative setting is now default. Do not attempt to "fix" this mapping as the Tseng chip can map its blitter registers into the VGA memory area, and those hardware registers may not tolerate write reordering as imposed by more aggressive MMU table settings.
  • The Merlin card driver did not indicate the maximum mode width for all modes correctly. Due to limited size of its hardware registers, Hi-color modes cannot be wider than 1024 pixels, true-color modes cannot be wider than 684 pixels and true-alpha modes cannot be wider than 512 pixels.
  • To limit stability issues, the hardware interrupt of the Merlin card can now be turned off by adding the "INTERRUPT=No" tool type into the Merlin monitor icon.
  • The Merlin card no longer provides its own functions to copy planar data from chip memory to VGA card memory as the default version of the rtg.library provides this function already by exactly the same algorithm.
  • Due to hardware limitations, the Sprite generated by the Merlin card (actually, the RAM DAC on the card) is limited to 32x32 pixels for high-res sprites, and 16x16 pixels for "big" sprites (i.e. BIGSPRITE=Yes in the monitor driver). Thus, tall pointer images may be clipped at the bottom. There is nothing the driver can do against this limitation.
  • The TsengET4000w32 chip offers a memory overlay feature which is now accessible through the P96 "Pip" (Picture-in-Picture) interface. However, as the Tseng chip does not have an intergrated RAM DAC, this memory window is rather limited. The RBGMode (pixel mode, pixel organization) within the memory window MUST be identical to the RGB Mode of the screen, and it cannot be planar. That is, you can only have "chunky" memory windows on "chunky" screens, "hi-color" overlays on "hi-color" screens and "true-color" overlays on "true-color" screens. The memory window neither supports opacity, thus the memory window only appears if it is topmost on the screen and not overlapped or clipped. Otherwise, the driver turns the memory window off. There is a PIP demo program on Aminet including sources. Note that this demo program attempts to create a "hi-color" overlay, which - according to the above restrictions - only operates on a hi-color screen.
  • If you see strange defects when rendering text or icons with the Merlin card, try adding SYSTEM2SCREENBLITS=No to the tool types of the Merlin monitor icon. This prevents blitter usage in those cases where the host CPU delivers data manually without a source buffer on the card. Since data transfers to the Merlin card are particularly flaky, this may prevent already some issues.
  • If you still see screen corruptions on rendering, you may have to disable the Merlin blitter altogether. For that, add the tooltype NOBLITTER=Yes to the Merlin monitor icon.

Update V3.2.3

  • 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.

Update V3.2.2

  • Some programs provide a custom planar bitmap for screens that have a chunky pixel format. In such a case, P96 already created a chunky side bitmap into which such programs are then silently rendering instead. Unfortunately, BltBitMap() did not correctly derive the type of this side bitmap, and instead used the type of the original bitmap instead.
  • Mode coercion could have returned a mode ID that does not exist, thus confusing intuition. The new code is now more careful creating a useful modeID from coercion.
  • Sprite colors are now switched if the sprite travels from one screen to another in a split-screen environment. This does not depend on any particular hardware feature, but is provided for all graphic cards.
  • Fixed passing in the wrong modulo value for the planar BltMaskBitMap() function if the source bitmap is interleaved. This broke only masked blitting on bitmaps with the Native driver.
  • In case a screen switch to a planar screen with bit depth 3 or less was made, and a soft-sprite was used on the target mode, P96 might have forgotten to initialize the sprite colors correctly.
  • The rtg.library did not inform the card special feature hooks in case the screen split position was updated.
  • As result of the above fix, the PicassoIV memory and video windows no longer need to be deactivated if screen splitting become active. They pan now together with the front screen. Note that P96 currently does not support video or memory windows on the back screen.

Update V3.2.1

  • 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.

Update December 2021 (V3.2.0)

  • P96 supports now a new feature for graphics hardware, dual palette support. On such 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 was 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.


Update September 2021 (V3.1.2)

  • 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.

Update to V3.1.0 (June 2021)

  • This version adds much better multi-monitor support, including keeping the native Amiga display on the native RGB output if the screen is switched away from it.
  • Mode coercion was actually slightly broken and could result in the mouse pointer leaving a native screen topwards even though an underlying RTG mode could not be shown.
  • HIRES mouse pointers are now again available on Os 3.2 due to a new interface between RTG graphics and the intuition pointer class.
  • If a board signals that it is not part of the display chain, P96 keeps now the native display active on the Amiga RGB output and thus allows a two-monitor setup with the native and the RTG output.
  • The Pixel64 driver failed to detect the graphics card on the ateo bus board. The card detection function was fixed. Note that the older ateo driver you find elsewhere does not reserve sufficient memory for the sprite data and thus trashes the mouse pointer.
  • See also the release notes of the 2.2 release: The fastlayers.library is obsolete. If you want fast layers operations, make sure you install either Os 3.1.4, or the V45 layers library from aminet.
  • The screen-dragging disable logic did not work entirely correctly and enabled screen dragging, even if front and back screen were on two different boards.
  • The maximal bitmap width on the S3Virge and S3Trio chips allowed to exceed widths of 4096 bytes, beyond what the chip can handle.
  • Due to a FIFO misconfiguration, the S3Virge could not use the blitter if the stream processor was disabled and showed display glitches at high display resolutions. This was fixed.
  • The rtg.library could cause a hit if a ViewPort with a NULL RasInfo or ColorMap was passed into LoadView.
  • The rtg.library erraneously activated PiP/memory windows even if those were on a back screen.
  • The memory window of the CVision3D was broken in multiple ways. Unfortunately, the stream processor requires a wait for a vblank to get disabled savely, or it trashes the screen or hangs. Note that the processor needs to be disabled on screen dragging or screen switches, so this happens regularly.
  • Re-enabled the CVision3D memory window on 256 color background. There is nothing wrong with that.
  • The WaitVerticalSync() function of the S3 chip did not restore memory banking properly on exit if waiting for the end of the sync. Note that the interrupt was disabled on Z-II sytems anyhow that required memory banking.
  • The S3 Virge interrupt handler was massively reworked to operate properly on Z-II and Z-III machines. In particular, it restores proper banking from a shadow register.
  • Now in Zorro-II mode the CVision3D also allows board interrupts. Enabled interrupts allow a more fluently screen dragging, and also may be used to synchronize to the screen, avoiding flicker on animations.
  • Waiting for vertical blanking on the S3Chip was not working at all on Z-II machines as it accessed the register in the I/O bank where, due to a chip erratum, it was never registered. The Z-II code now accesses the register in the MMIO bank where it works.
  • In case a screen whose monitor is not in the display chain looses the intuition input focus, P96 removes now the mouse pointer from the screen.
  • In case a smaller screen was dragged down with a larger screen in the back, the rtg.library may have trashed memory upfront the smaller screen. This was because the lib assumed erraneously that the frontmost screen could be panned left-right.
  • The default maximal planar memory is now 128K instead of 256K as this is the maximum permissible by legacy VGA registers (GR6, to be precise).
  • In case allocating a planar bitmap was attempted that was too big to fit on the card, the rtg.library would have let this allocation pass, even though any later attempt to display this bitmap would have failed. The updated code now checks beforehand whether a bitmap can possibly be displayed.
  • The memory reorginzation function did not reliably move planar data around as the BlitRectNoMaskComplete() function for planar data is just a dummy. Planar data is now moved by the CPU manually through the legacy VGA memory apperture mapping.
  • 4-bit planar modes are now available on the CVision3D/S3Virge based cards. Due to a chip limitation, the maximum available memory in the planar mode is limited to 128K per plane, i.e. 512K total.
  • The S3Virge memory window is now also disabled for interlaced modes because the S3 stream processor does not work on interlaced screens. Note that the stream processor is also not available on double clocked (high-resolution) modes and double-scan (line-doubled) modes.
  • The CVision3D card driver recognizes now the tooltype INTERRUPT=No to disable the vertical sync interrupt usage. Use INTERRUPT=No in case you find that the interrupt handler is not working for you and you observe problems or conflicts with other expansion cards or the CIA interrupts.
  • The rtg.library avoids now an additional WaitForSync() if it is possible. This enables smooth screen dragging especially on those chips where the CPU cannot reliably wait for a vertical blank (S3Virge).
  • Due to panning by adjusting the memory window address and a rounding issue, the S3Virge memory window overlay could stop display DMA for the primary (background) stream a bit too early, causing artefacts at the left edge of a window on a panned screen.
  • The S3Virge hardware accelerated line drawer did not clip lines correctly and could therefore draw outside of the window bounding box.
  • For consistency reasons, the CVisionPPC card now also recognizes the tooltypes INTERRUPT=No and INTERRUPT=Yes, they work the inverse of the NOINTERRUPT tooltype, which is just harder to understand (double negation).
  • The S3 accelerated line drawer was off by a lot. Due to a some missing sign extensions and clearing of low-order bits, computations might have been just wrong, resulting in incorrect clipping results. In case coordinates where negative, the algorithm also incorrectly adjusted the line start address without ensuring that this address must be a multiple of 8.
  • The S3 line drawer did not always clip correctly, resulting small out-of-bounds pixel errors. The computation of the clip window is now done hopefully correctly.
  • Since the S3 line drawer cannot ensure that it draws lines exactly as the built-in Bresenham which is used for off-card line drawing, and since this may result in some wrong pixels, the accelerated line drawer of the CVision3D can now be turned off by the tool type FASTDRAWLINE=No.
  • The CVisionPPC accelerated line drawer may have also caused small out-of bounds clipping errors because its line drawer may not operate exactly as the built-in Bresenham algorithm. The same fixes of the clip window computation have been here applied as well. Also, the CVisionPPC fast line drawer can now be turned off by the tool type FASTDRAWLINE=No if this turns out to be a problem.
  • The rtg.library line drawer interface was streamlined a bit avoiding unnecessary register ping-pong, probably speeding up the line drawer by a small amount.
  • The 24-bit BGR mode of the S3Virge/CVision3D is back. Note, however, that it does not support screen dragging due to a limitation of the S3 chip. Note that this mode, due to the same limitations, does not support interlace, double-scan or double-clock modes. The resulting display will look "funny" because the stream processor (on which this mode is based) does not support scan doubling, interlace, double-clocking and screen- dragging.
  • Due to some trickery, the planar mode of the S3Virge also gets a hardware sprite. The HW sprite is also enabled on the 24 bit mode.
  • The S3Virge driver forgot to adjust the endianness for the line drawer and therefore drew lines in the PC endian monitor modes in the wrong color.
  • Due to a hardware bug of the S3Virge, the line drawer operates flakey in the 24bit mode and may draw the last pixel in the wrong color. It is now replaced in this specific mode by the software renderer.
  • The blitter fallback for the 32-bit true-color modes on the S3Virge were activated way too early as the chip can take stride values up to 4095 bytes, sufficient for most true-color screens. This allows blitter usage for rectangle fills, scrolling and inversion for many cases and thus speeds up processing of these modes by quite a bit.
  • In 24 bit RGB or BGR modes, DrawEllipse confused the R/B channel order and drew the ellipses in the wrong color. All other modes are fine.
  • Ellipse drawing on non-layered rastports in the COMPLEMENT mode left a couple of pixels non-complemented, namely the top, bottom, left and right edge of the ellipse, and for circles, the 45 diagonals. Actually, these pixels were inverted twice. Also, COMPLEMENT drawing of ellipses used the wrong color for 15, 16 and 32 bit RGB modes.
  • The CVision3D driver reconfigures now Gary for a more relaxed bus timeout as the S3Virge chip may lock the bus for quite a while in high color depth modes and may thus trigger a physical bus error.
  • In case you see flicker on 24bit 1024x768 modes of S3Virge boards, ensure that you reduce the clock frequency a bit as the chip is operating at its edge of bandwidth. Possible bus contentions may also cause system freezes or bus errors.

Update to V3.02 (January 2021)

  • Added a new flag to indicate that the sprite resolution is halfed horizontally on double-clocked rates. Thie Cirrus GD5434 is a victim of this property.
  • Computation of the total required video RAM for enabling the screen dragging was not correct, and did not take alignment requirements of screens into account. This was fixed now.
  • The Z-III configuration of the CyberVision3D was not in the database of the installer script and thus failed to install the required components.
  • The S3Virge.chip driver was still delivered with a major version of 7, though the major version should have been 42.
  • Apparently, the legacy VGA engine of the S3 Virge chip has problems pipelining its data while the blitter is accessing the video RAM. The new driver therefore only enables the blitter if the stream processor is enabled as well, which happens for non-double-clocked, non-double-scan video modes and if no screen dragging is in process.
  • The rtg.library did not accept a LoadModule'd version of the graphics library as original and thus recognized it as "patched" by the P5 CVisionPPC driver, disabling the native modes.
  • The 3DLabsPermedia2 driver is now more careful reseting the chip which could create (physical) bus errors while the chip is still busy performing the reset.
  • Due to a missing bracket, the 3DLabsPermedia2 driver was still not installed along with the CVisionPPC card driver.

Update to V3.01 (December 2020)

  • S3Virge driver updated: Stream processor only used when screen dragging is not used
  • S3Virge driver fixed for double scan modes
  • rtg.library will allow "FakeNativeModes" if P5 patches are removed by another tool, which is NOT part of this P96 archive.
  • SetRGB32() could not be called from supervisor mode. Fixed, which takes Shapeshifter back to working.
  • 3DLabsPermedia2 now installed (fix in the installation script)
  • ModifySprite() fixed, fixing MouseBlanker commodity.
  • P-IV memory handling improved

Update to V3.0 (October 2020)

  • added Screen dragging
  • added CyberVision drivers
  • Warp3D API compatibility
  • please check back for more information here. We're publishing this in a hurry, while AmiWest ist still going on.

Update to V2.4.6

  • Fixed AllocBitMap(), which was broken on very large screens in the (unpublished) version V2.4.5.

Update to V2.4.5

  • Due to an oversight, allocating planar (4-bit) bitplanes on intuition V46 or above did not return the proper result as it allocated a chunky bitplane instead. As net-result, planar non-native graphics modes did not work at all.

Update to V2.4.4

  • Bug in erasing True Colour screens fixed; Pagestream now works properly.

Update July 2019 (V2.4.2)

  • Cirrusgd542x driver updated, which was used for the P-II, GVP-Spectrum and others. Screens with more than 512 lines are now working properly, and automatic switching to software-cursor is now aware of special behaviour of the chip.
  • fixed a test-case for the P-IV flicker fixer that initially only showed in emulation, but is now confirmed to fix the real deal as well.

Update to V2.3

  • Bug in BltMaskBitMapRastPort() fixed: The modulo-value of the mask was calculated wrong.

Updates in V2.2

  • The fastlayers.library is obsolete. The distribution no longer includes it, and the rtg.library no longer uses it. A v45 version of layers is available in the aminet which provides similar functions, though not on the basis of a patch. Otherwise, P96 works also on top of the V40 layers.library.
  • rtg.library: Apparently, some line drawing modes were a bit off, especially in combination with the firstDot flag. This may still require some testing, though.
  • rtg.library: Blitting small bitmaps in 16-bit hi-color mode could have trashed memory.
  • rtg.library: Some min-terms for 15 and 16-bit hi-color when blitting chunky to hi-color modes trashed registers and hence caused rendering defects.
  • rtg.library: Allocating bitmaps for screens that are not yet visible, but about to become visible caused trashed screen content as soon as the screen was moved to front. This was because the bitmap already got board memory at its allocation time, which was however, overwritten by the backfill memory on a screen flip, causing random nonsense from non-initialized memory on the screen.
  • rtg.library: Not yet visible true- or high-color bitmaps that are about to become visible but are not yet visible get the background colour from WB screen, even though they may not be even part of the WB.
  • Fixed testing of occluded layers for PIP functions, adapted to the new V45 layers interface.
  • test for native bitmaps: the rtg.library now uses consistently TypeOfMem() to test whether a bitmap can be accessed by the native chipset or requires CPU emulation.
  • Added a new internal hook, EnableSoftSprite(boardinfo,formatflags,modeinfo) which allows a more flexible switching of softsprites than the simple SoftSpriteFlags available before. Especially the Cirrus GD534 has strange rules when the hardware cursor is available and when not.
  • Some combinations of mask and line mode did not honor the FRST_DOT flag of the graphics rastport correctly. Fixed.
  • JAM2 in HICOLOR mode rendered incorrect results when drawing lines.
  • Some blit combinations with patterns did not honor the minterm combinations correctly, especially combinations of JAM1/JAM2 and INVERSVID were problematic.
  • Cirrus GD5434 (PiccoloSD64 and others):
    • double line mode was broken (there is probably still a similar bug in the GD542x)
    • softsprite enabling is now more flexible
    • avoids color artifacts at the right border in true-color autoscroll modes
    • Due to a forgotten flag in the driver initialization, the pointer hot-spot was off if the BIGSPRITE option was used and the mode used line doubling.
  • Cirrus GD542x (GVP Spectrum and Picasso II):
    • removed artifacts on true-color screens with autoscroll enabled.
    • there is potentially still a bug in the double-line scan modes.
  • Develoment files both for application developers and card developers are now available. While the previous development files were based on the GD432x chip and the PicassoII board, both chip and card do not demonstrate the full feature set of P96 ideally. Instead, the GD5434 and PiccolloSD64 chip and card are now included. The GD5434 supports double-line scan modes, and requires a complicated-mode dependent soft-sprite switching that is only supported by the latest version of the rtg.library.
  • Previous versions of P96Mode and the emulation.library required a private link library, namely the xls.lib. As this library is no longer available, the missing functions have been re-implemented.
  • The P96 monitor driver became a lot shorter now.
  • The install tool FindCVPPC caused hits on some systems. The tool was rewritten to avoid them now.
  • Note that you can bypass the Amiga blitter now and use the CPU for blitting, thus allowing bitmaps in FAST MEM. This requires setting the following variable: 
 ENVARC:Picasso96/DisableAmigaBlitter

to contain the value "Yes" for this operation.

Update in January 2019 (V2.3)

  • RTG library updated: Fixed non-working modes for Permedia2 chip, which had a problem with screenmodes using different byte-orders. This was not directly related to the Permedia2 chip, but a more generic error in RTG library, so if you have read about Bug#466 in the OS3 bug tracker in conjunction with BVisionPPC, this is the fix that came out of it.

Update in April 2019

  • Improved compatibility with SDL. This is putting emphasis on "improved" but not "fixed", as SDL has an inherent problem that P96 cannot fix. SDL-driven programs may crash on a screen-change. When a screen-change is happening, then SDL is pulling a pointer to the bit map, but it does not lock it everytime it does that. The bad thing is that P96 may or may not have moved the bitmap in the mean time, which is documented behaviour. The good news is the "black screens" with NetSurf are mostly eliminated with this update.

Developer support

Some things have changed with P96 V3.0!

  • Memory management (the default implementations are usually fine).
bi->AllocCardMemAbs(): Allocate memory of a given size at a particular graphics memory location, migrating any other memory that is in the way.
bi->ReInitMemory(): Re-initialize the memory pool for a given RGBFormat.
  • Sprite management:
bi->EnableSoftSprite(): Check for a given RGBFormat and modeInfo whether a softsprite needs to be enabled (already new in 2.4.0, i.e. v41)
  • Screen management:
bi->SetSplitPosition(): Enable a split-screen at given line.
BoardInfo->Flags: BIB_VGASCREENSPLIT: Board allows screen split.

Software Developer archive

The following archive explains how to adapt programs to use the P96 software (updated January 2024 for V3.4.1): Media:Develop.lha

Hardware manufacturer archive

The following archive shows how to make a driver for P96 using the full scope of the software, including hardware acceleration (updated January 2024 for V3.4.1): Media:CardDevelop.lha

Writing a driver

This has been exported to a separate Wiki article. Please see P96 Driver Development.

Special thanks

P96 is a very complex software package. Finding our way around it would not be possible without the help of Thomas Richter AKA Thor, who did the bulk of the work. Also, special consideration should be given to the beta tester team of OS3.1.4. Writing proper bug reports is hard work. Thanks for giving this the same love that you have for this wonderful platform: Marcus Gerards, Mikhail Malyshev, Thomas Klein, Ignacio Gully, Tobias "MastaTabs" Seiler and Christian "Scrat" Euler.

Operation and installation under UAE

The UAE driver has been removed from the package for unclear copyright reasons and for obsolescence. The only thing required is an icon and a generic loader, which is identical for all P96 drivers. Just go to devs:monitors/ and rename some other P96 driver (and icon) to "uaegfx" and "uaegfx.info" - only the name matters, but the loader is identical for all P96 drivers. Further, the only really important content of the icon/info file is that a tooltype "BOARDTYPE=uaegfx" is set.

The file "libs:picasso96/uaegfx.chip is not needed any more - this is the one that's under the problematic license. WinUAE has P96 support built-in since a few years, and that even has hardware-sprite support for the mouse pointer, which was not the case for the old drivers (yes, there were two versions with different bugs, one even without hardware blit functions).

If you really want to run an old version of UAE, you will find the required driver in the historic P96 shareware archive on Aminet.

Installing the new version of P96 under UAE involves some manual steps and ignoring warnings. Specifically, you need to select any other graphics card from the list to continue installation, and then you need to override the warning message that tells you that it's not a good idea to install graphics card drivers on an emulated system. This will get you though installation and let you do the change to the tooltype of the P96 monitors file (click the icon once, then select "information..." from the drop-down menu of WB).

Retrieved from "http://wiki.icomp.de/w/index.php?title=P96&oldid=10082"
Personal tools
Namespaces

Variants
Actions
Navigation
Icomp
Print/export
Administration