P96 3.0.0 (and later) news and support

[Thomas Richter]

Just this morning, the 3.1.2 release of P96 became available at iComp.

This is again a minor bugfix/compatibility improvement release. There was one bug in multi-monitor support that appeared if one card was in the display chain, and another card was not, and the display was switched from the not-in-chain display to the native output. In such a case, P96 forgot to turn the native output on again.

There was also a defect in screen-dragging support, which did not work for cards without blitter. Surprisingly, this hit the ZZ9000 card which, even though it does have a blitter, does not indicate its presence to P96, thus screen dragging remains a bit slow on this card until this defect is addressed in the driver. On all other cards with a blitter, screen dragging already became much "snappier" with the 3.1.1 release.

There are also a series of compatibility patches in the Picasso96API.library and the emulation of the cybergrapics.library (part of the emulation.library) which gets more programs to run fine under P96 emulation. They are mostly related to the cgfxBestModeID() function which returns now big-endian modes with higher priority as some programs expect that the CVisionPPC only supports such modes. Under P96, this card supports many more modes, though. P96 exploits the full capability of its chip, including endian-switch and B/R switch.

The full list of changes:

- 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 forgot to 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, the 3.1.1 failed. The 3.1.2 falls now back to the 3.1.1 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 working 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 the 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 adds now 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 question is never stated,
looping forever for the user to confirm.

[hexaae]

Great news!

[nogginthenog]

Thanks Thomas!

[hexaae]

Site http://ami-soft.blogspot.com/
http://netsurf.baderman.net/netsurf-m68k.lha on AmigaOS3.9 doesn't work anymore with error:

Unable to set video: No video mode large enough for 820x600
Unable to initialise framebuffer

I think the only things I changed since I run it (and was still working) were: AmiSSL 4.10 (Aminet), and P96 3.1.2 update.

I reported to Arti and he told me to ask to P96 devs...

EDIT:
Rolling back to old 2.377 and Picasso96_old/ subdir make NetSurf start fine again

[Thomas Richter]

First of all, please report bugs at the icomp forum where they can be collected. This is not quite the right place.

The short answer is that this is probably due to a workaround which was necessary to get some other (less well) written programs running. Netsurf should probably switch to the native API (Picasso96API.library) instead of depending on the CGFx emulation. This would resolve the situation quite nicely.

[hexaae]

Thanks for reply, will do opening a report at https://forum.icomp.de/

[dschallock]

(EDIT) - Sorry Thomas, just read above. I will report these on the icomp website.

updating from p96 3.10 to 3.12 brought some new bugs to zz9000 setup.

When running programs that use native screen modes like deluxepaint IV I get the strange horizontal split screen with the top half of the screen duplicated again on the lower half.

When running Brillance 2.0 when I don't get the split double screen but when I click on a menu item which normally expands the menu to larger sub menu the screen goes black for a few seconds and returns to the screen with the expanded menu.

Still no screen dragging working in this version for me either.

Downgrading back to p96 3.10 resolves these issues.

[Thomas Richter]

Originally Posted by dschallock

When running programs that use native screen modes like deluxepaint IV I get the strange horizontal split screen with the top half of the screen duplicated again on the lower half.

This is *not* a P96 bug, bug a ZZ9000 firmware bug that was confirmed by Lucas (mntmn). P96 cannot control what the ZZ9000 does to native screens, and the native output is fine.

Originally Posted by dschallock

Still no screen dragging working in this version for me either.

Since it does for other beta testers, I suggest to check your installation. Note that you can only drag screens if there are at least two screens in the view, and if the two screens have the same mode.

[Thomas Richter]

Originally Posted by hexaae

Thanks for reply, will do opening a report at https://forum.icomp.de/

You have an answer in the icomp forum, please check there.

[hexaae]

Originally Posted by Thomas Richter

You have an answer in the icomp forum, please check there.

Thanks for heads up. I enabled forum notification.

[Thomas Richter]

Now, did the new version work better?

[hexaae]

Yep, solved the issue (failed launch of NetSurf 68K) as I've written to Jens but I'm still unsure if introduced some random gfx very minor glitches with a few CGX programs like Genetic Species (24bit CGX-->P96)... Will do some more testings rolling back to older versions too and report in icomp forum soon

[klx300r]

Originally Posted by Thomas Richter

…
VA2000 does not have a line-compare register, so it does not support screen dragging. The ZZ9000 has something comparable, though cannot (at this time?) mix modes or switch palettes. Warp 1260 is to my knowledge not a graphics card at all, and MiSTer does to my knowledge not implement RTG graphics but rather only native planar graphics.
…

after trying to get a hold of Lucas for a very long time about potentially getting us VA2000 users an update for screen dragging with sadly no response I guess Thor’s response above means it’s never gonna happen …still would have been nice to hear an official response from MNT (Lucas)

[trixster]

Try contacting him on the mntmn irc channel on libera.chat

He’s very active on there!

[Thomas Richter]

The ZZ9000 receives a feature update, and with the next version, will support mid-view palette switch. This means that there will be no longer false colors when dragging two chunky screens.

[gdonner]

Originally Posted by trixster

Try contacting him on the mntmn irc channel on libera.chat

He’s very active on there!

If it helps, specifically: #mnt-amiga on https://libera.chat

Logs of archived IRC support chat that might also be helpful: https://mntre.com/amiga-irc-logs/

[klx300r]

Originally Posted by gdonner

If it helps, specifically: #mnt-amiga on https://libera.chat

Logs of archived IRC support chat that might also be helpful: https://mntre.com/amiga-irc-logs/

Thanks Greg, just posted there & hope to get a response

[klx300r]

Originally Posted by klx300r

Thanks Greg, just posted there & hope to get a response

and finally got a response and no not from irc but from their official MNT forum https://community.mnt.re/ and the response is:


"Hi, unfortunately we don’t have any resources to work on VA2000 firmware at the moment. But the firmware and drivers are completely open source, so anyone competent in Verilog and C could add such functionality."


..so any fellow VA2000 users here that are competent in Verilog and C

[Tigerskunk]

Sorry, complete OS newb here. So maybe this is a daft question, but do these new versions of P96 work with Vampire RTG?

I have a V1200 in use.

[Thomas Richter]

Originally Posted by Steril707

Sorry, complete OS newb here. So maybe this is a daft question, but do these new versions of P96 work with Vampire RTG?

The driver API is fully backwards compatible, so yes.