P96 3.0.0 (and later) news and support

[macce2]

@spudje

Many thanks for your help !!
I guess the webpage is quite awful indeed !

[Thomas Richter]

Right now, the 3.3.3 version of P96 appeared and can be ordered or downloaded at the icomp shop.

The major feature of this release is that it offers the emulation of planar bitplanes, even if the graphics card does not support them or if a program requests more than the maximum 4 bitplanes VGA offers. That should help you to promote even more legacy applications to the graphics card, we had such issues lately. For that, set "ENV:Picasso96/EmulatePlanar" to "Yes" and reboot.

Detailed release notes:


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

Sorry, this release took 3 months longer than anticipated, mostly because we had one customer with "special" hardware where I had to find a workaround for a driver bug. (And, hey, Elbox, next time, you fix your drivers yourself and support your customers yourself, would you?) The workaround is mentioned above.

Have fun, and sorry for the delay....

Thomas

[alexh]

Thanks for all the hard work.

[nogginthenog]

Thanks Thomas!

[hexaae]

Great news!

[Thomas Richter]

Maybe I should translate some of the release notes into "plain English" (i.e. make it less technical).

The "EmulatePlanar" switch works best in combination with screen promotion utilities. Promote the native output to an RTG planar mode, and many legacy applications that "poke into the frame buffer" would now work. They get a planar chipmem bitmap of up to 8 bitplanes, and P96 combines them into a chunky display if needed.

The Draw() workaround translates to "MusicX works again, despite programming defects".

NOMASKEDBLITS=YES translates to "make P96 work despite Elbox drivers" that do not support masked blits correctly.

Then, we have one really funky bug that crashed the system if you loaded a new graphics.library by LoadModule, and the graphics.library would end up in chip memory at some particular location. Due to a couple of miserable coincidences, this made P96 think that graphics is not original and need to be restored to its original locations, but those were not real code, but some junk locations in lower chip mem. graphics should *really* not be in chip memory, and if it is, you better try "LoadModule" with the NOMEMFKICK option. This happens if your hardware vendor did not equip your turbo board with proper auto-configuring memory. (Sigh)

The "bobs" related update translates to "you can now relocate bitplanes to fast (PlanesToFast) option,and at the same time keep the native blitter enabled", without workbench showing junk when drawing icons. This way, P96 will now use the native blitter whenever possible, but if some data ends up in fast memory, the CPU will take over. This did not work before, but only for the GELs system.

The "WritePixel" fix translates to "WB 3.1.4 and beyond shows now the test picture correctly when testing new screen modes". It is another oddity and a very old bug that was hidden in a rather obscure place.

Then, the DPaint 5 thing. Interestingly, DPaint 5 can blit both with the native blitter and the CPU, but the way how it determines whether to use the CPU or the blitter uses some arcane undocumented flag of the Os GetBitMapAttr() function. Probably CBM had ideas about RTG themselves, shipped preliminary information to EA how it should work, EA implemented the switch on this "reserved" bit, but the "bitplane is not native" bit never made it into the Os documentation, neither the Os. Who knows...

[gdonner]

Thomas, thanks for all your hard work with this update! As always, it's much appreciated!

It has to be frustrating for you trying to track down elusive/obscure bugs, let alone implementing workarounds for them. :-\

[nogginthenog]

Originally Posted by Boing-Ball

Thanks Thomas…. Will look into re-subscribing as I believe these only last a year at a time?

This is correct. Mine expired also.

[shelter]

Wow, first Amiga OS 3.2.2 and now this. Seems like a very nice "driver update" with some cool features.
The things yoo and other devs do for the Amiga, I can't really express it in words.
It's astonishing to say the least.

[macce2]

Is this new release free for purchasers of the previous P96 v3 ..?!

[Thomas Richter]

It depends when you bought the last version. Once you buy P96, you get one year of free updates, after that period, you'll have to buy again. I would typically provide new versions around Christmas, if not earlier, but this plan did not work out for 3.3.3 unfortunately, so timing was off. This was not on purpose - it just did not make sense to release something with a known issue.

[macce2]

My order from iComp was on 24.07.2022.
That site could be more complete, I guess..
Should I view my purchase history on iComp site and use the old link or
something...?!


Update: Yes, that seems to be the case;
the new updated file(-s) seem to open
with the old link(-s).


Many thanks for your hard work, Thomas !

[klx300r]

Thanks for the update ThoR to

[mfilos]

Thanks for the update Thomas! I'm so glad that P96 gets updated \o/

[mark_k]

Originally Posted by Thomas Richter

Then, the DPaint 5 thing. Interestingly, DPaint 5 can blit both with the native blitter and the CPU, but the way how it determines whether to use the CPU or the blitter uses some arcane undocumented flag of the Os GetBitMapAttr() function. Probably CBM had ideas about RTG themselves, shipped preliminary information to EA how it should work, EA implemented the switch on this "reserved" bit, but the "bitplane is not native" bit never made it into the Os documentation, neither the Os. Who knows...

I took a look at the GetBitMapAttr() code in Kickstart 40.63.

GetBitMapAttr() with BMA_FLAGS never returns with BMF_INTERLEAVED set, unless the bm_Pad field contains 0x805C. bm_Pad == 0x805C causes the following changes:

BMA_FLAGS can return with BMF_INTERLEAVED bit set.

BMA_WIDTH:

• When bm_Pad != 0x805C, BMA_WIDTH always returns bm_BytesPerRow*8
• With an interleaved BitMap and bm_Pad == 0x805C, BMA_WIDTH returns the stride, i.e. (plane1ptr - plane0ptr)*8

The check for an interleaved BitMap is as follows:

• Depth must be > 1.
• First and second bitplane pointers must not point to the same address.
• bm_BytesPerRow must be greater than the difference between the first and second bitplane pointers.

[Thomas Richter]

Believe me, this is not related to BMF_INTERLEAVED, neither anything in the Kickstart, nor something implemented in the Os.

[pcotter]

Sorry if this question is in the wrong thread but as the Native driver is interconnected with P96 i would like to know if Ftext is necessary still when using Native?
Thank you :-)

"FText V1.7
What it It?

FText is a replacement for the graphics.library routine Text(). This
patch causes text to be rendered in fastram instead of chipram..."

[pcotter]

anyway, did some tests and Ftext seems to work with Native...

PutText()

[gdonner]

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.

It's interesting that a prototype of DKB's Inferno card did/does(?) exist--see link below to an old post from the legendary Skipper Smith talking about his Wildfire--but both the Amiga Hardware Database and The Big Book of Amiga Hardware ambiguously list CyberGraphX drivers (v3 and v4) for it. Obviously those drivers were planned, rather than actually written:

I like the one I have in my A2000, though it is currently not in
operation right now. I would not encourage you to consider getting one,
because you won't find much support for them and the pseudo-PCI slot that
it has never gotten used for anything- the promised Inferno video card
never got beyond the prototype stage (I have one of the prototypes, but it
is non-functional. I keep meaning to give it back to Dean).

Source URL: https://groups.google.com/g/comp.sys.../c/EPaTNdTyLpU

FWIW, if an actual Inferno card does exist, there is at least one owner with a DKB Wildfire card that it could be connected to--Retro Hack Shack:

[ Show youtube player ]

[Magic]

Thank you so much to everyone!