After quite a long delay due to research a report from an Elbox Mediator user, the root cause of artefacts during blitting has been found. It's a driver problem in the Elbox driver itself where we don't have any control. We are hereby asking Elbox customers to contact them about a possible fix on their side.
For now, we can only provide a workaround; a new ToolType in the monitor icon needs to be set:
P96 V3.3.3 can now emulate planar modes, even when the actual hardware does not support it. To make use of this feature, set the environment variable ENV:Picasso96/EmulatePlanar to "YES".
Another problem that has been reported in this support forum that has been fixed is with DPaint 5. Here's the complete list of changes:
- 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:
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:
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.