Os 3.2 development preview

[kolla]

AFAICT the SX1 & SX32 work with the standard a1200 scsi.device

Yes, I can confirm for SX32 Pro and TF328 (boards I have), and the same is also the case for TF330 and TF360, as well as Witcher-CD32 from what I know.

[kolla]

Hm, so new functions... now it will be possible to write code that relies on this new utility.library, and hence on OS 3.2.

How clever is that?

[kolla]

So, when writing software one can...
- require OS 3.2
- check for version of utility.library and use those functions only when available, and use own custom code when not
- ignore new functions and use own code and rely strictly on what exists in pre-3.2 to make sure software runs equally well on anything OS3.

If you were a third party software developer, which would you go for?

[kolla]

@CBM

You know who wrote a lot of that “shit” that was tossed into OS 3.5 and 3.9?

Also a lot of that “shit” is what is now further developed in OS 3.2 - 3.1.4 was not a “clean cut” start from OS 3.1 sources, many components came from OS 3.9, because why not.

[kolla]

So now fragmentation is a good thing?

[kolla]

COP is triggered during a crash all fine, and the custom key combination is the decimal dot on the numeric keypad. So all you need is available at this point. (-:

Unless your Amiga is an A600.

[kolla]

A new feature is that it checks whether the boot volume or any other volume contains a newer version

Is it really smart to just load any "newer version" from any (randomly) available volume?

If you have multiple partitions with different versions of Amiga OS installed, some include components that are "newer" (as in higher number version string) than those you wish to use from the partition you boot from... how do you prevent those from being loaded? Remove the pure flag on all relevant files?

[kolla]

Boot partition first. Then any other partition. Not any different from the logic by which the workbench and icon libraries are loaded. Actually, since A4000T times.

On A4000T it was already quick&dirty work-around, and back then it was not an issue as those two components either were in kickstart, or they weren't, in which case they could be loaded from disk.

The case now is different, we are now not just talking about components that may or may not be in kickstart, but about updating just about any components that are in kickstart, with rather randomly available components existing on available file systems.

So if you boot from floppy on a system that has a hard drive with several boot partitions that have different versions of workbench.library and icon.library - what can one expect?

Does it check other bootable filesystems first, using boot priority?
Does it just pick the first version it finds that is an "update", or does it continue to scan and pick the one with highest version string?
Does it care about pure flags, like LoadModule now does?
Does it do any validation, or will it blow up if it "by accident" finds non-native modules from available on AROS, OS4 or MorphOS partitions?

[kolla]

In which case you read the bloddy manual. Which is the recommended cause of action for COP anyhow.

Right, but why not just use a more available and less obscure hotkey as default in the first place.

[kolla]

Right, but why not just use a more available and less obscure hotkey as default in the first place.

Such as RETURN probably? Come think about it, would you?

I was not thinking of Enter, no. The otherwise useless caps-lock would be my choice.

[kolla]

What if console-handler had built in multiplexer with scrollback buffers...

[kolla]

You would typically use this to point "RAM:ENV" to "ENVARC:" such that any file that is accessed in ENV: is automatically copied from ENVARC: to ENV: when needed.

The only time a copy in env: is needed, is when the content differs from that in envarc:, so instead of copy on access, it would make sense to just copy on write to env: and on access follow the link to envarc:.

[kolla]

An exclusive write to envarc: is also reflected in env: today with happyenv/env-handler, but no program really does this.

I cannot think of any program that only writes to envarc: without also writing to env: - can you? “Save” means “save and use” for all prefs programs at least. Or do you plan to change that?

[kolla]

Really, sounds confusing - “save, but do not use!”

Well, then perhaps SetEnv should be improved with this feature too, “SetEnv SAVEONLY” or thereabouts... and likewise for OS prefs programs.

[kolla]

So this is all bogus?

http://aminet.net/package/driver/media/IDEfix97

IDE-fix:
Enhance your IDE-port! Faster transfer, faster booting, less CPU use!
No MaxTransfer troubles, set MaxTransfer as big as you like!
TD64 & NSD commands supported, use IDE drives bigger than 4 GIG with your
Amiga (requires FileSystem with TD64 and/or NSD support).
Patches into the system "on the fly", no reboot required.
Use 4 IDE drives with your Amiga (with additional 4 drive adapter)!!!
Supports removable IDE units (SyQuest or ZIP IDE drives) without trouble!

[kolla]

Second, IDEfix does not issue LBA48 commands as the scsi.device does, and hence limits the maximum drive capacity to (IIRC) 128MB. Any larger drive will appear in the HDToolBox only as 128MB drive. Then people come along, partition their drive/card under UAE, and insert it into the Amiga, and then all hell breaks loose because IDEfix cannot address any blocks beyond the 128MB limit, even though the partition appears to be the right size.

Ah, now I get it - you just wrote 128MB instead of 128GB three times in a row!

(Also, "Gary IDE detection logic" - do you mean "Gayle IDE detection logic"? Or is this another example of German humour?)