P96 3.0.0 (and later) news and support

[Thomas Richter]

Thanks!

[Thomas Richter]

A new and completely revised version of the driver API documentation is now available under

http://wiki.icomp.de/wiki/P96_Driver_Development

This includes of course the new function for screen dragging support, but the specification of all other functions have been revised and checked.

Have fun,

Thomas

[klx300r]

thanks for the update Jens/ Thomas!

[Saghalie]

Do you have a way to notify registered users of updates? Or do we need to just follow this thread?

[Thomas Richter]

There will be notifications in the icomp forums, and I will also post here. The latest version is still 3.0.2, and there are no bugs open, so I guess we're good.

[fehmi]

I have a question about screen dragging. My experience is with an emulated environment; I don't exactly know how screen dragging works / should work on real hardware.

I installed P96 3.0.2 on AmiKit XE. When I try screen dragging with ChaosPro, I am able to drag the screen and see Workbench behind it. However, navigation with the mouse is pretty much broken. For instance, when I move the mouse up to Workbench, even though the cursor is still visible on the ChaosPro screen, mouse buttons are registered on Workbench. I can only navigate on Workbench by blindly clicking on random spots. That said, once I reach to ChaosPro window by trial-and-error, I can either drag the screen up or close the program without any issue.

I know that AmiKit is a highly customized Amiga setup; that is why I posted the same question on their forum, as well. Below is a breakdown of my setup:

WinUAE 4.9 Beta 19 (also tried beta 3, 16, 17, and 18)
Picasso96 3.0.2
Workbench 3.X and Kickstart v3.1 (amiga-os-310-a1200.rom) from Amiga Forever 9
AmiKit XE 11.4.2 (default configuration - attached)
Windows 10 20H2
GeForce RTX 2070 Super (tried drivers 466.11 and 466.27)

[Thomas Richter]

For all hardware drivers, clicking on the topmost screen works and delivers the mouse click at the right position, I ensured that. This is likely a defect in the winUAE driver which I do not maintain, please inform Toni on this.

There is an updated SDK on the iComp page, and there is also a long entry in the wiki on the updated driver API.

[Toni Wilen]

Originally Posted by fehmi

I have a question about screen dragging. My experience is with an emulated environment; I don't exactly know how screen dragging works / should work on real hardware.

AmiKit has far too many unknown parts. Try with more default WB first. And make sure no extra mouse options are enabled like "virtual mouse driver".

[Thomas Richter]

True, though I have seen similar issues on the beta of the ZZ9000 driver, and there the issue was that the driver did not update some internals of the boardinfo structure. With screen dragging enabled, it becomes necessary that the driver updates the MouseX/Y cooridinates and the YSplit member of the board info, so I suggest to have a quick look at your sources and compare that with the Wiki and the reference driver.

This variable update wasn't strictly necessary without screen dragging, but while the reference driver always did this, some third party implementations may have not.

[fehmi]

Originally Posted by Toni Wilen

AmiKit has far too many unknown parts. Try with more default WB first. And make sure no extra mouse options are enabled like "virtual mouse driver".

I tried the same with Workbench 3.X that came with Amiga Forever 9 - I replaced the stable WinUAE with Beta 19 and ensured 32-bit version is launched by choosing "Play with WinUAE (32-Bit)".

I was able to drag the ChaosPro screen and the cursor was visible on Workbench when I moved the mouse up. However, I encountered another issue this time - the cursor was invisible on the lower screen. I had to click blindly to find the right spots. Also, random horizontal bars started to appear in the screen below and there was even a second mouse cursor left-over - please see attached.

[coldacid]

fehmi: Does it work with WinUAE 4.4.0?

[fehmi]

Originally Posted by coldacid

fehmi: Does it work with WinUAE 4.4.0?

My understanding is that screen dragging doesn't work on WinUAE 4.4.0. Below is from the change log of WinUAE 4.9.0 beta series:

- uaegfx Picasso96 2.5.0 screen dragging support added.

[coldacid]

Ah, yes. Forgot about that.

[Toni Wilen]

Originally Posted by Thomas Richter

True, though I have seen similar issues on the beta of the ZZ9000 driver, and there the issue was that the driver did not update some internals of the boardinfo structure. With screen dragging enabled, it becomes necessary that the driver updates the MouseX/Y cooridinates and the YSplit member of the board info, so I suggest to have a quick look at your sources and compare that with the Wiki and the reference driver.

I can't find any MouseX/Y modifications in included example driver and YSplit isn't modified anywhere else than in SetScreenSplit().

Originally Posted by fehmi

However, I encountered another issue this time - the cursor was invisible on the lower screen. I had to click blindly to find the right spots. Also, random horizontal bars started to appear in the screen below and there was even a second mouse cursor left-over - please see attached.

It sounds like hardware sprite emulation is not enabled and any drag operation forces full screen refresh. Hardware sprite can't leave any mouse cursor remains because it is separate 3D object rendered by Direct3D.

Check that Direct3D mode is enabled (Misc panel 9 or 11) and uaegfx.info does not have SOFTSPRITE enabled.

(But even in softsprite mode there shouldn't be any garbage but it also isn't emulator's problem anymore)

[Thomas Richter]

Originally Posted by Toni Wilen

I can't find any MouseX/Y modifications in included example driver and YSplit isn't modified anywhere else than in SetScreenSplit().

Sorry, my fault. So what the driver is supposed to update is XOffset/YOffset in SetPanning. It also *should* update MouseX/MouseY in SetSpritePosition(), though for some legacy reasons, it does not. The rtg.library does that for the driver, in addition to passing the coordinates in.

To the user: A possible workaround is to enable the softsprite in the tooltypes of the monitor driver.

[fehmi]

Originally Posted by Toni Wilen

Check that Direct3D mode is enabled (Misc panel 9 or 11) and uaegfx.info does not have SOFTSPRITE enabled.

Originally Posted by Thomas Richter

To the user: A possible workaround is to enable the softsprite in the tooltypes of the monitor driver.

I have checked above on 2 setups - Workbench 3.X on Amiga Forever 9 and AmiKit XE. I have ensured Direct3D is enabled (tried both 9 and 11) in each configuration. Subsequently, I have tried screen dragging with softsprite enabled and also disabled (rebooted after each change); however, softsprite had no effect on below -

Workbench 3.X: Once I drag the screen and move the mouse up, the cursor is visible on the upper screen (i.e. Workbench) and works just fine. However, the cursor becomes invisible once I move the mouse down to the lower screen (i.e. ChaosPro).

AmiKit XE: Once I drag the screen and move the mouse up, the cursor still moves inside the lower screen (i.e. ChaosPro). However, the actual mouse movements and clicks happen on the upper screen (i.e. Workbench). In other words, I can blindly navigate on the Workbench while the cursor continues to move in ChaosPro screen.

Edit: Attached a configuration file, a crash log, and relevant screenshots from Workbench 3.X -

• AF9_cursor_problem: Screen dragging is broken as described above with this configuration.
• AF9_crash: As soon as I drag the screen, WinUAE crashes with window Select Arabuusimiehet.WinUAE.

I do not wish to hijack the P96 thread if this is no longer related to P96 - please advise if it needs to be moved to the WinUAE section.

[Thomas Richter]

SoftSprite=Yes vs. SoftSprite=No in the monitor icon should definitely make some observable difference. If you don't spot the difference, you probably made the change in the wrong place. Unless the UAE driver does not have a hardware sprite at all (which would surprise me, but I don't know).

[Romanujan]

Originally Posted by Thomas Richter

This release provides one new (important) feature, and that is screen dragging. It requires support from the chipset, namely the VGA line compare register, and updated drivers to include the new API. (...) Note that screen dragging has certain restrictions that all stem from the limitation of the VGA chips and the corresponding boards: (...)

Do modern RTG implementations (like WinUAE, MiSTer, MNT VA2000, Warp 1260) suffer from these restrictions too? Or is it possible for them to provide a driver that will overcome them?

[Thomas Richter]

Modern RTG implementations are those made by modern graphics cards, and they suffer even more by no longer implementing the legacy VGA engine, in particular the VGA line compare register the P96 logic currently depends upon, thus you cannot drag screens on VGA chips later than approximately 1996 or so at this point. The Permedia2 in the CVisionPPC is one of the first examples that do not support screen dragging due to its modern (relatively speaking) GPU.

On Os 4, screen dragging is implemented by completely different means, namely by composing the display in the graphics card by "blitting" the memory contents of the screens to the frame buffer. That is, screens there become something like windows, with the advantage of also allowing horizontal arrangements of screens. As part of this process, one can also convert the color representation - modern GPUs do that in no time, and you would be able to "mix modes" any way you like. The frame buffer would be true-color anyhow.

However, all of this requires that the applications "play well" and only render by the Os instead of poking directly into memory, something you cannot take for granted, and it also requires that such a fast mechanism for screen composition exists, none of which you can take for granted for legacy Amiga software and RTG hardware.

VA2000 does not have a line-compare register, so it does not support screen dragging. The ZZ9000 has something comparable, though cannot (at this time?) mix modes or switch palettes. Warp 1260 is to my knowledge not a graphics card at all, and MiSTer does to my knowledge not implement RTG graphics but rather only native planar graphics.

Whatever it is: Currently, the "constant-mode" restriction is hard-coded into the rtg.library. There are still bits left to raise this restriction at some point, but I'm surely not going to implement 10 different means for doing so, and I believe depending on particular hardware features only available on dedicated FPGA boards instead of off-the-shelve GPUs is going to be a dead end. In a sense, the Os 4 method is the most future-proof way of doing it, though I did not choose this path right now due to dependency on a fast graphics composition engine you do not find on the 1990th's generation of VGA chips the legacy Amiga RTG cards were built from.

Thus, if "mode switching" comes to P96 at some point, it will likely come in a way that is supported by standard components, and that means "screen composition" though GPUs. This allows more choices to customers and avoids vendor-lock-in problems.

[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?