AmigaOS 3.1.4! [beta]

[Daedalus]

It's very easy to dedicate a separate partition to 3.9 and 3.1, switching between them if needed. A lot of the impact comes from four areas:

First, loading and installing the replacement ROM image/ROM modules and the associated double boot which greatly slows the boot process. There's not a lot that can be done about this, but chances are if you're running a patched 3.1 setup, you probably have similar patches and reboots in your startup slowing it down anyway.

Second, lots of extra things started in the background on bootup, such as ARexx, a few standard commodities, BenchTrash, AmiDock, AsyncWB etc. I always get rid of BenchTrash straight away, most of the other things can be done away with too (some people don't like AmiDock for example), but I hate using a Workbench without AsyncWB, and ARexx is almost essential for so many things. Still, they can all easily be disabled to reduce the loading times if desired.

Third, 3.9 has more eye-candy. By default the screenmode has lots of colours (maybe 16 or 32? I can't remember...) compared to 4 colours as standard under 3.1. This will make everything feel slower - opening windows, dragging things around, etc., especially on ECS machines. Obviously graphics card users don't need to worry about this. Also, there's a colourful backdrop set by default that can take several seconds (or even minutes if you're on an '020) to decode and scale to the screen, using all the CPU time in the process and making things crawl until it's finished. Switching Workbench to 4 colours will give a similar redraw speed to 3.1, thought the icons will be ugly as they're intended for more colours. Removing the backdrop will also stop all the CPU time from being used after startup until the image is displayed.

Finally, the 3.9 programs all use ReAction for their GUI, which is a little slower than GadTools. Not much getting away from that really, but at least you get some extra functionality, and with a faster CPU it isn't really noticeable. And it doesn't cause anything else to be slower.

In summary, two areas where a big impact can be made are to reduce the colours and get rid of the backdrop, and remove the extra startup items. That'll give you an experience much closer to 3.1 but still have many of the 3.9 benefits in place.

[Olaf Barthel]

Originally Posted by nogginthenog

A nice alternative is how Olaf's RoadShow config files work. They appear to be parsed with ReadArgs() or similar.

e.g.

# Each line in this file is read and parsed according to the
# following template:
#
# NAME/A,PASSWORD/K,UID/A/N,GID/A/N,GECOS,DIR,SHELL

If I remember correctly, AmiTCP did this first and you are well-advised to always steal from the best

One shortcoming to this approach is in that the storage and retrieval of structured data is not one of its strengths. So, given a choice, JSON might do the job with a minimum of fuss if you need structured data to be handled well.

Just the other day I looked into how you would do just that. You have a lot of well-designed 'C' JSON implementations to choose from, as it turned out. The only restriction which I could see involved how much memory you would need to throw at the processing stage during retrieval. Some of the 'C' solutions are specifically made to work well on embedded systems, which helps, but if you are going to store and retrieve complex data structures, the amount of memory you will burn quickly increases almost geometrically

[PeterK]

Originally Posted by Daedalus

There's not a lot that can be done about this, but chances are if you're running a patched 3.1 setup, you probably have similar patches and reboots in your startup slowing it down anyway.

Did you ever try RemLib written by Thomas Rapp to remove old libraries from the resident list. It won't need a reboot because the new libraries are simply loaded from Libs: like any other disk-based library. This may also work with other resources, but I've never tested it yet. RemLib is included in my Aminet IconLib package or on the IconDemoADF images. It's also somewhere on A1k.org, but you would need a login to download it there.

[gulliver]

@PeterK
Has Olaf Barthel contacted you regarding your icon.library implementation?

It is much better in all aspects than any former CBM, Escom, Haage&Partner and even Hyperion´s work.

It is one of those enhancements any amiga user would undoubtly agree is worth its weight in gold for any OS update.

[Michael]

It is possible to avoid a reboot and have most of the needed 3.9+ stuff running from start.
I had my system setup like that for years and only recently (a few years ago =) ) decided to have a reboot with all rom patches enabled. My fully bloated system loads in around 20 seconds from reboot (060/CGX/NET/DebugTools) and if I need a quick boot I can hold right mouse button that will interrupt s-s and load a primitive startup in just 2 seconds with all the major stuff setup for work and trouble shooting. Somewhat better then just a CLI prompt.

[PeterK]

Originally Posted by gulliver

@PeterK
Has Olaf Barthel contacted you regarding your icon.library implementation?

No, Olaf Barthel has just posted here on this page and I can't see why he should do that. There is probably not enough space for a new workbench.library and icon.library in a 512 kB ROM.

Update:
It's a replacement ROM for OS 3.1 and not for OS 3.9. And for low end machines it could even be a disadvantage to use my icon.library, because it always stores all icons in the extended OS 3.5 icon format in memory and has to make an additional copy of the standard DiskObject structure for the WB 3.1. That requires more memory and time than just handling the planar images only as it is done by the icon.library v40.

[gulliver]

@PeterK
I really dont care if it is either inside or outside rom. I just care that we get the best option there is. Loading it from disk is an option, or even having the old 3.1 icon.library in rom modified with a loader that first searches for a disk based one, and if not found, goes back loading the old 3.1 from rom. There are many solutions for this.

I just see that your icon.library is the the most feature rich and faster implementation out there. I would just hate to get a slower, buggy and underperforming one for the update (like we did with 3.9).

Update:
Then, they could just build the rom with the old v40 icon.library with a clever modified loader which checks first if enough memory/cpu power is available and there is a disk based version, it loads that one (your version), and if not it just loads the v40 one (from rom). This will still save precious rom space, keep backwards compatibility and enable the use of your version if the system is ready for it. And even if the user decides to, he can simply delete your version from libs: and the system will default to v40 which sits in rom.

There is always a workaround

[PeterK]

Ok, but the implementation of such a smart library loader would be the job of Olsen and ThoR, if they think it could make sense and is possible, not my decision.

[gulliver]

Originally Posted by PeterK

Ok, but the implementation of such a smart library loader would be the job of Olsen and ThoR, if they think it could make sense and is possible, not my decision.

Yes, indeed.

BTW, the smart library loader could also solve the workbench.library rom issue in a similar way.

[utri007]

Why to keep rom size 512kb? 1024kb roms has proven to work with many machines without a problem.

Havin up to date scsi.device inside of rom helps a lot, same with ffs. Leaving workbench.library out of rom has disadvantages.

[Michael]

It possible to have a slightly simplified wb in rom, to save space, and then load the big abd more feature enabled one from disk if available. WB in rom is basically required for floppy boots.

In fact it's ideal to have a possibility to load any component from disk if it is available and then defer to rom based version, this would also allow easier future updates.

So that makes scsi (ide) device the only really essential component to be updated, unless it can be made intelligent and load a new version from rdb like filesystems do to be future proof too. Then again ide is not going any further then 500GB drives? Or 2TB via adaptors?

[Olaf Barthel]

Originally Posted by PeterK

No, Olaf Barthel has just posted here on this page and I can't see why he should do that. There is probably not enough space for a new workbench.library and icon.library in a 512 kB ROM.

You are correct, this boils down to a space issue first. Also, it's unclear (to me) if the icon.library code works well in ROM, how the licensing issues look like, and how the code would be maintained in the future.

Looking two steps ahead: the big unsolved problem is not with icon.library by itself, but with how workbench.library performs the directory scanning and window update. This part of the game really, really stinks, has always stunk since Workbench became part of Kickstart.

Workbench is at its heart one lumbering single-threaded application which can scan one single directory at a time and can't do anything else except refresh the window and allow you to close it (even redrawing the window contents when necessary is painful). The whole lump of scanning directories, showing the contents as text or icons, putting icons and their corresponding files and directories together, is as tightly integrated as one might except and very hard to change. But change it must, after some 30 years.

Question is how to do that with icon.library if it has to be made to fit. Right now, warts and everything, the AmigaOS 3.9 icon.library seems more malleable in that respect. I'm frankly scared of changing a 10,000+ line assembly language implementation (that's about the size of exec.library with the autodocs removed), more scared of testing the changes.

[Olaf Barthel]

Originally Posted by Michael

It possible to have a slightly simplified wb in rom, to save space, and then load the big abd more feature enabled one from disk if available.

The workbench.library as it was in Kickstart 3.1 is, sadly, as simple as one could make it, and possibly as complex as Mike Sinz dared to make it, at the time. Furthermore, there is no clean way to shut down Workbench entirely, which would be the prerequisite for replacing it at run time, after the system has booted.

The more I look at it, moving workbench.library out of the ROM and onto disk seems to be the best of the worst alternatives.

[PeterK]

Originally Posted by Olaf Barthel

Also, it's unclear (to me) if the icon.library code works well in ROM, how the licensing issues look like, and how the code would be maintained in the future.

My icon.library can be loaded from ROM and licensing is not required at all, because there are no restrictions for distribution. But as I already said, I won't put my icon.library into the ROM, because low end Amigas with planar icons only may suffer from the larger overhead that the internal OS 3.5 icon structure and the additional copying of the standard DiskObject data causes. Yes, maintenance might become a problem as soon as I will quit.

Workbench is at its heart one lumbering single-threaded application which can scan one single directory at a time and can't do anything else except refresh the window and allow you to close it (even redrawing the window contents when necessary is painful). The whole lump of scanning directories, showing the contents as text or icons, putting icons and their corresponding files and directories together, is as tightly integrated as one might except and very hard to change. But change it must, after some 30 years.

Something that many people have complained about is that WB always loads all the icons even in text listing mode. And the workbench.library should also be loadable from a Kickstart 3.0.

What do you think about a smart library loader as suggested by gulliver?

[daxb]

If the target is a system with HD to boot from then it would be best to remove as much as possible unnecessary libraries out of ROM and load from HD. I think it is worth the cut. The cases where wb/icon are needed in ROM are nowadays rather seldom.

[Olaf Barthel]

Originally Posted by PeterK

My icon.library can be loaded from ROM and licensing is not required at all, because there are no restrictions for distribution. But as I already said, I won't put my icon.library into the ROM, because low end Amigas with planar icons only may suffer from the larger overhead that the internal OS 3.5 icon structure and the additional copying of the standard DiskObject data causes. Yes, maintenance might become a problem as soon as I will quit.

I am not so much concerned about you quitting the project (well, there should be concern in this case), but rather what will happen if we should make changes to the workbench.library and/or icon.library APIs which would require subsequent changes to your icon.library implementation. One future goal would be to break up the tightly integrated workbench.library directory scanning/icon retrieval/window update code, and in the course of slaying that dragon, some eggs will likely have to be broken.

Something that many people have complained about is that WB always loads all the icons even in text listing mode.

This is how it works for Workbench, I'm afraid. Unless you tell it to show all files (actually, it shows all directory entries in a drawer, not just all the files), Workbench does the same job regardless of the view mode in effect. Note that it does not rescan the directory if you switch between text and icon mode, which it would have to if the scanning procedure were any different. The text display mode was never intended to be an optimization of sorts, it's just a different way of showing what Workbench found in a drawer.

What do you think about a smart library loader as suggested by gulliver?

I don't see it happening any time soon, because the overall architecture of ramlib+exec favours the "fast path", i.e. reopening a library which is already in RAM or trying to find it on the resident list with InitResident() making it usable. The "slow path" would have to reverse that by prioritizing disk-loaded libraries. This is already rather tricky to begin with, and it only becomes more complex if you attempted to patch OpenLibrary/OpenLibraryTags/OpenDevice at run time to add a clever diversion.

For example, how do you decide to try the disk first if a library is already ready and waiting in ROM or RAM? I can only think of a "whitelist" or sorts which tells ramlib which libraries are preferably loaded from disk, otherwise things will get messy when, for example, deciding whether or not to load dos.library from disk How do you maintain that whitelist?

Methinks that operating system components which require dos.library to work finding a new home on disk rather than in ROM solve these problems much more elegantly than a complicated solution which has not been designed or tested yet. Hence, if your system setup is best served with a solution which keeps icon.library and workbench.library in ROM, then you might have to consider if an operating system which cannot deliver that, but offers other desirable features instead, might just not be good enough for your purposes but still be valid for others.

We cannot always satisfy all the constraints imposed on what goes into the ROM. Something has to give.

[gulliver]

Originally Posted by Olaf Barthel

For example, how do you decide to try the disk first if a library is already ready and waiting in ROM or RAM? I can only think of a "whitelist" or sorts which tells ramlib which libraries are preferably loaded from disk, otherwise things will get messy when, for example, deciding whether or not to load dos.library from disk How do you maintain that whitelist?

It is simple, just set the non essential libraries to boot that take much of the precious rom space, to be loaded from disk as default behaviour and if not, fall back to loading them from rom (you can put there the old v40 ones).

No whitelist, just a simple one time design choice from both you and ThoR, it doesnt need to be much more complex than that.

Candidates are as both you and ThoR have already mentioned in some posts:

workbench.library
icon.library
matieeesingbas.library
mathffp.library
audio.device

And then maybe some other amiga specific model rom module here and there that could also apply for this smart library loader.

The key to this smart library loader concept is that you keep the best from both worlds: compatibility is assured and new modules can be loaded if available on disk, and the boot process does not need to be restarted.

[kolla]

Originally Posted by rare_j

If there was a strip down guide for 3.9 I think a lot of people would like to try it.

It is really easy - just clear away stuff you do not need from sys:wbstartup, select conservative and simple Reaction settings (Reaction is really what is "heavy" in OS3.9), no fancy workbench backdrops, and finally replace all colour icons with old school icons.

You can even run most of OS3.9 on a 68000 if you remove or downgrade the bits and parts that require Reaction (mostly Prefs programs), and a few programs in C: (I don't recall exactly, but all of them are wtf... why is this 020+ "optimized"??)

[kolla]

Originally Posted by gulliver

BTW, the smart library loader could also solve the workbench.library rom issue in a similar way.

I thought newer SetPatch already does this

[tom256]

Great. Hope AOS3.x will be under constant development now. Not only bug fixed but also new features and performance improvements.

Thank You Thomas and Olaf!!!