P96 3.0.0 (and later) news and support

[Thomas Richter]

The "screen mode switching" is the "big thing" in this release, and as stated, it is currently supported for the P-IV and the CVision3D. The way how this works under the hood is quite different, though, and this abstraction is all up to the driver.

For the PicassoIV, the trick is the DAC switching property of the chip. One can use the signal that would usually generate the border blanking to switch the DAC - the digital analog converter - from one mode to another mode. That's a special feature the Cirrus chip on the P-IV supports. In this case, it is from hi-color to chunky. Border-blanking is then implicit because the signal generator that would otherwise control the border and its size is mis-used to drive the DAC switch. Since hi-color uses 16 bits per pixel and chunky uses 8-bits per pixel, hi-color pixels are then twice as wide as chunky pixels. That's "mode coercion" the way how the Cirrus chip does it. Unfortunately, the trick does not work (yet?) for true-color, so it's currently only switching from hi-color to chunky that works.

For the S3Virge on the CyberVision3D, the trick works in a completely different way. The chip is more or less "two VGA chips in one package". The legacy VGA logic, which can generate double-scan, double-clock and interlace, and has a "line compare register" which was used for screen-dragging so far. But it also has a scream, pardon, stream-processor which can generate a picture, and which was used so far only for overlays. Unfortunately, it is an "either-or". VGA logic or stream processor. The stream-processor allows overlays like the memory windows, but it does not support double-scan, double-clock, interlace or screens wider than 4096 bytes.

Now, what P96 (or the S3Virge driver) does is that it dynamically switches between the two operating modes. For double-scan screen-dragging, it uses the VGA logic because only the VGA logic supports double-scan. For mode-mixing, it uses the stream processor, which is otherwise also used for the "PIP" windows. Thus, if you drag a true-color screen on a chunky stream, one of the screens is actually an overlay. Unfortunately, the overlay cannot be chunky, only hi-color and up, and so P96 dynamically selects which part of the monitor is the overlay and which one is the background. The S3 virge driver is now one of the most complex in the portfolio since it dynamically switches between the operating modes of the chip and distributes overlays depending on the screen arrangement and whether a PIP window is open.

Are there more chips that can do this trick? Well, maybe. There is an experimental extension of the Cirrus5434 that is on the PiccoloSD64 and Matze's graphics card which also supports DAC switching, but it requires a bit of help. One wire needs to be soldered between two pins of the chip, something that became internal in the Cirrus 5446 chip on the P-IV, and the driver needs a particular "kick" to enable the feature. It is at present experimental and thus not enabled by default - it does have a couple of draw backs.

If there is interest in how to extend the card, and how to activate mode switching on 5434-based cards, let me know. Again, "on your own risk" at present.

[Thomas Richter]

There are also a couple of bug fixes in the new release that are not explicitly mentioned in the overview, so here they come.

The S3 Virge on the CVision3D is a two-headed processor which can generate the display either by the legacy VGA logic or the "stream processor", as already reported. The latter one supports overlays and by that also mode-mixing, but it does not support interlace, double scan and double-clock. There is another limitation, namely that it does not support screens wider than 4096 bytes simply because its registers are limited to 12 bit. Interestingly, on some chip revisions, there is either a 13th bit, or the stream processor does not work at all for 32-bit modes. One way or another, the new driver disables the scream-processor now for such wide modes and uses the VGA logic instead, but then you cannot mix modes.

There was also a wrong factor of x2 in the computation of the back-porch, leading to a wrongly positioned picture in some modes. This was also fixed.

Speaking of overlays (PIP windows in P96 speech), the old code was still a bit too critical and did not allow overlays based on aperture settings different from the setting of the main screen. However, P96 already became more flexible in release 3.2.0 by allowing aperture mixing, and thus the check was superfluous. This prevented PalomaTV to operate on a chunky workbench for Zorro-II machines.

A single missing bracket in the P-IV code also prevented correct initialization of one hardware register, causing the Paloma TV picture to leak to the right part of the screen.

Then, we had one bug in the palette loading / SetRGB4() and friends which unfortunately also triggered a reload of hardware registers even if the affected screen was not visible.

[Jacques]

Hi Thomas and Everyone,
having just bought P96, I've installed the latest 3.3.0 on my 060 Amiga 1200 (Warp 1260) under AmigaOS 3.5 (using MMULIBS for 060 libraries and MMU). To date, I was using old and free Picasso96.

Trouble is, I'm getting enormous freezes when booting to Workbench (Hires laced AGA) - first to enable desired screen-mode, than loading wallpaper. Also, going into screenmode to list available modes, it's also getting frozen for few good seconds before displaying them. The same when I'm running FileMaster on separate screen, it's drawn in steps it seems - so slow. That is happening with or without using NATIVE.
Any clue, please?

[Thomas Richter]

Without further information, hardly. Which graphics card? Which machine? Which Os? Which system? What is an "enourmous freeze"?

[Jacques]

I think I wrote all of those above? Freezes of few seconds (where you can't even move the mouse cursor) on screen-changes or even when going into AmigaOS screenmode program (before available screenmodes are listed), Amiga 1260 (Waro 1260), AmigaOS 3.5 and it happens in pure AGA modes (native or without native). I didn't install any particular driver as I don't own any of the supported cards, I though manually put monitor file for CSWARP.card, Picasso96settings file and the driver itself (Warp 1260's RTG) and these modes are working fine.

I can record a video in the evening and share if it helps, no problem. Thank you in advance for help/

[Thomas Richter]

If you don't load the "Native" driver on a non-graphics-card machine, then P96 is not even loaded. Thus, certainly not a problem of P96. Probably have a look at the picture datatype, you should prefer the one that came with the Os.

[Jacques]

It all changed after installing P96 in place of old Picasso 96, though, for sure it happens WITH native. As for without, now I'm confused and will need to re-check. As well, I haven't changed picture datatype over P96 version upgrade from the old, free one.

[jurassicman]

Hi guys, How can I check which version of P96 drive I'm using at the moment?

[gdonner]

Originally Posted by jurassicman

Hi guys, I can I check which version of P96 drive I'm using at the moment?

From Thomas in a previous post:

"The best way is to look into the "History.readme" version that came with the package. Failing that, the second best way is to type

version LIBS:Picasso96/rtg.library

in a Shell window, which allows me to find out the distribution version."

[jurassicman]

Thanks gdonner! I did miss that post...

[wiz12]

Could the version number be implemented in Picasso96Mode in the Project/About menu?

[gdonner]

Probably old news by now, but just in case, there's a typo in the version string of Picasso96Mode from the P96 v3.3.0 archive. I suspect it should be v1.684, rather than v1.664:



(Picasso96Mode from P96 v3.2.4 is v1.683)

[Thomas Richter]

There is certainly no typo, because nobody types in this string. You've got the right version, though. The problem for the seemingly lower version number is that 3.3.0 and 3.2.x were developed in parallel, but no worries, the changes from the 3.2.x branch are merged in, just not the version number it seems. That was some kind of mis-guidance from subversion.

[Thomas Richter]

Here we go again! The 3.3.1 of P96 has been released and can be bought or downloaded from your order history at iComp.

This is again a minor service release providing the following features:

- The Cirrus5434.chip driver was broken (Piccollo64, Matze's graphics card) and did not switch back from direct color modes to chunky modes.
- One release of UAE had an issue by indicating that it would support mode mixing, but forgot to provide the necessary call-backs in some configurations. P96 provides now default call-backs avoiding the crash.
- Bitmap handling was simplified and streamlined.
- The Visiona driver supports now panning and interlace.
- The installer places now the P96 version into ENVARC:Picasso96/Version so you know what you have on the system.
- The installer no longer provides wrong default selections for the available boards in case the list of installed boards requires more than one page.
- The installer makes a very tiny consistency check on the unpacked files as some people unpacked on the PC, and then protection bits were incorrect.

[alexh]

Thanks for all the hard work.

[Swe_Kryten2x4b]

Thanks for the update.

Just wanted to take this opportunity to hear if I'm the only one that has experienced this starting with 3.3.0.

AmiTube doesn't seem to like it all that much...it either gurus when trying to download a video or it freezes after trying to quit (if network was uninitialized and just being just to start the playback).

I know it's probably very far-fetched but I can't think of anything else that has changed on my system.

[gdonner]

Thomas, as always, thanks for this latest update--much appreciated!

[Leon Besson]

Same here Thomas. Good stuff Bromigo!
Glad I invested in this.

[Solskogen]

Can you add back uaegfx so we don't have to do the manual steps after installation?

[cloverskull]

Yes, strong +1 here, as someone paying (happily) for the Picasso96 updates, when I use UAE, I revert to old pre-Indivision builds since setup is straightforward.