P96 3.0.0 (and later) news and support

[Solskogen]

Am I blind or is P96 gone from the shop?

[nogginthenog]

Originally Posted by Solskogen

Am I blind or is P96 gone from the shop?

You need to login first.

[slaapliedje]

Originally Posted by Romanujan

I haven't tried RTG support on my MiSTer yet (didn't have time - but I'll definitely try when I get my OS 3.2), some support is definitely there: https://github.com/MiSTer-devel/Mini...95675b8810b1da

As for the Warp 1260, the web page lists the following feature: RTG Graphics – up to 1920x1080 resolution 32bit color and Digital Video output - see http://www.amigawarp.eu/1_5_warp1260...arp1260-photos

I didn't mean PC-world chipsets - I meant software emulated virtual cards, FPGA implementations, etc. BTW, PiStorm also seems to implement RTG, I'm not sure how the Vampire handles it (do they have P96 driver, or their own solution). Of course, having a workaround for each and every such RTG provider wouldn't be feasible - but what about extended driver API that would allow them to support better screen dragging? Maybe even combined chipset+RTG screens displayed at once, if the OCS/ECS/AGA is emulated or provided by FPGA?

The Vampire doesn't support screen dragging in SAGA.

Funny thing is, maybe we can consider it a bug when ScreenMode says that screen dragging is supported, when it isn't on (newer) RTG setups? As it says it's draggable on the V4SA, and it's Draggable on the Voodoo3 I have in my A4000 as well.

Interesting how OS4 'got around it', I put that in quotes because it's slow as shit on the Voodoo 3 in my system :P

[Thomas Richter]

Originally Posted by slaapliedje

The Vampire doesn't support screen dragging in SAGA.

Which is a shame since the hardware could support it.

Originally Posted by slaapliedje

Funny thing is, maybe we can consider it a bug when ScreenMode says that screen dragging is supported, when it isn't on (newer) RTG setups? As it says it's draggable on the V4SA, and it's Draggable on the Voodoo3 I have in my A4000 as well.

The problem is that the "draggable" bit in the graphics database means something different than you think it does. It actually means "screens can be panned", i.e. "supports autoscroll". P96 supports this on almost all chipsets. What is missing is a "screen split" feature on some of them, though there is no bit for that in the database, as strange as it is.

Originally Posted by slaapliedje

Interesting how OS4 'got around it', I put that in quotes because it's slow as shit on the Voodoo 3 in my system :P

In a completely different way. P96 3.x depends on a hardware feature of legacy VGA chips, namely the "line compare register". Os 4 instead moves data around by the blitter. Thus, a "split screen" in Os 4 actually "a window offering transparent window moves". This is of course more flexible, but a lot more resource hungry.


Split-screen is not available on some VGA chipsets, actually on most modern (or actually most "not completely outdated" chipsets, even), and it is thus understandable that Os 4 selected a different design. Of course, this implies that the Os 4 method is very slow on such outdated chipsets.

[Solskogen]

Originally Posted by nogginthenog

You need to login first.

Thank you! :-) It's now bought and installed!

[Thomas Richter]

Yesterday, a new release of P96 became available for purchase. Release 3.1.1 is again a minor "bugfixing" release of the recently appeared 3.1.0, even though there is one major improvement of P96Mode that should hopefully improve the usability of the program (see below).

First, the S3Virge driver (oh no, not again) did not display the leftmost pixel column on 8-bit modes. The "funky" stream processor of the S3 chip is responsible for this issue, which does not like an input signal with border blanking enabled. Funny enough, the output signal it generates always *is* border-blanked, but it does not like a similar input. Thus, to make the output consistent, border blanking on the chip is now turned off if the stream processor is on (which then generated a border-blanked picture without a missing column), and turned on if the stream processor is off (e.g. during screen dragging) thus reproducing the picture of the stream processor. Yikes!

If a software (games mostly) taking over the Amiga display left to workbench, P96 has forgotten to restore the sprite/mouse pointer. This may also improve P-IV support, though I unfortunately cannot test here lacking the hardware.

The "VGA memorial second" that generated a dark screen for a short while when starting to a drag a screen has now mostly disappeared. It is only a short flicker for boards that offer sufficient memory and an on-board blitter. P96 is now smart enough to avoid migrating video RAM and uses now the blitter to re-arrange memory for screen dragging.

Finally, P96Mode was improved in two ways: First, disabled modes are now ghosted, hopefully making it more obvious that they are not reachable by the screen preferences. Second (and more important), P96Mode now pre-populates modes if you create a new setting for a new board. It fills in all the VGA standard modes, so you don't have to create them yourself. You may have to adjust the timing a little bit as every monitor and every card is a little bit different, but the overall timings are those from VESA and thus should give you at least a halfway decent picture on any monitor.

As soon as you "attach" this setting to a card, P96Mode will ask you whether it should disable or erase modes the card cannot realize (e.g. due to lack of memory or bandwidth). For example, a GVP Spectrum cannot generate a FullHD true-color screen, though this mode - being a VESA mode - is pre-populated. Just say "Erase all" to get only the modes the card can do.

Thus, installing a new card should now be done in seconds rather than hours.

Of course, you can still create your own modes. I personally like scan-doubled modes as they fit to the classical workbench "hi-res 1:2" pixel aspect ratio, but as they are on-VESA modes, they are not present. They are easy to create from the regular modes of course.

[Thomas Richter]

As a desert, a tiny commodity for multi-monitor support will appear in the next days in Aminet: "P96ScreenCx".

If you drag this into WBStartup and configure your monitor tooltypes accordingly, then the mouse can travel freely between multiple monitors.

Consider for example that I have my native Amiga monitor to the left, and a second monitor to the right of it that displays the CVision3D screen. For this, the CVision3D must not be in the "display chain" (DISPLAYCHAIN=NO in its tooltypes, i.e. two separate monitors).

Now, put

RIGHT_OF=Native

into the tooltype of the CVision3D monitor icon.

Now, if you move the mouse out of the right edge of the native screen, it appears at the left edge of the CVision3D monitor, and vice versa.

With proper combination of tool types, you can configure yourself an arbitrarily complex monitor wall, sufficient monitors and RTG cards provided.

Naturally, this will require P96 3.1 or better.


The tool is free, you can grab it in the next couple of days from Aminet.

[nogginthenog]

Many thanks Thomas! I'm installing now.

IComp limits the number of downloads which is not cool (I appreciate this is not your problem).

[Thomas Richter]

You can always ask to increase the number of downloads in the support forum. It's just that the shop software requires a number there, and 10 seemed a reasonable choice. (Not that I manage the shop or make such decisions, just to let you know where the problem comes from).

[alexh]

Originally Posted by Thomas Richter

Which is a shame since the hardware could support it.

Absolutely. Lucas added a "line compare register" to the ZZ9000 RTG card so I'm sure SAGA could do the same.

[Thomas Richter]

The FPGA emulates a Copper which could clearly reset the bitmap pointers to 0 at a particular screen region. There is no change in the core required, this could be done right away - just that someone has to do it, and somewhat *wants* to do it. The latter is the problem. It is in their minds, not in the technology - same problem why the hardware doesn't do Autoconf, and requires a patched kickstart, all of which could be easily achieved.

[hexaae]

MOUSE BLANKING ON P96

I have a question as I just noticed today: can't mouse pointer be blanked using a 3rd party utility/commodity in RTG mode?
I've noticed the mouse disappears on specified timeout or after keypresses only with AGA resolutions...

I'm using WinUAE + UAE Z3 RTG emulation... and commercial Picasso96.

[Thomas Richter]

Originally Posted by hexaae

I have a question as I just noticed today: can't mouse pointer be blanked using a 3rd party utility/commodity in RTG mode?

Of course it can if it is done correctly. If such a third party tool pokes into the custom chips to disable the native sprite DMA, then clearly, this won't work. The P96 sprite is not created by the custom chips, it is created by the RTG hardware which won't see this poke.


This is exactly the reason why you shouldn't write into the hardware directly....




If you instead clear out the mouse pointer image through the Os, all is fine. Thus:

UWORD __chip  blankData[] = {0,0,0,0,0,0,0,0};
#define BlankMouse() ChangeSprite(NULL,&blankMouse,(APTR)blankData);
#define UnblankMouse() RethinkDisplay();

[hexaae]

Originally Posted by Thomas Richter

Of course it can if it is done correctly. If such a third party tool pokes into the custom chips to disable the native sprite DMA, then clearly, this won't work. The P96 sprite is not created by the custom chips, it is created by the RTG hardware which won't see this poke.


This is exactly the reason why you shouldn't write into the hardware directly....




If you instead clear out the mouse pointer image through the Os, all is fine. Thus:

UWORD __chip  blankData[] = {0,0,0,0,0,0,0,0};
#define BlankMouse() ChangeSprite(NULL,&blankMouse,(APTR)blankData);
#define UnblankMouse() RethinkDisplay();

Ok, thanks for informative reply. I can't find a single Commodity or tool working on RTG too on Aminet though
Tried this for example, with C sources, but doesn't work http://m68k.aminet.net/package/util/cdity/mouseblanker
They all seem to disable the chipset sprite only.

[Thomas Richter]

What's the problem with the mouse blanker commodity that comes with the Os? It uses the above code and works fine.

[tomcat666]

Hi.

I tried the P96ScreenCx utility on my piStorm here. I have the 3.1.0 P96 installed and it is working fine with both the PIGFX RTG screen and Native screen being enabled at the same time (that is only when the RTG screen is active then one also sees the Native screen. If the Native screen is active then RTG screen is disabled).

I have installed the P96ScreenCx utility as per instructions and added the LEFT_OF=Native line to the toolypes of the PIGFX monitor (The PIGFX monitor also has the DISPLAYCHAIN=No tooltype).
Unfortunetly nothing happens when I go to the left or right edge of either of the screens, it is the same as before. I get no debug output from the utility if I start it from the CLI (otherwise it is in WBSTartup).
Does PIGFX need something special when compiled to have this supported?

Best regards,
Tomaz

[Thomas Richter]

It needs the boardtype to be consistent with the internal library name in LIBS:Picasso96. A similar problem exists with the GBAPII++ card driver whose file name (and thus board type) is GBAPII++, but whose internal library name is GBA-PII++ (with a dash). Thus, if something like that happens, ensure that the card name and the board name are really identical.

[tomcat666]

Originally Posted by Thomas Richter

It needs the boardtype to be consistent with the internal library name in LIBS:Picasso96. A similar problem exists with the GBAPII++ card driver whose file name (and thus board type) is GBAPII++, but whose internal library name is GBA-PII++ (with a dash). Thus, if something like that happens, ensure that the card name and the board name are really identical.

Hmm, still not working.
The internal name is pigfx.card :

pigfx.card PiGFX 43.20 (29 May 2021)

I renamed the Picasso96 card driver in libs from pigfx020.card to pigfx.card
And set the tool type of pigfx monitor accordingly:



And still it doesn't work...

Anything else to check?

Best regards,
Tomaz

[Thomas Richter]

The important part is the internal library name, which shall match the file name, and the board type tooltype. You can check with a system monitor (or the program author). This shall be pigfx.card (and not pigfx020.card).

[tomcat666]

It is pigfx.card ... here is the pigfx.card file:

http://pc.sux.org/tomcat/pigfxcard.zip

When running the P96ScreenCx in CLI and snooping with SnoopDos I don't get any entries for the DEVS:Monitor, I only get this :