AmigaOS 3.1.4! [beta]

[MartinW]

Will pick this up when it comes out, whoever it has to be bought from.

The whole 3.9 vs 3.1 thing is moot. As was said, they're very different things. For my A1200 that is pretty much just used for games I use 3.1 now as it's nice and quick in 256 colour mode relatively low res WB and I just don't need to extra bells and whistles of 3.9 just to spin up some WHDLoad games, but for my more "pro" 060 machine that will do development and have internet and all the rest of it I use 3.9 and wouldn't want to do without it!

[Gzegzolka]

Interesting stuff. So why 3.5-3.9 is so different that many of You still stay with 3.1? Is it all about speed or are there any compatibility issues with classic software and games?

[kolla]

I run OS3.9 everywhere, easier to strip down 3.9 to the level of 3.1 than to patch 3.1.

[Olaf Barthel]

Originally Posted by grond

Well, I'm just curious what is stopping Hyperion from releasing OS4 for 68k. It looks like it can't be legal reasons any more.

For one thing, the APIs have diverged so much by now that you couldn't "just" backport the software, you would also have to retrofit the missing API functionality in the operating system. That might up to a point be possible, but it will cost you.

These hypothetical changes would cost you in terms of memory and CPU load. On a 1990'ies 68k Amiga this would impose additional limitations on what the operating system could do.

Again, none of these changes are technically impossible, but the target audience would shrink very quickly. I suppose we might already be in the low hundreds of active Amiga users. There is only so far how you can limit the number of Amiga users who might want to use and pay for such changes.

Finally, you'd probably have to toss the idea of having the same code base support both AmigaOS 4 and AmigaOS 68k. You'd have to fork the software and develop both platform branches separately. This is very difficult to pull off successfully, especially considering the circumstances.

[Michael]

Doing a complete refresh of Reaction GUI would have been a good start and have a huge benefit on compatibility, allowing all the modern prefs and tools from the current OS4 to be recompiled for classic.

[Amiga4000]

I got to thinking, doesn't Jen's ACA 500+ have AOS3.1 in ROM for reinstalling the system to HDD?

I'm thinking that Jen's must have some sort of agreement with Hyperion for this functionality, and maybe only Jen's can answer this but, will this new OS update be made available, at some point, to download and refresh the OS in the ACA's ROM? Free? Not free?

Also, I am wondering if this AOS3.1 update will be in ROM on the new A1200 Reloaded?

[wmaciv]

THIS! I would pay good money for this update; LONG overdue, and written by individuals who understand what counts...

[eXeler0]

Originally Posted by Olaf Barthel

For one thing, the APIs have diverged so much by now that you couldn't "just" backport the software, you would also have to retrofit the missing API functionality in the operating system. That might up to a point be possible, but it will cost you.

These hypothetical changes would cost you in terms of memory and CPU load. On a 1990'ies 68k Amiga this would impose additional limitations on what the operating system could do.

Again, none of these changes are technically impossible, but the target audience would shrink very quickly. I suppose we might already be in the low hundreds of active Amiga users. There is only so far how you can limit the number of Amiga users who might want to use and pay for such changes.

Finally, you'd probably have to toss the idea of having the same code base support both AmigaOS 4 and AmigaOS 68k. You'd have to fork the software and develop both platform branches separately. This is very difficult to pull off successfully, especially considering the circumstances.

Yes, backporting the entire OS4 to 68k would be a "fools errand". If we are talking realism, it would probably be easier to look at it from the "other side".. Meaning, not what is actually needed or most wanted but what is easy to port and doesn't rely on a bunch of other stuff and simply do that.. (Not likely though..)
But it seems Hyperion are at least seeing that there's some movement in the 68k market likely thanx to Apollo-core. Don't want to sound too cynical, but it seems they are testing the waters with a moderate update and see if they can cash in a little. And frankly that's fine. I'll surely buy whatever patched 3.1.x to support the whole idea... And because I like 3.1 ;-) And because they contacted the right people to make this happen ;-)

[SnkBitten]

As this continues development will there be ROMs released? Didn't the last update put out for 3.1 only work in emulation as it wasn't possible to burn it to EPROMs and no ROM was ever released (though the changes were extremely small in the KS).

I'd prefer to see the larger HD supported in ROM so you can eliminate the required under 4GB boot partition.

[Jope]

40.72 was released in rom image form and it works fine in a real Amiga when burned to EPROM.

I hope this eventual 3.1.x release will also come in rom + disk form.

[patrik]

@Olaf:

Will a MaxTransfer fix be included for the A600, A1200 and A4000 scsi.device? With fix I mean internally splitting transfers in 0x1fe00 large chunks and not relying on the deprecated ATA1 functionality.

[SnkBitten]

Originally Posted by Jope

40.72 was released in rom image form and it works fine in a real Amiga when burned to EPROM.

I hope this eventual 3.1.x release will also come in rom + disk form.

Did that include splitting it for an A4000? I remember reading of complaints in that it couldn't be split by the known tools and rendered to Hi - Lo 256K ROMs.....or something like that.

[Olaf Barthel]

Originally Posted by patrik

@Olaf:

Will a MaxTransfer fix be included for the A600, A1200 and A4000 scsi.device? With fix I mean internally splitting transfers in 0x1fe00 large chunks and not relying on the deprecated ATA1 functionality.

Sorry, this is an area in which I must defer to Thomas. Short of tinkering with the less pleasant bits of the partitioning tools, I prefer to steer clear of the mass storage complex (there's probably a reason why "mass" and "mess" sound alike). My brain very nearly exploded when I researched how HDToolBox and scsi.device/hddisk.device of old would interact with the ST-506 interface devices.

That said, these limitations definitely should be respected by the IDE scsi.device, because just about nobody seems to bother checking the MaxTransfer properties of volumes, even if these are properly configured for a change. Some file systems do their best, but you cannot expect data recovery or disk copy software to be as diligent.

[Jope]

Originally Posted by SnkBitten

Did that include splitting it for an A4000? I remember reading of complaints in that it couldn't be split by the known tools and rendered to Hi - Lo 256K ROMs.....or something like that.

Probably that was the split into modules part, which is relevant if you want to build a custom kickstart for yourself.

A wordwise dissect into lo and hi roms does not care about the contents of the file. If it does, you can switch to a dumber tool.

[Toni Wilen]

Does new fastfilesystem support KS 1.x or do I need to do yet another compatibility patch?

Maxtransfer

It is fixed (no reads from IDE CHS/LBA registers) if this driver is also based on v52+ scsi.device (which Jens licensed for ACA500/plus).

[kolla]

Re-implement all Reaction prefs programs from OS3.9 with gtlayout.library <3

[Locutus]

Originally Posted by kolla

Re-implement all Reaction prefs programs from OS3.9 with gtlayout.library <3

better yet, have all the prefs tools store their shit in human readable formats :-D

[kolla]

Originally Posted by Locutus

better yet, have all the prefs tools store their shit in human readable formats :-D

Oh man, that would be crazy... xml, json, yaml... lol

I guess parsing text files would slow down booting considerably, but having alternative prefs program that can take text as input would be great. Like an IPrefs daemon with AREXX port

[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

[rare_j]

Originally Posted by kolla

I run OS3.9 everywhere, easier to strip down 3.9 to the level of 3.1 than to patch 3.1.

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