AmigaOS4.1 Update 5 Released

[Karlos]

More info here: http://blog.hyperion-entertainment.biz/?p=683

AmigaOS 4.1 Update 5 has now been released.

More details and a place for registered users to download the update can be found at Hyperion's main web site.

The following AmigaOS platforms are supported:

* AmigaOne 500 (460ex)
* Sam440ep and Sam440ep-flex (all variants)
* AmigaOne XE
* MicroA1-C
* Pegasos II
* CyberStorm PPC
* Blizzard PPC

Besides the usual bug fixes, some highlights include:

* Optimized DMA copy routines for 440ep and 460ex based platforms.
* SM502 audio driver and Mixer for AmigaOne 500 systems (460ex).
* Updated Radeon, R200 and Permiedia2 Warp3D drivers. Per-application configuration is now possible to help work around bugs in old software. User documentation is provided on the wiki.
* Catweasel driver for floppy disk, SID chip and joystick support.
* MIDI support now included via the camd.library.
* Professional photograph backgrounds provided by mediacube.
* Improved Amiga 68K emulation. A full Workbench 3.1 installation is now included. Authentic Amiga ROMs and Workbench files are provided in the new Emulation drawer.
* AmigaOS support is available via Hyperion's support forum.

A special thanks to the AmigaOS development and testing teams for their hard work on this release!

[Karlos]

Funny how when MOS or AROS comes out with an update you can be certain that an OS4 update will be released within a few days.

Why, when was the last MorphOS or AROS update?

[Karlos]

I wish I could afford one so I could have a fast next Gen Amiga with proper Midi support, not to mention the ability to run OctaMeD SS.

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.

[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.

[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.

[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.

[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.

[Karlos]

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.

Perhaps it wasn't clear, but the driver only ever reads environment vars, it never writes them. If an updated executable gets a new name and you want to keep the same settings, rename the subdirectory in ENVARC:Warp3D//

Tweaking shouldn't be that common since for the most part, the default settings are the correct ones. Notable exceptions are things like Wipeout2097, which depend on a number of incorrect behaviours of the legacy Permedia2 driver.

Many of the driver options are performance tweaks, for example, being able to turn redundant framebuffer clears into no-ops, using a narrow Z buffer and so on.

[Karlos]

Ah, I see. I thought it would have automatically generated default settings for each Warp3D application you could edit from a preferences editor. It is clear now.

The reason I chose to do it this way was the fact that the drivers already used environment variables to change their global options. Rather than introduce a completely new (from the user's perspective) way of managing settings, it seemed more natural to extend the existing one.

The fact that the application settings will always override the global ones (which in turn will always override the compiled-in defaults) gives you some flexibility in how you manage things. Aside from the obvious use case of enabling something just for one application that is disabled by default, you might decide that the compiled in default for a particular feature is not what you want, except for one application. In that case, you could disable it in the global settings and then re-enable it in the settings just for that app.

In my case, for example, almost none of my Warp3D-using software uses a stencil buffer. I could therefore turn on "Use16BitZBuffer" globally for my Radeon 7000 and disable it again for the minority. The default 24-bit depth buffer with 8 unused bits of stencil is a waste of VRAM and bandwidth for the rest.

[Karlos]

@Karlos

Do you have plans for a BlizzardPPC SCSI driver?

I made a start on one a while ago, but it's not been worked on for some time. Right now, it's just a scaffold. The device opens, creates the necessary ports, interrupt, worker process and so on and can be queried using the regular IORequest mechanism. However, there's no actual chip-level code in it yet.

I don't have much time to work on amiga projects and my small plate was full of Warp3D stuff as it was.