P96 3.0.0 (and later) news and support

[tomcat666]

Unfortunetly it is not developed anymore. The native screen has much lower horizontal resolution but it will position the mouse to the furthest right on the new screen, it will not leave the mouse on the same position as on the previous screen... So for some reason it thinks the monitors are in the wrong order.

[Thomas Richter]

There are two aspects here I should clarify:

First, please understand that this utility is not part of P96 and not distributed as part of P96. It is solely authored by me and distributed by me. See also the ReadMe that came with it. Thus, please do not post at iComp, they are not related to this thing.

Second, a technical aspect, maybe I wasn't clear: If the mouse leaves the current screen, P96ScreenCx does two things: It first triggers a screen switch (ScreenToFront()), but this leaves the mouse position in its original place. Second, it moves the mouse to the opposide edge of the new screen to create the illusion that the two screens are side-by-side. This mouse movement is performed by synthesizing mouse movement events through a well-known mechanism of the input.device of a system. For a reason unclear to me, AmiStart seems to swallow these synthetic mouse movement events.

Long story short: I wouldn't know how to solve this problem. I cannot synthesize mouse movement events to push the pointer to the right place in any other way; the current way is the system way. However, I do not know the backgrounds of AmiStart well enough.

Thus, either do without Amistart, or do without P96ScreenCx, there is nothing what I can do, I am sorry.

[tomcat666]

Thank you for the explanation. Really appretitated... Will try debugging it with a friend, maybe he comes up with something

[tomcat666]

Hi

My good friend Amigo/Binary helped with investigation of the issue. Thanks to him there is an elegant fix available.

In a nut shell there is no fault in either P96ScreenCX (as you thought) or AmiStart. The problem is that commodities.library itself removes the events it dispatches forward to the commodities and because it has a priority higher that intuition (int. has 50, commodities have 53) the intuition does not get the events anymore.

He fixed it by having an utility that listens for the same events with priority 51 and puts them back as soon as they arrive so the intuition finally gets them.

Works like a charm too.

If anyone wants the fix and the source, here it is :
http://pc.sux.org/tomcat/AmiStartP96ScreenCXFix.zip

[coldacid]

You or your friend should get that uploaded on Aminet if it hasn't already been. Although seeing as it isn't a fix for P96ScreenCX exactly but rather a workaround for commodities, perhaps with a different name.

[a/b]

Originally Posted by coldacid

You or your friend should get that uploaded on Aminet if it hasn't already been. Although seeing as it isn't a fix for P96ScreenCX exactly but rather a workaround for commodities, perhaps with a different name.

Not sure if it's needed though. Would like to get a clarification from Thomas first.
Namely, events get nullified because class=RAWMOUSE shouldn't have a subclass *afaik*, but his utility is setting it to $10 (couldn't find anything in 3.0 includes, so not sure whether it's some private intuition/input flag, or his own flag e.g. to be able to identify fake event later on when they get dispatched, or something else), which then results in commodities.library event handler at 53 to nullify them: if subclass is not 0 (plus some extra conditions for class=NEWPOINTERPOS that are irrelevant), that for RAWMOUSE events means nullification, and intuition at 50 doesn't get to have them.

[Thomas Richter]

The commodities library does not filter input events out that go "downstream" to intuition, but only those that go to into its handlers, otherwise the commodity would not work at all. The value 0x10 is used here to achieve exactly that, it indicates that the event is "synthetic". The problem P96ScreenCx has to solve is that the synthetic mouse event created by the commodity should not trigger another "recursive" screen switch by the mouse reaching the other end of the screen as part of reaction on the event. The tool cannot know how many mouse ticks the mouse has to travel to reach the other end of the screen and thus may, without a further indication, trigger a switch.

[a/b]

Yeah, I understand that. They get removed when the app is running (it's using cx for event handling, I typically use either IDCMP or input.device so can't tell more about this first hand, and how to avoid it.. exe is ~1MB), but this could be generalized for an arbitrary app?
I did a test earlier with a prio=100 handler that sets subclass of those events to 0 and it doesn't work: events are perpetually generated (as you pointed out) and mouse becomes unusable.
However, wouldn't it be sufficient to use class+subclass+code+x+y combo (rawmouse, 0, nobutton, +/-4095, 0, all legit values) to correctly identify them with 99.9% repeating, and avoid a "problematic" private subclass that cx handler apparently doesn't like (it only allows documented subclasses: $00-$03 for class=NEWPOINTERPOS)?
Either way, I don't have a horse in this race, just an opinion about choosing between 2 evils.

[Thomas Richter]

Actually, what I did there was all just too complicated. Please find a test version attached and please report back.

[tomcat666]

Originally Posted by Thomas Richter

Actually, what I did there was all just too complicated. Please find a test version attached and please report back.

After quick tests on winuae and pistorm a500 everything seems to work fine with this version.
Thank you !

[a/b]

Originally Posted by Thomas Richter

Actually, what I did there was all just too complicated. Please find a test version attached and please report back.

[nagares]

Originally Posted by gdonner

He's asked the PVS author, Ralph Torchia, twice now for better code, but no answer.

I wrote with Ralph Torchia this night.
Sadly, he lost all Amigahardware including software and source codes in a flood.
If he still had it he would release it to the community.

[gdonner]

Originally Posted by nagares

I wrote with Ralph Torchia this night.
Sadly, he lost all Amiga hardware including software and source codes in a flood.
If he still had it he would release it to the community.

OK, thanks for letting us know!

[bubbob42]

@Thomas updated P96screencx to latest Aminet version. Works fine, except for one oddity:

- screen 1: native
- screen 2: rtg pubscreen in front of rtg workbench

Moving pointer between 1 and 2 is fine (TT ActivateWindow is enabled). Now we hit close gadget of the program (YAM) on the MUI pubscreen (screen 2) and move to screen 1 before the pubscreen is closed. Now Screen 2 closes, but the screen stays grey (screen background color). Only switching the screen manually or moving the pointer back to screen 2 will make the grey background vanish and Workbench reappear.

[my_pc_is_amiga]

Thanks Thomas for documenting ENV and Tooltypes here on EAB -- would be nice to have these new descriptions in the P96 guide file in the P96 package. Also, I have noticed the HISTORY readme file that is in the lha does not get copied during the install process. Having the history file copied and a link in the guide would be nice too.

Originally Posted by 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.

[hexaae]

Originally Posted by my_pc_is_amiga

Thanks Thomas for documenting ENV and Tooltypes here on EAB -- would be nice to have these new descriptions in the P96 guide file in the P96 package.

I second that, the GUIDE included in P96 package should be updated.

[Thomas Richter]

I would prefer to move the guide to a wiki on the icomp page, this is easier to maintain and to update for me.

[Thomas Richter]

Actually, as of today, a new version of P96 was provided. It's now release 3.2.3, with the following changes:

- P96 no longer attempts to set the beamcon0 register and the vtotal register
of the custom chips in case the active video mode is on an RTG board that
is not in the display chain.
- Even though bitmaps were locked, memory management could have migrated them
off the board if memory was getting tight. This may have caused quite some
issues on "close-to-zero" memory situations.
- As BlitMaskBitMap was potentially allocating memory for the mask buffer, it
could have migrated the bitmaps it was actually supposed to render, causing
all kinds of havocs. To avoid this problem, source and target bitmap for a
two-bitmap operation are now locked on the board. This is actually a very old
bug that goes back to the 2.x release cycle.
- A possible memory inconsistency in P96Mode was fixed where an incorrect
memory pointer was released.
- The Altais and RetinaBLT drivers did not record the state of the monitor
switch correctly. As a result of this defect, the SetDPMS() function to enable
power saving may have failed, keeping the monitor on all the time.
- The rtg.library may have attempted to switch of the Altais display on a Draco
system without ever turning it on again.
- Fixed a very old bug on adjusting the line pattern shift upon drawing into
multiple cliprects. This bug was apparently introduced while merging my own
P96 version with the last official version by the authors. This bug could have
introduced artefacts when drawing "marquee" effects for selecting multiple
files in alternative file managers.
- When switching buffers on a double-buffered screens, P96 forcibly reloaded the
sprite image, which caused flicker on some RTG boards. This version now avoids
reloading the sprite unless absolutely necessary.

As always, I will provide some more details in the next days.

[hexaae]

WOW! Lots of releases in recent times!

[nogginthenog]

Thanks Thomas!