AmigaOS 3.2 and beyond

[Jope]

Originally Posted by mateusz_s

Hmm interesting.. but how to use L:CrossDOSFileSystem instead of fat95?
just delete fat95 and let L:CrossDOSFileSystem do the job autmatic or do I have to configure something? Not sure how to use it..

If you want to try, you can open the cf0 dosdriver in a text editor and just change l:fat95 to l:crossdosfilesystem. It should work with the same dostype, but there is the caveat, that it will load crossdosfilesystem a second time into memory if you later mount PC0: for example.

If you really want to tune your mem use in a low memory system, you would adjust the name of the dosdriver to end in the letter C (such as renaming it + its icon to CFC and CFC.info) and use the dostype 0x4d534800.

More information on this is available in the FAQ. Hit help when you're on the workbench screen, select 10 - FAQ and scroll to section 2.13.

[mateusz_s]

@Jope
Thanks I will try it.

ps.
Why the name change from CF0 to CFC is so important?
Why using dostype 0x4d53480 instead of the one that is written in CF0 file?

[Jope]

Originally Posted by mateusz_s

Why the name change from CF0 to CFC is so important?
Why using dostype 0x4d53480 instead of the one that is written in CF0 file?

These two changes are linked together. If you change the dostype, you must change the name of the dosdriver too.

The reason is in the FAQ I linked to, I recommend reading it, but shortly: if you decide to use the new dostype, then the filesystem driver looks at the last letter of the device name to determine which partition to mount. FAT95 uses the dostype itself to determine which partition to mount or if it is supposed to use autodetection.

[mateusz_s]

Originally Posted by Jope

These two changes are linked together. If you change the dostype, you must change the name of the dosdriver too.

The reason is in the FAQ I linked to, I recommend reading it, but shortly: if you decide to use the new dostype, then the filesystem driver looks at the last letter of the device name to determine which partition to mount. FAT95 uses the dostype itself to determine which partition to mount or if it is supposed to use autodetection.

OK thanks again, I will look also at the FAQ..

[mateusz_s]

Hello,
I found something weird about the icon.library..

I switch main 8 icons from sys: to this nothing fancy Ken Icons:
http://www.amiga-look.org/artwork/kens-icons-v23

and after opening sys: drawer icons started to appear very slooowly. That 8 icon appear time took about 4-5 seconds
on RTG winuae 060

So I tried to switch the icon.library with this:
http://aminet.net/package/util/libs/IconLib_46.4

.... and the icon loading time is now superfast, the window appear already with icons, you cant even see when they appear.

another thing is, that now I started seeing AmigaOS4 and (i guess) dual PNG icons with transparency behind them - with no slow performance issue:
http://www.amiga-look.org/artwork/packpaticonv2


So I wanted to ask - is it a matter of future optimalization od AmigaOS 3.2 icon.library (and adding additional icons support) or some compatibility issues with other Amigas or legal issues?

Thanks!

[Minuous]

If it is really taking 4 seconds to show 8 icons there must be some problem with your WinUAE configuration.

[mateusz_s]

Originally Posted by Minuous

If it is really taking 4 seconds to show 8 icons there must be some problem with your WinUAE configuration.

You could check yourself if possible, you don't have to switch the icons,
just open that folder from that lha package:
...Icons\Kens_Icons_v2.3\Kens_Icons\Workbench

http://www.amiga-look.org/artwork/kens-icons-v23

It just a glow icon package, noting fancy in my opinion..
When using native 3.2 icon.library they are appear very slow..

[Minuous]

Each of those icons takes about 1/10 of a second here, and my host machine is not especially fast (1.5GHz).

[PeterK]

He is probably running WinUAE without the JIT and "Fastest Possible" CPU. Maybe he wants to enable the MMU, and then you can't use the JIT. I've tried that just for fun, and indeed without the JIT KensIcons v2 (256 colors) are coming up very slow on RTG screens using the v45 OS libs, about half a second for every icon, which is caused by the color mapping (more than 100000 color compares for every icon). My library uses direct drawing for the 24 bit RGB colors, and that only for the first image, no slow compares at all! (I was a bit shocked, the OpenWin.rexx benchmark said something about 85 times faster using the HDD (SSD), not the Ram Disk, for this configuration).

[mateusz_s]

Hi,
I think I have found a BUG. When we are inside the drawer that doesn't have an icon
and we are doing cleanup and then SNAPSHOT the System crashes. Both WinUAE and Real Amiga.

[Steady]

@mateus_z

I just tried to replicate this but I get no crash. Can you please provide a step-by-step action that I can use to verify?

[mateusz_s]

Originally Posted by Steady

@mateus_z

I just tried to replicate this but I get no crash. Can you please provide a step-by-step action that I can use to verify?

Sorry, my bad.
It seems that @PeterK icon.library replacement is the cause:
http://aminet.net/package/util/libs/IconLib_46.4

To reproduce:
- go to dh0:
- show all files
- open a drawer without .info like s, c, libs etc.
- click autoarraneicons or just clean up and make snapshot

[daxb]

Wouldn't it be nice if the OS open a requester in this case asking for should I create an icon for you to be able to snapshot or cancel?

[indigolemon]

Originally Posted by mateusz_s

Sorry, my bad.
It seems that @PeterK icon.library replacement is the cause:
http://aminet.net/package/util/libs/IconLib_46.4

To reproduce:
- go to dh0:
- show all files
- open a drawer without .info like s, c, libs etc.
- click autoarraneicons or just clean up and make snapshot

I can't reproduce this here - 3.2 with PeterK's library.

[mateusz_s]

Originally Posted by indigolemon

I can't reproduce this here - 3.2 with PeterK's library.

hmm.. Are you sure you have it installed. Try type:
version libs:icon.library

Or maybe Your S,C, LIBS drawer has their icons..

Friend of mine also check it on his Amiga - and it crashed.

[PeterK]

Originally Posted by mateusz_s

Or maybe Your S, C, LIBS drawer has their icons..

Friend of mine also check it on his Amiga - and it crashed.

Ok, confirmed, sometimes it really crashes, which needs some investigations. Sorry, I didn't watch this thread for some days ... no, no, I was just sleeping too long ...

[AMIGASYSTEM]

Originally Posted by mateusz_s

Hi,
I think I have found a BUG. When we are inside the drawer that doesn't have an icon
and we are doing cleanup and then SNAPSHOT the System crashes. Both WinUAE and Real Amiga.

This may also depend on some incompatibility due to the datatypes not recognizing some files, try deleting the files one by one until you find the culprit.

[AMIGASYSTEM]

Originally Posted by Jope

These two changes are linked together. If you change the dostype, you must change the name of the dosdriver too.

The name of the DosDriver in my opinion doesn't influence on its functionality, in my systems I use Driver names invented by me and I don't have any problem in the various mounting volumes.


Example CD0 you can rename CDX, CDY or CDZ and it will always work the same way.

[PeterK]

I think I have found a BUG. When we are inside the drawer that doesn't have an icon and we are doing cleanup and then SNAPSHOT the System crashes. Both WinUAE and Real Amiga.

I'm not 100 % sure, but after some debugging it seems to be a bug in workbench.library v47 of OS 3.2 although it works with the OS 3.2 icon.library.

Workbench.library calls FreeDiskObject() in icon.library with an invalid address, and my icon.library just aborts this function call then, because it can't find a DiskObject structure (magic selfpointer).

This does not happen under OS 3.9 or 3.1.4 or for the case that I replace the OS 3.2 workbench.library with v50.107 from OS 4.0.

Of course, it could still be possible that a FreeDiskObject() call inside of my icon.library is executed in the context of the Workbench task, but atm I can't see another reference to icon.library code in the Enforcer hits. Maybe the devs can tell me what was executed last in workbench.library before that FreeDiskObject() was called by WB.

[Predseda]

Originally Posted by mateusz_s

Sorry, my bad.
It seems that @PeterK icon.library replacement is the cause:
http://aminet.net/package/util/libs/IconLib_46.4

To reproduce:
- go to dh0:
- show all files
- open a drawer without .info like s, c, libs etc.
- click autoarraneicons or just clean up and make snapshot

With standard WB installation it doesnt crash for me. No replaced icon.library.