AmigaOS 3.2 released!

[mfilos]

Originally Posted by boemann

I'm starting to question if this has anything to do with your links at all. To me it sounds more like iprefs not running

Can you please test a setup where you don't have links but just actual files and then try to click "use"

When you do click save, can you then see the pref files you changed in ENV:

I never had a problem with actual files.
But I did the test once more now and it works just fine.
What I did is replace the ScreenMode.prefs from a symbolic link to an actual file then disabled my script in Startup-Sequence.
Then checked the timestamp on the ENV:Sys/ScreenMode.prefs and when I click USE and intuition refreshed just fine the timestamp changed in the file.

So everything works as it should in a normal file.

[boemann]

Originally Posted by mfilos

I never had a problem with actual files.
But I did the test once more now and it works just fine.
What I did is replace the ScreenMode.prefs from a symbolic link to an actual file then disabled my script in Startup-Sequence.
Then checked the timestamp on the ENV:Sys/ScreenMode.prefs and when I click USE and intuition refreshed just fine the timestamp changed in the file.

So everything works as it should in a normal file.

Ok thanks, that at least takes cuts down what we should now look at. What is the filesystem on your disk where ENVARC: is?

[mfilos]

Originally Posted by boemann

Ok thanks, that at least takes cuts down what we should now look at. What is the filesystem on your disk where ENVARC: is?

FastFileSystem 47.4 (with Long Name support - DOS7).

I also disabled every patch I had in my S-S (which are not many as I am very picky of what I put in this new installation of 3.2.1 and after checking with the FAQ which are already embedded in the OS)
... and still no change.

[boemann]

I don't have that many more questions right now, but several AmigaOS developers are looking at it right now. We will likely get back to you soon.

[mfilos]

Originally Posted by Ras Voja

Can it works with PFS3 out of box, installled in SLB?

I'm pretty sure that the problem is not the filesystem but the devs will check and report back.
Apart from that my choice of using FFS for the first time after so many years in PFS3 was due to new changes in 3.2.1 and the fact that I wanna try it as well.

[idrougge]

Originally Posted by saimo

* shell option to have TAB open a file requester like KingCON does.

So very much this, and not an ASL requester, unless necessary.

The Amiga is a GUI/CLI system — there should be no artificial boundaries here.

[Olaf Barthel]

Originally Posted by Thomas Richter

The "link to external devices" aka "lazy copy" the RAM disk supports works well if the external object is a hardlink. It does not work for soft links. Thus, make sure that the above external link is a hard link (which is resolved by the file system) and not a soft link (which the RAM disk cannot resolve).

Um, long story short: this was caused by a side effect of the respective preferences files being hard links.

The procedure by which ram-handler retrieves the respective file attributes, and the file names, will use the names as provided by the source file system.

For the FFS this means that the file name will be that of the "original file" which the hard link references. For example, for the file "ENV:Sys/ScreenMode.prefs", ram-handler may use the name "ENV:Sys/ScreenMode.prefs.V4SA" instead.

Because the name of that preferences file is not what the file notification request used by IPrefs expects, the existing "ENV:Sys/ScreenMode.prefs" will remain unchanged.

The bug has been fixed and a new ram-handler will become available in due time

[mfilos]

Originally Posted by Olaf Barthel

Um, long story short: this was caused by a side effect of the respective preferences files being hard links.

The procedure by which ram-handler retrieves the respective file attributes, and the file names, will use the names as provided by the source file system.

For the FFS this means that the file name will be that of the "original file" which the hard link references. For example, for the file "ENV:Sys/ScreenMode.prefs", ram-handler may use the name "ENV:Sys/ScreenMode.prefs.V4SA" instead.

Because the name of that preferences file is not what the file notification request used by IPrefs expects, the existing "ENV:Sys/ScreenMode.prefs" will remain unchanged.

The bug has been fixed and a new ram-handler will become available in due time

That is great news Olaf!!! Thanks a lot for that prompt response!
So I guess with the new Ram-Handler I'd use the same hard-link but the IPrefs will correctly update the real file instead of the ENV version?

Can't wait

[klx300r]

I think this question has come up before on this thread but I can't seem to find it now so asking again...is there a need (is it beneficial) for us Blizzard 060 owners to use BlizKick with OS3.2

oh & also same question with HSMathLibs

[tomcat666]

Suggestion: Make PFS3 the default file system for OS 3.3 And get rid of the validation problems once and for all.

[mfilos]

Originally Posted by klx300r

I think this question has come up before on this thread but I can't seem to find it now so asking again...is there a need (is it beneficial) for us Blizzard 060 owners to use BlizKick with OS3.2

oh & also same question with HSMathLibs

Well if you use an actual 3.2.1 kickstart I don't find a reason why using BlizKick would benefit you (unless you wanna put some BlizKick modules).
Without knowing exactly what the rework on Mathlibs are, I believe that HSMathLibs would be beneficial (as they have specific versions for 68881/82, 68040, 68060 FPUs). Devs are more appropriate to respond here.

Originally Posted by Ras Voja

Same, on paid MathLibs,
and again on PFS3 usage in SLB and since day 1 on 3.21. with 3.2.1 ROM

Suggestion: use 1MB ROM in 3.3 and beyond, please

What's the problem with 512KB ROM and modules like icon.library and workbench.library on LIBS:
If you want 1MB ROM, you can make it yourself rather easily with whatever modules you want from 3.2.1 etc.

Also if you prepared your harddrive/CF with PFS3, it's on the RDB and you don't need anything else put anywhere.

[Thomas Richter]

Originally Posted by mfilos

Without knowing exactly what the rework on Mathlibs are, I believe that HSMathLibs would be beneficial (as they have specific versions for 68881/82, 68040, 68060 FPUs). Devs are more appropriate to respond here.

Cough. The standard math libraries of the system *also* contain specific versions for the hardware FPUs. Just integrated into one binary. These binaries provide no advantage on FPU-equpped binaries.

[boemann]

Originally Posted by klx300r

I think this question has come up before on this thread but I can't seem to find it now so asking again...is there a need (is it beneficial) for us Blizzard 060 owners to use BlizKick with OS3.2

oh & also same question with HSMathLibs

It is absolutely beneficial to relocate your ROM to FastRAM which is what BlizKick does. Basically any OS code located in ROM will execute much faster. Obviously you need to have the FastRAM to spare, but that is about the only downside

As for HSMathLibs they likely speed things up, although you run the risk of incompatibility. We have recently found bugs in the official libraries that have existed since Commodore days but only one machines. Now this could be seen as a reason to not use the official ones but it is also a sign that getting this stuff 100% right is not trivial. Personally I would stay with the official ones. Even with bugs it is the same bugs that everyone else sees, and thus much higher chance that the developers of various software have worked around it.

[boemann]

Originally Posted by Thomas Richter

Cough. The standard math libraries of the system *also* contain specific versions for the hardware FPUs. Just integrated into one binary. These binaries provide no advantage on FPU-equpped binaries.

This !

The speed up you will see from these things are not groundbreaking

[Michael]

Originally Posted by Ras Voja

Please include latest MUI5 in next OS 3.3, even as extras install, like with OS 3.5. AHI and few essentails too. KingCON: and ASL Libs too, Magic Menu, UHC Tools.

This is not so simple, and as for MUI 5, we need a petition to adapt it to the classic and bring back some functionably that was cut out in favour of fast rtg system and thus make real hardware a pain to use. Sadly, currently 3.8 is the best choice for 68K.

[Thomas Richter]

Originally Posted by Ras Voja

There is no prob, more OS in ROM, the marrier. Amiga Classics supports 1MB long time.

No, they don't. A2000, A500 and A600 cannot, and even then, the lower ROM is rather reserved for the CD32 modules. Even worse, some third party hardware makes use of this extended ROM area.

Originally Posted by Ras Voja

If you ask me, whole OS should be in ROM or better resident fast RAM since we have 128 MB plus on accels.

You have that today, already. LoadModule loads ROM modules in resident fast RAM, such that it persists a reset. It can be even protected from getting overwritten through MuProtectModules. So everything you want is already here.

[Thomas Richter]

Originally Posted by tomcat666

Suggestion: Make PFS3 the default file system for OS 3.3 And get rid of the validation problems once and for all.

This is not such a great idea. Note that you still need the FFS in ROM to boot from floppies, so you cannot get rid of it. ROM space is limited, and even some third party hardware can only boot from FFS due to incomplete support of the RDB. Besides, you can perfectly boot from other file systems if you want to.

[Thomas Richter]

Originally Posted by Ras Voja

Seems to me to be "math libs as it should be"

No, as they should not. They do not scale to various CPU models. The system math libraries work on any CPU, no matter whether 020, 000, 060, with or without FPU. These libraries do not. This is just an incompatibility nightmare for no performance improvements whatsoever. Note that the native math libraries also only move arguments to the FPU and perform the computation there - if a FPU is present. So there is nothing to gain.

[Thomas Richter]

Originally Posted by Ras Voja

What MUI5 lacks that MUI 3.8 has, how to register MUI 3.8 and how to make MUI5 m68k port legal?

The Os already has a GUI system. Thank you.

Originally Posted by Ras Voja

oh, Its easy to dump ROM to Fast RAM. I am talking about whole OS from RAD: on 128MB systems. How much RAM would it eat?

Why? Again, Kickstart modules, or actually anything ROM-able you can load with LoadModule, reset-resident. The rest, why do you care?

Originally Posted by Ras Voja

Use 1MB ROM or far more, I am not saying to leave out FFS, include it. I am saying support PFS AIO from start, like MOS does. Who uses FFS in 2023? Only Hyperion.

No, surely not. And again, there is no ROM space. If you want to use it, there is no problem putting it int o the RDB.

Originally Posted by Ras Voja

There are builds for each CPU

Which is a bad construction. Put the harddisk into a different system, and it fails. The system math libraries *also* have code for each CPU/FPU, but in one binary. Again, there is nothing to gain.


The Os is constructed in a scalable way. You can take a disk installation you made on an 68060 and it works perfectly fine on a 68000 or 68030. It's really a bad habbit to have separate binaries for each model as you cannot upgrade or downgrade your system without the whole construction failing.

Originally Posted by Ras Voja

The "HSMathLibs" are completely written in assembler to achieve the maximum acceleration.

And? So are the Os libraries.

Originally Posted by Ras Voja

So you advise me not to get it, even all reviews etc. are positive to sys libs? OK, saved me few euros, thanks.

Don't waste your money on this stuff.

[Michael]

Originally Posted by Ras Voja

What MUI5 lacks that MUI 3.8 has, how to register MUI 3.8 and how to make MUI5 m68k port legal?

OS has it's own gui systems, so not a problem to install a 3rd party engine afterwards, it's one of the most popular ones too.


MUI 5 removed some settings, removed hardware scrolling support, enables very cpu heavy colour settings requester with no option to fallback to classic elegant mode, always on the fly changes, again cpu intensive for lower powered machines and why is there a test button that used to do it's job?


This is my list of issues that need addressing, then it will be acceptable.
Is not it public now ?