AmigaOS4.1 Update 5 Released

[Terminills]

Why, when was the last MorphOS or AROS update?

are we talking distros if so the 13th

http://www.amiga.org/forums/showthread.php?t=62363

[Karlos]

are we talking distros if so the 13th

http://www.amiga.org/forums/showthread.php?t=62363

I must have missed that. Then again, I have been busy lately.

[takemehomegrandma]

Seems like some nice highlights there.  I think the full 3.1 installation and roms is a very nice touch

From the OS4.1.4 release notes:

"Introducing the new Emulation drawer with official AmigaOS 3.x ROMs and Workbench files. AmigaOS ROMs are provided for all classic Amiga models and the CD32 platform.
Added RunInUAE contribution to utilize the new Emulation drawer."

With better 3.1 integration, its beginning to look more tempting.

"Integration"?

:confused:

[XDelusion]

I still mostly use my A1200 for that (using 3.9 and 4.1). However, OMSS on the A1 with the Maestrix is pretty sweet.

It doesn't matter what other software I try, I somehow always come back to OctaMED.

Me too, I'm all about my old Amiga, but I'd still love to see next Gen Amigas do have the stuff they did, I.E. the musick...

...which OS 4 seems to have put a priority on, sadly the hardware is too expensive for me to justify dropping money on atm.

[Matt_H]

Catweasel! Finally!

[wawrzon]

id rather guess the update should address bad climate of the last two days after trevor leaked the production costs of x1k become unbearable. well, if certain guys like tommysammy consider even stepping down from the platform, it telling. even if aeon and os4 arent a personal union anymore it would be stupid to let the whole ship sink just as effect of collateral damage. or is there still some netbook in sight?

nevertheless nice that the update sports some desktop backgrounds, even if apparently not from djnick. no rounded corners, btw? what concerns including complete workbench3.1 it must have been helluva of development work involved. i hope the subsequent updates will include also the older workbench versions one by one down to 1.2.

btw, those w3d updates, ist that your work, karlos? i guess the individual program setting infrastructure has been backported from alains wazp3d, right? and the sam460 audio driver, is that an updated version in comparison to what the users have been already supplied with?

[Minuous]

Does this mean we might see an updated SDK soon? There is functionality that has been in OS4.1 for months at least, which is still not accessible to third-party developers because there are no updated includes.

[redfox]

Upgrade completed.  My system seems a bit sluggish right now, but it might be network related.  I was having a few issues before I downloaded the update.  I will see how it goes over the next few days.  Fingers crossed.

---
redfox
MicroA1-C + AmigaOS 4.1 Update 5

[Matt_H]

Am I missing something regarding OS 3.1 integration? Wasn't that part of the last update? Don't have my AmigaOne with me, so I can't check/compare...

[Karlos]

btw, those w3d updates, ist that your work, karlos?

Yes.

i guess the individual program setting infrastructure has been backported from alains wazp3d, right?

No. Wazp3D has a somewhat different mechanism. I believe it creates a file in the same directory as the application, whereas Warp3D relies solely on environment variables.

http://wiki.amigaos.net/index.php/UserDoc:Warp3D#Application_Profiles

I added support for this in the Permedia2 driver prior to update 4. Since then, I refactored and generalized the code so that it could be used by other drivers and added it to the R200 and R100 drivers in turn while working on them.

[wawrzon]

@karlos: i see, i suspected it since alain introducetd similar mechanism just of late. dunno which is better, but i fear env variables should be used with caution even though it sounds more amiga-like. im not familiar with how do you create them, but they might duplicate or cross interact once there are more applications and also one tends to forget them when something goes wrong. just thoughts. anyway, nice to hear that one of few things worth mention in this update comes from you.

[Karlos]

@karlos: i see, i suspected it since alain introducetd similar mechanism just of late. dunno which is better, but i fear env variables should be used with caution even though it sounds more amiga-like. im not familiar with how do you create them, but they might duplicate or cross interact once there are more applications and also one tends to forget them when something goes wrong.

The env mechanism is fairly simple. Each driver already has it's own directory within ENV:Warp3D in which it stores the global settings for that driver. I extended this by adding subdirectories, where the name of the subdirectory needs to match the name of the executable the setting is for. You add them on an as-needed basis.

To quote the documentation:

The general path to these settings is ENV:Warp3D///. Thus, when the application "ShootEmUpFTW" running on a Radeon 9250 allocates the 3D resources, the driver checks to see whether any of the driver's environment settings in the ENV:Warp3D/RadeonR200/ directory have also been set in the ENV:Warp3D/RadeonR200/ShootEmUpFTW/ directory. Any that have will override those in the main ENV:Warp3D/RadeonR200/ directory.

So, when an application first loads the driver, the global settings are pulled in. This is the standard behaviour.

Next, whenever the application creates a 3D context, the driver tries to determine the command name of the application that opened it (falling back onto the task name if nothing else works) and looks to see if a subdirectory of overridden settings exists with that name. If it does, it re-evaluates any that it finds in there and applies them to the current context only*

Per application settings always trump global ones. This means that you can rely on the global settings mostly and tweak individual variables per application as necessary to get around any bugs, incompatibilities etc.

*unless the creator of the 3D context is a vanilla Task, in which case, it can't do the necessary IO and so just uses the global settings as they are. Thankfully I've not seen any examples of this.

[Crumb]

@Karlos

Do you have plans for a BlizzardPPC SCSI driver? The chip is already supported in PCI cards and there are just minor differences. "Strim" adapted the scsi driver to NetBSD in case you need to ask hima bout the differences. He also has added G-Rex support to NetBSD, and he supports all G-Rex slots. BlizzardPPC SCSI sources are already at the NetBSD repository and I'm sure he'll commit recent G-Rex changes soon (just in case he hasn't already done it)

[wawrzon]

The env mechanism is fairly simple. Each driver already has it's own directory within ENV:Warp3D in which it stores the global settings for that driver. I extended this by adding subdirectories, where the name of the subdirectory needs to match the name of the executable the setting is for. You add them on an as-needed basis.

i thought so. perhaps this is sthe most efficient way, only different apps may have same executable names which as long as stored in separate directory. of course im rtather painting the devil on the wall as they say in germany, but we had something similar on aros of late. scalos makes the same dumb generic assignment as wanderer does, and this leads to all sorts inexplicable problems with scalos, as result of a too generic assumption on a directory name. just an example.

[Karlos]

i thought so. perhaps this is sthe most efficient way, only different apps may have same executable names which as long as stored in separate directory. of course im rtather painting the devil on the wall as they say in germany, but we had something similar on aros of late. scalos makes the same dumb generic assignment as wanderer does, and this leads to all sorts inexplicable problems with scalos, as result of a too generic assumption on a directory name. just an example.

Well, if two executables have the same name, the same environment settings will be used. This is not anticipated to be a major problem, but if it is, renaming one of the executables should work. Remember, the vast majority of Warp3D applications are games.

[itix]

Well, if two executables have the same name, the same environment settings will be used. This is not anticipated to be a major problem, but if it is, renaming one of the executables should work. Remember, the vast majority of Warp3D applications are games.

You could calculate md5sum from the executable. Now if executable is updated it will be detected automatically and user dont have to edit settings again if compatibility problems were fixed in a new version.