AmigaOS 68k development - components, critics, bugs, work-arounds, tips&tricks

[kolla]

Since other threads about "OS 3.1.4" and "Os 3.2" keep derailing because of "most users" who prefer to not see any discussion on the actual operating system, and rather wish that everyone shut up and just hail the whatever the "official team" might come up with... here is an alternative thread, where those of us who are not unconditional "yes men" can also air our thoughts regarding the development of the operating system that is among our favourite hobbies.

From your point of view
- have there been changes in OS 3.1.4 (and the 3.2 preview) that you like in particular?
- have there been changes that you don't like so much?
- have there been changes that are irrelevant for how you use the Amiga?
- have you found bugs? have you reported them? what happened?
- have you needed to make work-arounds as counter-measures for bugs and changes in the OS?
- have you found unintended "features" in the updates that can be exploited in cool ways?
 - what more changes and improvements do you wish to see?

[kolla]

I can start with saying that the number one killer feature in OS 3..4 for me, is 68000 support for v45 Workbench and ASL prefs.

Sadly the Workbench prefs does not include the Ghostbuster functionality (http://aminet.net/package/util/cdity/GhostBuster) and the OS developers seem incapable of understanding why anyone would wish to hide a device icon, especially since it would prevent the user from selecting the hidden device and formatting it (not really, but that is what an OS developer has given as reason) - and I wish for that functionality for 6800 systems as well - Ghostbuster comes with sources, but it uses Reaction, for which there is no 68000 support, plus I am no big fan of Reaction in the first place. So what to do, what to do... aside from cloning the Workbench prefs program from fresh, there is one option, I suppose - use the Ghostbuster commodity, and just binary patch the prefs (or wait for OS 3.1.4 sources to leak).

Regarding ASL.. I prefer v45 ASL over ReqTools and others, so I use http://aminet.net/package/util/misc/AslToRT to trap calls to reqtools.library etc and use ASL requesters instead. A more "clean" way, like implementing reqtools.library as a wrapper for ASL, would probably be preferable. Lastly, the "official" family of C:Request#? programs has always been lacking one member - RequestString - there is a myriad of third party variants around, mostly incompatible with each other - it would be very useful with an official RequestString that make all the others redundant.

[kolla]

- have there been changes that you don't like so much?

Yes there have been, several, but let's start with the most serious one - the new shell v46.

While I have enjoyed following the development of shell v45, v46 comes with a number problems:
  * it is buggy, changes are many and so are the bugs, they manifest themselves in the strangest ways and without access to neither sources, nor documentation (aside from the v45 guide on aminet), nor bug tracker, it is sometimes extremely tricky to fathom wtf is going on.
  * it is totally unnecessarily embedded in kickstart ROM chips, meaning its problems are "frozen" -
  * it introduces features "taken out of thin air", no consulting or interaction whatsoever with the shell users at large
  * its features are utter overkill for the so called "most users"
  * many of its features are pointless or have "issues" since they rely on a third party product to work as intended
   (a product with unclear legal status, an update with all ties to to Amiga Inc. removed would clear this up)

If I was Hyperion, I would not have allowed shell v46 in the kickstart chips. I would have insisted on keeping the built in kickstart shell small and tidy and, only with the limited set of required features - all this to make sure it is as tiny and as rock solid as possible. A cleaned up OS 3.1 shell, an amiga equivalent of POSIX /bin/sh. And then this minimal shell can be replaced on boot by more experimental, feature rich v46/47/whatever L:Shell-Seg on boot by SetPatch. And I would not make it available on ROM chips until at least a few months of testing "in the wild".

More later.

[kolla]

  * many of its features are pointless or have "issues" since they rely on a third party product to work as intended
   (a product with unclear legal status, an update with all ties to to Amiga Inc. removed would clear this up)

I agree with this 110%.... Nothing against the devs creating this HW but, supporting their HW in ROM makes NO sense to me.

Hm - HW as in hardware? I was talking about third party software, not hardware (I thought this was obvious)

[kolla]

Yes, but he has a point. Why support Vampire in the rom and not CD-ROM on ide scsi thats already part of the machine.

There is no Vampire support in kickstart ROM, I don't know why you suggest that there is.

[kolla]

But at least they fixed it so it'll detect an 060 and will still actually boot and complain that the libraries aren't in place.

The kickstart makes sure that any 040/060 (or similar) FPU is "turned off" on initial boot, and then Setpatch turns it on when loading appropriate CPU libraries.

[kolla]

I'm not up to speed on everything so I could be talking nonsense, but what about making a compressed ROM image which is able to fit more stuff. The kickstart on '030+ systems is often copied to fastRAM anyway.

I believe your first observation is the most accurate one At best, only parts of the kickstart can be compressed, and you would also need a decompressor and validator in place... it quickly grows bigger than what you gain.

[kolla]

Yea, fit more stuff. It could be decompressed on the fly at boot up and copied to RAM:  and off you go.... with a SCSI CDRW whirring away!  Great observation DX! The forum needs new blood like you! 

You can do _all you need_ if you just add a boot device to your system that contains the needed kickstart modules. It can be a partition on a disk, a floppy... anything.  Personally, I am leaning to doing what old 68k Macs had all those years ago - a dedicated "magic" partition at the start of the hard drive, dedicated for ROM modules and updates. One can argue that Amiga users should be smart enough to not need this, and just have the components floating around in SYS:, but I am not so sure.

[kolla]

The lower 0xE0 ROM space is now populated by the Vampires, so this option is taken as well.

The Vampires already support 1MB kickstarts, AROS uses 1MB kickstarts, and if there is any trouble regarding addresses, the Vampire products are still supported and the issues can be dealt with in updates. So, I believe your argument is pretty weak.

[kolla]

Thus, instead of following good engineering practise and use available extension mechanisms such as autoconf or the F-space ("debug") ROM or a CPU library, the vampire relies on its own mechanisms, which partially populates the E0-area, yes.

Good, then I suggest ignoring the Vampire cards and if things break, it will be up to them to fix it - after all, the 68080 has a proper MMU which they control fully, how hard can it be.

[kolla]

I don't know what you call "proper", and I don't see how the (rather minimal and incompatible to anything instead of proper) MMU has to do anything with the issue. It cannot remap address spaces.

From what I understand, that is the entire job of the "proper MMU" of the 68080 on the Vampire cards - to map addresses around so that AmigaOS (or EmuTOS) finds what it expects at the addresses it expects. For example, with "v3 core", map the entire chipset register address space out to where SAGA is located.

But regardless of this, it should be none of your concerns, and instead a concern for those who keep breaking "the rules".

[kolla]

Everything except the initial hardware diagnostics and the decompressor could be compressed. Decompressor is easily less than 1KB. BTW, this is how PC BIOS ROMs have been since the mid '90s.

Yes, they even use Lha from what I recall. However, the Amiga kickstart, is not the equivalent of a BIOS, and when did you last see a BIOS that was 512kB?

What I suggest is to keep the Amiga kickstart small yet functional - strip the "user interface" parts (shell, workbench.library and icon.library) to their bare minimums, enough to boot and work with legacy floppies. They can be replaced with feature rich on-disk variants when booting off hard drives.

[kolla]

Everything except the initial hardware diagnostics and the decompressor could be compressed.

Just to elaborate on this - exactly what, in your opinion, can be compressed?
Here is the content of the A1200 CBM OS3.1 40.68 kickstart

Code: [Select]

exec                                    14K
expansion                              2.8K
romboot                                3.8K
graphics.library                       104K
dos.library                             39K
filesystem                              24K
console.device                          15K
layers.library                          13K
scsi.device                             10K
con-handler                             10K
input                                  5.8K
audio.device                           4.3K
card.resource                          3.1K
utility.library                        2.5K
battclock.resource                     2.4K
ramlib                                 1.1K
ramdrive                               1.6K
cia.resource                           1.0K
misc.resource                          236B
wbtask                                 252B
potgo.resource                         376B
filesystem.resource                    472B
disk.resource                          908B
mathffp.library                        1.2K
timer.device                           3.6K
mathieeesingbas.library                3.7K
keymap.library                         3.3K
bootmenu                               5.7K
trackdisk.device                       7.3K
icon.library                           9.2K
ram-handler                            9.2K
shell                                   17K
intuition.library                      112K
gadtools.library                        23K
workbench.library                       70K
battmem.resource                       544B


[kolla]

That’s of little use when “most user” wants to boot from floppy or ADF, disabling the hard drives to save the little ram there is.

[kolla]

Ah, and you know what "most users want"?

You know that I consider "most users" a myth, an excuse to cling on to when "developers" run out of real arguments