Posts by hexaae

Got it today on the GMail account, thank you!

Got no confirmation eMail

My order date/number: 06.03.2023 , 130102

Got no mail and I'm still in the free update range from last purchase...

Seems to have been fixed indeed from my quick testing, but I'll wait for a bug-free WinUAE 4.9.2+ version to test it thoroughly since 4.9.1 seems to have a few problems with 3.3.0...

WinUAE 4.9.1 (using hidden switch -p96test 1), OS3.9 + MMULib

The other day I was so excited to test P963.3.0's new feature "different res screen dragging", but I've found it worked (with visible glitches) only on the very first reboot (I manually installed it with a simple "copy RamDisk:Picasso96Install/Libs/#? LIBS: ALL") coming from P963.2.3:

https://www.youtube.com/watch?v=sF0fK5p6-WM

The strange thing is that on next reboots (even I quit and restart WinUAE!), "UAEgfx" driver crashes on boot with an "Illegal instruction" GURU

Rolling back to P96 3.2.3 solves the issue.

New iconlib athor said this, so yes, it seems a generic issue, not something broken because of some hacks in PPaint:

Quote

This issue also has happened (not anymore now after recent workaround in the new icon.library) with DOpus5 on chunky screens when WB is running in TrueColor. On a 32 color screen the palette was damaged right from the start when DOpus5 was loading the disk icons. - And AfA_OS also shows ColorIcons with random colored frames instead of frameless, but AfA has its own icon_lib.exe...

It happens only when using new icon.library by P.K., but switching to older rtg.library fixes it so it seems a problem in rtglib...

Probably other programs using SetRGB32() and ReleasePen() in a certain way are potentially affected (it's just a case that is triggered by pio_ico plugin and PPaint)...

In short it happens in this case:

new iconlib + new rtglib

But won't happen with:

old iconlib + new rtglib

or

new iconlib + old rtglib

Would be great if you can give it a look, because I'd really like being able to use new icon.library for (MUCH) better WB icon palette + latest rtg.library with all its improvements...

Hello,

I've experienced a minor glitch when using P96's rtg.library > 42.1106 (26-Dic-2021) (this was the last one without this issue)...

My WinUAE sys (Zorro III RTG + p96, 060 with 3.9 and mmulib by T. Richter etc.):

icon.library 46.4.563 Aminet - util/libs/IconLib_46.4.lha

Picasso96API.library 2.407 (27-Feb-2022)
©2021 iComp

emulation.library 41.493 (27-Feb-2022)
©2021 iComp

rtg.library 42.1226 (27-Feb-2022)
©1991-99 A.Kneer T.Abt, ©2017-2018 icomp

When loading Coloricons >32colors with PPaint (reproducible also with free version from Aminet) + pio_ico plugin Aminet - gfx/ppaint/pio_icon.lha right after loading the icon PPaint screen palette gets corrupt, as discussed on EAB forum icon.library 46.4 test versions - Page 196 - English Amiga Board (abime.net) :

(10) WinUAE 2022 04 07 23 50 56 01 - YouTube

Video explained:

1. launch PPaint
2. open 'Load brush' PP-requester
3. double click on the right: ICON format (will open pio_ico prefs), and then Cancel
4. at this point, from WB, drag'n'drop a program with coloricon >=32colors on PPaint app-icon, this will automatically point to the correct path into previously open PPaint 'Load brush' requester
5. switch back to PPaint and just load the program (it has an .info of course that will be automatically loaded)

You'll see the screen palette gets altered (PPaint UI turns blue!) in the video after loading, and to restore the correct palette I can simply switch screens back and forth from usual Intuition depth screen gadget in the upper-right.

The author of new icon.library commented:

Quote

This rtg.library palette issue seems to occur only when you have at least two different screens open, like WB in TrueColor and another 8-bit screen in chunky mode. It is triggered by SetRGB32() and ReleasePen() and it seems to happen when colors of a non-active screen should be changed (for the first time). My icon.library tries to do that with the delayed color mapping. There is no problem with my direct access to the private data structure of PalExtra as I expected. I can still allocate new free pens and increase the reference counters as usual, if I just disable the call to SetRGB32(), then everthing still works, except that I don't get the desired new colors, so a few pixels show wrong colors, but the screen palette and DOpus5 wallpapers won't get corrupted.

Just read this thread today: Setting up uaegfx / Picasso96 - English Amiga Board (abime.net)

and thought it could be a good idea adding a sort of check when launching Picasso96Mode and WinUAE is detected, warning user it is not required in this case...

Ok, just keep in mind that this means bare (old) OS3.9 + P96 3.x.x + akDTs will suffer those Multiview SCREEN bugs

Newer Multiview 47.x (OS3.2+) have solved compatibility.

OS3.2 has its own PNG and GIF native dts (and can't replicate the issue there as I just tested). OS3.1.4 from my basic install has no PNG and GIF included (as well as for the oldie OS3.9). In my first post I specified my main system is OS3.9-based... that's why I was using akGIF and akPNG dts from Aminet where I faced the issue with Multiview SCREEN in conjunction with P96 RTG (and couldn't reproduce it disabling 'uaegfx' monitor + P96 and Zorro 3 emulated gfx board).

You can replicate the issue trying to open with Multiview (and switch to its own fullscreen) these TIFF files: TIFF Files (sc.edu) using akTIFF from Aminet... on OS3.9.

P.S.: OS3.2 and its Multiview 47.x version works fine instead even with akTIFF dt, just tested! I think this will finally push me to definitely switch to 3.2 as my main (emulated) Amiga system and upgrade my rusty OS3.9

Quote from hexaae

Forgot to tell I use akPNG and akGIF dts...

EDIT: actually, changing datatypes to ZGIF (gif.datatype 39.18 (30-Mar-1996)) and Cloanto© PNG DataType 43.3 (16-Dic-1995) solves the issue with Multiview!

Just as a myself reminder in this thread Cloanto PNG dt has stack shortage issues. vPNG from Aminet is working fine and has no issues with Multiview + P96 RTG.

Ok but consider many users have this or similar DTs (not much choice from Aminet), so a wider compatibility would be appreciated (given the DT is not the only responsible for this issue at least and assuming something could be improved in P96 under this aspect... ).

Forgot to tell I use akPNG and akGIF dts...

EDIT: actually, changing datatypes to ZGIF (gif.datatype 39.18 (30-Mar-1996)) and Cloanto© PNG DataType 43.3 (16-Dic-1995) solves the issue with Multiview!

Tested with old picture.dt from P96 archive on Aminet:

picture.datatype 43.41 (20-Dic-1998)

and Multiview SCREEN/window switches fine. This picture.dt is unusable on modern systems though and have issues with clipoboard copy too (e.g. using sytem IconEditor's copy and paste clipboard), so it's not a valid workaround

I can reproduce the issue when I use OS3.9 installation + P96 3.2.2 with WinUAE (1920x1080 Zorro 3 gfx board emulation), and Multiview SCREEN <picname> to open these pics: https://1drv.ms/u/s!ApMUGr0cuN39goZj9zBuxX7gqAE5PA?e=7PLsUG

Can't see mouse and RMB to open menu won't work: the screen frame is freezed (I can still quit with the default Multiview key 'Q' though). Winuaeenforcer hits with wild read/writes can also occur.

datatypes.library 44.47 (25-Dic-1999)

picture.datatype 45.17 (19-Mar-2002)

Note: if I boot keeping RMB pressed to skip Picasso96/uaegfx monitor driver initialization thus forcing WB3.9 to boot in simple AGA mode I can't reproduce the issue of course and the pics have no issue when I switch WB window/Multiview own screen.

P.S.

If you can't reproduce it, try first to open pictures in a window with Multiview on Workbench (24/32bit) and then select menu option to move on its own screen.

Yep, reproducible with WinUAE even from my fresh file-disk installation of OS3.2, OS3.9, OS3.1 and no RTG enabled.

PPaint "Read Brush" from Clipboard seems broken in some way since at least 6.4.

It seems a PPaint issue actually... nothing to do with P96 or RTG in general

I've been able to reproduce it even with PPaint 6.4 or 7.1c free, fresh install no additional plugins. Try to load these pics through Multiview (given you have dts installed), and...

1 - Copy/Mark image from Multiview menus

2 - from PPaint try to import clip (Brush > Clipboard: Read brush)

this should generate (winuae)nforcer hits and mem corruption by PPaint task.

P.S.

Why picasso96API.library, and Picasso96/rtg.library + emulation.library have all capital letters (= PICASSO96API.LIBRARY....)?

PPaint 7.3c gets unstable doing some tasks like loading PPaint:Picture/#? files using PPaint:PPview by double-clicking pics icons...

Rolling back to P96 3.1.2 solves the issue...