icon.library 46.4 test versions

[PeterK]

No, I guess it's probably just a racing condition (IPrefs, LoadWB, etc). You could also try to insert a Wait before LoadWB or use "LoadWB DELAY".

Your WinUAE config just works fine here with OS 3.9 BB2. Unfortunately, some years ago, I've destroyed my OS 3.9 iso image and my Mini-PC has no CDROM anymore. I just have a zip file with OS 3.9 BB2 ready installed. It's hard to downgrade that to plain OS 3.9. I also have AmigaForever7, but that's another story. You can't compare it with OS 3.9.

[AMIGASYSTEM]

Tried to update OS3.9 with BB1, BB2 and BB3 the problem remains, with BB4 problem solved JIT + Z3 Fast Ram they work perfectly

[PeterK]

Which WinUAE version? And for 32 bit or 64 bit?

[AMIGASYSTEM]

Use WinUAE 32Bit, found a Z3 Fast Ram problem even with BB4, see video:

EDIT:

If you disable JIT, the problem still solves and Z3 Fast Ram no longer creates a problem !

[PeterK]

Very strange behaviour! Did you test with older versions 476-480?
Your config file says: WinUAE 3.6.2. Did you try older WinUAE versions? I'm using 3.6.1 64 bit.
Which filesystem is that? I use Windows drawers directly, no HDF.

Enable "Create winuaelog.txt log" and "Log illegal memory access" under Misc settings in WinUAE and post both log files: "winuaelog.txt" and "winuaebootlog.txt".

[AMIGASYSTEM]

Originally Posted by PeterK

At the moment I'm testing some older icon.library

v46.476= "No problem GUI Request", but problems graphics icons,see screenshot, without Z3 Fast Ram all perfect

v46.464= equal 476

v46.450= equal 476

[PeterK]

What happens with the original OS 3.9 icon.library?

What is your Windows version? And which build number?

Could also be a hardware (memory) problem, who knows?

On my PC it even works with WinUAE 3.6.2 beta 0 and your config with Z3 ram. No issues.

[AMIGASYSTEM]

I'm sorry Peter, in the test video i had not used the v46.481, but one old icon.library v.46.228. Then BB4 he had not solved this problem.

With Icon.library original OS 3.9 no problem JIT + Z3 Fast Ram, all perfect

[PeterK]

Could you send me your HDF as a compressed file per email, please. Thank you.

[AMIGASYSTEM]

Yes !
No problem with your IconDemo.ADF JIT + Z3 Fast Ram, all perfect

[PeterK]

Your HDF works perfectly with your configuration and Z3 ram.

Check your PCs memory or switch WinUAE to DirectDraw.

[AMIGASYSTEM]

All very strange, with DirectDraw nothing changes, AFA OS, Amikit and other OS Amiga no problem. I'm a PC expert, I managed hundreds of them in my company where I worked. it's very fast everything works perfectly, tomorrow I'll try with my other PCs, thanks anyway. Win7 it's very fast everything works perfectly, tomorrow I'll try with my other PCs, thanks anyway.

[AMIGASYSTEM]

Originally Posted by PeterK

Check your PCs memory or switch WinUAE to DirectDraw.

Found the cause, it was not the Ram of my PC, even on my other PC the same problem happened, the cause was the config file winUAE, I recreated the configuration from scratch and the problem disappeared


The file config strangely did not give problems on Win7 64Bit and my other PC with Win7 at 32Bit, i found the problem only on two PCs at 32Bit , attach config that created problems.

[PeterK]

The main difference between your old an new WinUAE configuration is that you have the UAE RTG Z3 graphics card enabled now. There was no gfx card on before. But both configs are using native Amiga screenmodes.

And the new config is still causing these errors on some of your 32 bit systems? Would be more intersting to know the config which is working fine on all PCs in order to compare it.

Your problem still makes me a little insecure whether there could be a hidden memory trashing caused by my library or not. But I need to be able to reproduce this issue before I can start searching for the reason. Or I need to know exactly the version of my lib where the problem occures for the first time.

Enable "Create winuaelog.txt log" and "Log illegal memory access" under Misc settings in WinUAE and post both log files: "winuaelog.txt" and "winuaebootlog.txt".

[AMIGASYSTEM]

Yes, the graphics card was an option that was not influential, in the first config I had deleted it specifically to not create doubts.

If I create a new configuration everything works fine, i think the problem is caused by a configuration "old" created with an old version of WinUAE.

In my opinion, as WinUAE updates the configurations from time to time we have to recreate them

Which log should I create the one with problems or the one without problems?

[PeterK]

Most important would be the log files when the problems occur.
Best case, if you could create two pairs of log files and the configs, to be able to compare the good settings and logs with the bad ones. But the logs are overwritten on every new start of WinUAE. Don't change the settings while WinUAE is running, start it twice with different settings directly from Windows (no internal restart). Save the log files each time after shutting down WinUAE.

[AMIGASYSTEM]

Originally Posted by PeterK

Don't change the settings while WinUAE is running, start it twice with different settings directly from Windows (no internal restart). Save the log files each time after shutting down WinUAE.

You know how it works, just clean up everything start testing

Tested yours Icon.library even with my systems AFA_OS, but with AFA OS "disabled" (key sx Mouse) and no problems found even if quality is lost

[PeterK]

Thank you for the flowers, AMIGASYSTEM

Yes, some quality gets lost, but a lot of memory can be saved. Was that really the point now, the result of your investigations into the JIT Z3 RAM problem?

[AMIGASYSTEM]

Yes, some quality gets lost, but a lot of memory can be saved.

It was just a test, with WinUAE, RAM is not a problem


I attach the two config

[kolla]

Time warp

Originally Posted by PeterK

Update to icon.library 46.4.465:

1.) For drawer names with an appended "/" the slash will be removed before the ".info" extension for the icon names is added, because nobody wants to access "drawer/.info" which would be mapped to "ENVARC:Sys/def_drawer.info". This sometimes has happened with ContextMenu, for example.

Can you elaborate a little on this?

I use ToolManager, and it is a constant irritation that if I select icons of type drawer from a ToolManager menu, it replaces the "[]" in the associated command with the selected drawers and their trailing slashes, making it close to impossible to make menu entries with commands to manipulate the corresponding .info file. As you point out, the closest you come is drawer/.info. I always thought this was a "misfeature" of ToolManager, but then I saw the above some time ago, and thought perhaps my woes were gone, but they aren't so...