P96 3.0.0 (and later) news and support

[dschallock]

What is the best way to check the version of the p96 install package?

The archive itself does not indicate the version from icomp and there isn't a document inside the archive with a version history.

I want to keep my updates straight. Sometimes if somethings goes awry with my system I restore from a backup and I want to make sure I have the latest version of p96 again.

Thanks!

[wiz12]

Originally Posted by Thomas Richter

The radeon driver is not maintained by me. So what was the last version this worked? As a workaround, you can use the softsprite (SOFTSPRITE=Yes in the tool type of the monitor).

This is most unusual but the problem now seems to have resolved itself and the mouse pointer graphics is no longer corrupt. Even after rebooting a few times the mouse pointer would still be corrupt but now it is suddenly ok again. I don't know why this would occur.

[Thomas Richter]

Originally Posted by dschallock

What is the best way to check the version of the p96 install package?

The archive itself does not indicate the version from icomp and there isn't a document inside the archive with a version history.

I want to keep my updates straight. Sometimes if somethings goes awry with my system I restore from a backup and I want to make sure I have the latest version of p96 again.

Thanks!

The best way is to look into the History.readme version that came with the package. Failing that, the 2nd best way is to say "version rtg.library" on the shell, which allows me to find out the distribution version.

[hexaae]

@Thomas
A doc explaining all Picasso options (tooltypes)...?

[gdonner]

Originally Posted by hexaae

@Thomas
A doc explaining all Picasso options (tooltypes)...?

If it helps, Tool Types are listed in the "PICASSO96_ENGLISH.GUIDE" file included in the P96 archive.

[hexaae]

Thanks, I missed it, ooops... even though some options I can see in PVS are not documented in the guide:

[PeterK]

Btw, PVS has a "Bubble Help"-function when you move the mouse pointer over the buttons and just wait a short moment ...

[hexaae]

Originally Posted by PeterK

Btw, PVS has a "Bubble Help"-function when you move the mouse pointer over the buttons and just wait a short moment ...

Of course but wondered if there was an extensive doc explanation for those options...

[gdonner]

Thanks, I missed it, ooops... even though some options I can see in PVS are not documented in the guide:

No worries I believe some of the Tool Types in PVS may have been discontinued in newer versions of P96. There might(?) also be some Tool Types in P96 v3.2.2 that Thomas just hasn't had a chance to add/update yet in the docs.

In any case PVS v3.8 definitely needs updating to match the current set of Tool Types in 3.2.2. I asked Cosmos about it, and he only has the raw disassembled PVS source. He's asked the PVS author, Ralph Torchia, twice now for better code, but no answer. So at the time of writing, he doesn't know if he can make more changes at this point, as adding only the video cards in v3.8 was very easy...

BTW, though I highly doubt Olaf Barthel has the time for further development on it, I could wish that his far more user-friendly PicassoMode TNG (below) got the spotlight instead of Picasso96Mode; but I'm certainly not complaining that Thomas is cleaning it up--it's just Picasso96Mode's confusing GUI that makes me think a rocket science degree is required to use it.

[Thomas Richter]

Originally Posted by hexaae

@Thomas
A doc explaining all Picasso options (tooltypes)...?

Actually, this is pretty much in the guide. However, let's see...


P96 settings come from 3 sources: The P96 monitor settings, stored in DEVS:Picasso96Settings. They define resolutions and modes, and this file is created by P96Mode.


Then, the tooltypes of the monitor icons, which apply to a specific RTG board only, and finally, global settings in ENVARC:Picasso96.

[Thomas Richter]

Monitor tool types: There are some global ones that are always supported, by every board, and there are some that are specific to boards.


The following are global:


SOFTSPRITE=Yes|No: This turns on rendering of the mouse pointer through software. If SOFTSPRITE=no, then the board is allowed to use a possibly present hardware sprite for its pointer. Typically, the hardware pointer, if it is available, is preferred as it is faster and causes less flicker.


BIGSPRITE=Yes|No: Enlarges the sprite by a factor of 2 in both directions. This only works for the standard 16 pixel wide sprite, the 32 pixel wide "hi-res" sprite is always "tiny". How large the sprite appears depends on the graphics board. The softsprite is always in pixels, i.e. 16 pixels wide, or 32 pixels wide. It can also be enlarged by by tooltype.


BORDERBLANK=Yes|No Enables a black border around some modes on some boards. Actually, on most VGA cards, hi-color and true-color modes have always a blank border, and only chunky and planar modes may not have one. Even for those modes, the border or the size of the border depends on the mode settings created by P96mode. Only if the border setting is non-zero, there is a border to be blanked - or shown in the background color. Border blanking makes much less a difference on P96 than it does on native hardware.


DISPLAYCHAIN=Yes|No Tells P96 whether the graphics board is part of the display chain, that is, part of a cable running from native Amiga video, through the board, to the monitor. A board that is not part of the display chain is understood to have a separate/independent monitor and cannot be switched to the same monitor as the native output. If you want P96 to switch between two monitors, one of the boards cannot be part of the chain and therefore has to have a separate monitor.


IGNOEMASK=Yes|No: Some boards profit from ignoring the write mask of the rastport. This is a bitfield by which a user of the operating system can restrict rendering to only a subset of the planes of the planar operating system. RTG graphics is typically chunky and does not have planes, and hence graphics operation may slow down if the mask should be taken into consideration. However, it is not quite following system rules to simply ignore it, and some programs may render incorrectly. I would keep this as "No" as this is a more conforming setting, as the slowdown is only rarely visible and only few programs are affected. However, those that are render then correctly.



NOPLANAR2CHUNKYBLITS=Yes|No. Ditto, this is not in active use anymore.


NOBLITTER=Yes|No. If set to No, the on-board blitter (2D-accelerator) of the board is disabled. If so, the CPU does all the rendering. Depending on the capabilities of the board, only a subset of the operations may be accelerated, and some of them are run through the CPU. This option is mostly useful for testing, as rendering through the CPU is typically slower than rendering through an on-board blitter.


SYSTEM2SCREENBLITS=Yes|No Some drivers have the capability to have the blitter manually fed by the CPU, and then performs color expansion. This option enables this functionality. Typically helps performance, but can be disabled for debugging.


QUIET=Yes|No: If set, suppresses error messages from the monitor icon, for example if the board it is responsible for cannot be found.


OVERCLOCK=Yes|No. If yes, may provide access to somewhat faster frequency settings on some boards that are beyond what the hardware vendor specified as "safe for use". If you enable overflocking, some additional higher resolutions may become available, though potentially with some graphic defects. In worst case, the graphics chip could overhead, age earlier, and may even run defective from it. Not recommended.


GRANTDIRECTACCESS=Yes|No. Allows direct access to the video RAM of the board. Acually, what this setting typically does is that it disables(!) a couple of video modes that use an on-board aperture switch to swap the endianness of words or long-words. It does nothing else, i.e. the P96 protocol for VGA memory access does not change. This setting is only a workaround for badly written software that incorrectly bypasses P96 to gain direct access to video RAM, and would fail or create incorrect results if P96 changes the video aperture. Thus, it creates a more restrictive selection of video modes. Generally not recommended, only makes your life harder by making some modes not available, and only useful as a safeguard against some software.


FAKENATIVEMODES=Yes|No: If enabled, disables native Amiga modes and promotes them to similar standard VGA modes. This is a simple software-based mode-promotion utility. Actually, this tooltype is automatically enabled for some boards such as the CVISIONPPC as its firmware makes native modes unaccessible through some proprietary patches.


BOARDTYPE=<name of card file>: Tells P96 which card driver to load for this board. For example, if the boardtype is "PicassoII", P96 will load LIBS:Picasso96/PicassoII.card to initialize a picasso video card. The card driver is then responsible for finding the proper ".chip" driver.


SETTINGSFILE=<monitor settings>. Tells P96 where to take settings for this particular board from. If not given, the settings for all boards come from DEVS:Picasso96Settings where P96Mode stores them, but in principle, you could also keep the settings in ENVARC:, or have separate settings files for each board.


MEMORYCLOCK=<value> Defines, to the degree possible, the clock by which the VGA memory is clocked. This is a very board specific value, and most boards would ignore this as they set the memory clock themselves, or compute the necessary clock from the video clock. Typically not advisable to touch, leave undefined.


Some board-specific tooltypes, not handled by P96 itself, but by some of its card drivers:


INTERRUPT=Yes|No. Allows the generation of vertical blank interrupts. This sounds like a good idea as it allows synchronization to the video beam and makes WaitTOF() operational, unfortunately VGA interrupts are glitchy on some boards, in particular the CVision3D. Also, the CVisionPPC card allows disabling of interrupts.


FASTDRAWLINE=Yes|No: Allows or disallows accelerated line drawing through the blitter for the cvisionPPC. Only for debugging purposes as I'm not aware of glitches in the line drawer right now.


MEMORYTYPE=Old|New: Allows to select between two different memory types and by that memory timing for the cvisionppc. The default one is "New". If you see strange glitches, or erraneous pixels on the screen of the cvisionPPC, try "Old".


SWITCHTYPE=JAVOSOFT: Enables an external VGA switch for some boards which do not have an on-board VGA switch. Unfortunately, I do not know how the interface works as it is not directly managed through P96, I can only give boards that parse this tooltype, namely the cvisionppc, the cvision3d and the retinaBLT. Switching is, as said, done by some external piece of software I do not have.


So, that's probably it for the tooltypes ...

[hexaae]

Thank you

[dalek]

NOBLITTER=Yes|No. If set to No, the on-board blitter (2D-accelerator) of the board is disabled.

Is this the right way around? NOBLITTER=Yes sounds like it should disable the on-board blitter instead of NOBLITTER=NO

[gdonner]

Originally Posted by Thomas Richter

IGNOEMASK=Yes|No

IGNOREMASK (typo)

Just curious if the old FONTSFIX=YES|NO Tool Type is obsolete? I suspect it is?

Thanks for posting the additional Tool Type details, Thomas--very helpful!

[Thomas Richter]

Originally Posted by dalek

Is this the right way around? NOBLITTER=Yes sounds like it should disable the on-board blitter instead of NOBLITTER=NO

Trouble with double negation... NOBLITTER=Yes disables the on-board blitter and performs all blitting operations with the CPU. NOBLITTER=No is the default and enables the RTG blitter, if there is one.


A name like "CPUBLITTING" would have been better...

[Thomas Richter]

Originally Posted by gdonner

Just curious if the old FONTSFIX=YES|NO Tool Type is obsolete? I suspect it is?

This is a card-specific tool type that is only parsed by the PicassoII driver, and evaluted by the Cirrus542x chip driver. I'm not sure why this should be only necessary on the Picasso-II and on no other cards based on the same cirrus chip. It seems to disable the accelerated BlitTemplate function for hi-color screens and the JAM1 rendering mode.

[Thomas Richter]

There are a couple of environment variables in ENV:Picasso96 (or ENVARC:Picasso96, where they are stored permanently) which also impact P96. They can also be changed while P96 is running, and changes are immediate.

ENV:Picasso96/AmigaVideo: Defines how P96 should configure the Amiga video if no RTG screen is present and all boards are in the display chain. This can be "31kHz" or "15kHz". This can be useful to allow higher audio playback frequencies while P96 is active.

ENV:Picasso96/Debug: Enables debug output for some functions. Only enable you're asked to do so. Actually, there are not that many debug traps anymore.

ENV:Picasso96/BlackSwitching: This is currently disabled. It should turn the display of those boards off that have currently no active display.

ENV:Picasso96/DirectColorMask: In case this is set to "Yes", then the rastport plane mask even applies to blitter operations in direct color modes, i.e. hi-color and true-color modes. This creates, unfortunately, a lot of overhead as for each pixel P96 has to find its palette index in a reverse lookup, then masks the palette with the mask, includes the new data, and then takes the pen again from the palette which is then rendered to the screen. This may help some programs that use the rastport mask to operate correctly on direct-color modes, but for quite a price. Unfortunately, line drawing, pixel plotting and ellipse drawing are unaffected, though should be affected. In general, not recommended to set as it can make P96 quite slow, and as it is not fully operational at this stage either.

ENV:Picasso96/DoNotSetMMU: Affects whether P96 sets the video RAM of boards that allow this to "imprecise nonserial". If "Yes", then video RAMs remain at "cacheinibit", if "no", video RAM of supported boards is set to "nonserial imprecise", which is a somewhat faster setting. In general, leave this at "No" except for debugging.

ENV:Picasso96/ShowModes: Defines which modes P96 makes accessible on the screen mode requester. This can be "Essential" in case only the most important/useful modes are shown, or "All" in case everything the board supports is shown. It can also be a hex mask that identifies for each bit whether a particular mode is enabled.

ENV:Picasso96/PlanarOnlyDIPFDBUF: Enables or disables the double-buffering capability of non-planar screen modes. By default, all modes support double buffering. If Yes, then only planar modes support double buffering, otherwise all modes support double buffering. Actually, I'm not quite clear why this is helpful. By default, all modes support it. This just sets a flag in the display info database.

ENV:Picasso96/DisableAmigaBlitter: If "Yes", all blitting, even on native Amiga screens, is performed by the CPU. This is typically faster than the native blitter. This flag is set by the "Native" driver.

ENV:Picasso96/PlanesToFast: If "Yes", then non-displayable planar planes are allocated in fast memory rather than chip memory. Most helpful to safe some memory. Such bitplanes can only be blitted by the CPU, obviously. P96 is smart enough to detect itself which planes require the CPU for blitting.

ENV:Picasso96/Experimental: Do not set. (-:

ENV:Picasso96/EnableBootVGA: enables or disables the BootVGA:Productivity monitor. I'm not quite sure where this monitor shows up.

ENV:Picasso96/AlertSupport: If "yes", then system alerts (aka "guru"s) are shown on the active RTG screen. This is also the default.

ENV:Picasso96/AreaEndSupport: If Yes, then AreaEnd() is also performed by P96 and the CPU. This is also the default. As I am not aware of drawbacks or defects in the implementation, this is also the recommended setting.

ENV:Picasso96/PreferFriends: This impacts the memory management of P96. If set, then friend bitmaps of the current visible front bitmap are preferably kept in video memory. Otherwise, they are migrated as easily as all other bitmaps.

ENV:Picasso96/DepthIncludesAlpha: Defines whether the number of colors recorded in the display info database includes the alpha or stencil bits of the video modes. P96 by default follows the system definition and records there only the number colors. If set, then P96 follows the CGfx convention and includes the stencil bit and the alpha byte in the "number of colors" enumerated in the display info database. The default is "no", which is also the system conforming setting. Some CGFx based programs may require "yes" here.

[PeterK]

Thanks a lot for all these detailed descriptions and explanations of the PVS options!

[tomcat666]

Hello.

A bug report for the P96ScreenCx utility:

When using the popular AmiStart utility for taskbar ( https://aminet.net/package/util/wb/AmiStart ) with the P96ScreenCx for multi monitor support the mouse repositioning does not work anymore properly. When you have Native Monitor on the left side and P96 monitor on the right (RIGHT_OF=Native tooltype) then when you leave one monitor it positions the mouse on the wrong side on the other monitor.
I have tried all possible tooltypes and settings in AmiStart and couldnt find what would be causing this. As soon as I quit AmiStart the normal behavour is back.

[Thomas Richter]

Sorry, but I have no idea. The only task P96ScreenCX does is to push a mouse move event into the input device, using the official API of the input.device. Have you tried contacting the author of the problem?