P96 3.0.0 (and later) news and support

[Thomas Richter]

Just put a new version of P96ScreenCx into aminet which fixes the workbench parsing issues and is more informative in case of errors.

[tomcat666]

Thank you for the new version.
I get the error "All P96 boards are in the display chain, monitor switching is pointless".
But I have the "DISPLAYCHAIN=No" set for the PiGFX monitor. You can see the DISPLAYCHAIN=No in the Icon Info of PiGFX in the screenshot (also I have both Native and RTG screens on simultaneously at that point), also I am adding the output of the Snoopdos:

[Thomas Richter]

Originally Posted by tomcat666

Thank you for the new version.
I get the error "All P96 boards are in the display chain, monitor switching is pointless"

And there you have your problem. I cannot solve this for you. Apparently, the way how you start the monitor is not what you think it is - you are probably starting it from a different icon, a different directory, or a different mechanism and you are looking at an icon that is not used for starting it. I'd suggest to use "WBLoad" in the startup-sequence to do so:

WBLoad DEVS:Monitors/PiGfx

Or whatever the icon is called...

A line that loads all monitors would look as such:

list DEVS:Monitors/~(#?.info) files lformat="WBLoad %s" | execute

under Os 3.2.

[tomcat666]

I was loading them in startup-sequence with the

LoadMonDrvs >NIL:

I have commented it out and replaced with what you suggested:

WBLoad DEVS:Monitors/PiGFX (also with the List and execute as you suggested)

I get the same error "All P96 boards are in the display chain, monitor switching is pointless".

There is no different icon or directory, this is the only place with PiGFX. If I remove the "DISPLAYCHAIN=No" from this icon then I don't get multiple monitor support at all, so this icon is used and now it is also loaded with WBLoad DEVS:Monitors/PiGFX .

Also, if you check the SnoopDOS output you will se that the utility never reads the DISPLAYCHAIN tool type at all, only BOARDTYPE. You sure there isn't a bug somewhere?

[Thomas Richter]

Yes, I'm sure because this tooltype is read by P96 (not by P96ScreenCx) and placed there in the board information. Well, unless the driver resets or manipulates the bit in some way, but in that case, I'm out.

Yes, this is tested on the CVision3D and the GBA-PII++.

[tomcat666]

Originally Posted by Thomas Richter

Yes, I'm sure because this tooltype is read by P96 (not by P96ScreenCx) and placed there in the board information. Well, unless the driver resets or manipulates the bit in some way, but in that case, I'm out.

Yes, this is tested on the CVision3D and the GBA-PII++.

The multi monitor support works fine with PiGFX , I have 2 monitors up and running as we speak, so I guess the DISPLAYCHAIN=No is properly handled by it ? I will ask the developer, maybe he will have some insight.

[tomcat666]

Got the info back. The driver is, of course, open source, but the answer to your question is "Both the ZZ9000 and the PiGFX driver set the INDISPLAYCHAIN flag on InitCard. Does P96 not override those flags once the card has been initialized?" The driver does not do anything with the flags once they are set/reset.

[Thomas Richter]

No. This flag is set or reset by P96 upon initialization of the card, and then further tuning is left to the card driver (obviously, this is the right order as the driver should have the last word). By setting this flag, the card driver indicates that the card is always part of the display chain (i.e. by the cable that runs from the native video output to the monitor), thus essentially forbidding the user to connect a second monitor. The driver can, for example, always *clear* the flag in case the card does not contain a VGA switch and the user MUST connect two monitors, but always setting the flag makes no sense as it is up to the user how to layout the cabling.

[tomcat666]

Thank you Thomas. With this information _Bnu was able to modify the driver so it now works perfectly !
Never thought I would see the day when we have proper multi monitor support on Amiga.

Great work !

[tomcat666]

Only one little thing - when going from RTG to Native the mouse pointer stays on the RTG screen in the position where you left it. Is there a way for the driver to know that it should remove the mouse pointer?

[alexh]

Originally Posted by tomcat666

Only one little thing - when going from RTG to Native the mouse pointer stays on the RTG screen in the position where you left it. Is there a way for the driver to know that it should remove the mouse pointer?

Is this the "mouse blanker" app discussed earlier in this thread? Or is that something else?

[Thomas Richter]

Originally Posted by tomcat666

Only one little thing - when going from RTG to Native the mouse pointer stays on the RTG screen in the position where you left it. Is there a way for the driver to know that it should remove the mouse pointer?

There is a way, namely the boardinfo->SetSprite() function which is used to turn the sprite on and off. If the board does not supply this function, the sprite always remains on. Alternatively, use "SoftSprite=Yes" in the monitor tool type, then P96 will render the sprite with pixel graphics (at the price that the pointer then flickers when scrolling, etc...)

[tomcat666]

Originally Posted by Thomas Richter

There is a way, namely the boardinfo->SetSprite() function which is used to turn the sprite on and off. If the board does not supply this function, the sprite always remains on. Alternatively, use "SoftSprite=Yes" in the monitor tool type, then P96 will render the sprite with pixel graphics (at the price that the pointer then flickers when scrolling, etc...)

_Bnu implemented the SetSprite() function and everything is working as expected. Sprite gets blanked when you are outside the RTG and reappears when you come back. Thank you !

[tomcat666]

A little demo to show how it works on the piStorm. Never mind the loud tank mouse

[ Show youtube player ]

[hexaae]

@Thomas Richter
You have PM

[Thomas Richter]

Just put a small demo source into the aminet that demonstrates how to use the "picture in picture" function some graphic cards offer, notably the Picasso-IV and the CVision3D. "Picture-in-Picture" aka "overlays" allow to display content in a window in a "screen mode" that is different from the mode of the main screen the window is on.

What is particularly interesting about this is that the mode of the overlay can also be a mode that is not even supported as screen mode, for example "YUV 422". For such overlays, the graphics chip performs a color space conversion and upsampling "for free", and thus software can spare the last step in the decoding of video or pictures.

If this feature sounds exotic to you: All modern graphic cards offer such overlays, the generation of the Cirrus chip on the P-IV and the S3Virge on the CVision3D were just the first generation that provided the feature. All later chips are just hard to find in the Amiga.

Unfortunately, this feature was poorly documented, so I attempted to provide some source how to use it. The program itself does not do anything fancy, it just seems to draw an ellipse in a window. However, this ellipse is an overlay, which you can clearly see if you resize the window. The graphics chip will, in this case, scale the window contents for you, free of charge, without even getting the program involved. Thus, there is no software upscaling involved, all done in hardware.

BTW, this is the same type of overlay the Linux "libxv" library provides on Xorg, just the P96 interface for it.

If you don't see an overlay, be reminded that older graphics chips do not offer this feature and not all drivers support it. At this point, P-IV and CVision3D do of the "in-house drivers". Also, there are some restrictions for the CVision3D (similar may hold for the P-IV): First, the overlay does not work on scandoubled modes, on double-pumped modes (>1024 pixels horizontally), or if screen-dragging is active as these modes are created by a different logic on the chip.

Second, overlaying one image by another can double the required bandwidth, and thus the overlay may flicker or disappear if the memory bandwidth is not sufficient to pull both the overlay and the screen background at the same time from the vga memory. Thus, for the S3 chip, this restricts overlays to 800x600 resolution (approximately, details depend on the video frequency).

Hope this helps to shed some light into one of the dark corners of P96.

[stefcep2]

Does this work with a real Amiga A4000 CSII 68060 and CV64?


Does it work with amithlon?

[Thomas Richter]

It surely works in a real Amiga as it has been tested on a real Amiga, but the CVision64 is based on the Trio64 chip, and this chip is just one generation too old. It is the predecessor of the S3Virge, which was the first chip from S3 that supported overlays.

As Amithlon is not driven by any of the "in-house" P96 drivers, I cannot answer the second question.

[stefcep2]

Ok Thanks Thomas.

Just to clarify do you mean on the CV64 this version doesn't work *at all* or is just missing some features?

And sorry if this is a simpletons' question, and you may not know the answer but with amithlon, why is Picasso96 version 2 installed as are the updates to it?

[Thomas Richter]

Originally Posted by stefcep2

Just to clarify do you mean on the CV64 this version doesn't work *at all* or is just missing some features?

The CVision64 is supported by P96 and works fine as far as I know, including screen dragging. So no problems in that direction, just that the hardware itself does not provide overlays required for this test program. Sorry, I cannot test this myself as I lack a card and an Amiga to plug it in, I can only check through betatesters. The latest thing I added to the driver was screen dragging support, and from what I know, this works fine. Just implemented from the specs. (Donor Z3 machines and CVision64 boards for potential driver improvements of course accepted. (-

Originally Posted by stefcep2

And sorry if this is a simpletons' question, and you may not know the answer but with amithlon, why is Picasso96 version 2 installed as are the updates to it?

On Amithlon? Well, probably its makers/mainainers (if they exist anymore) should get in touch with Jens/iComp to get the new version licensed? P96 is commercial software.