Amiga.org
Amiga News and Community Announcements => Amiga News and Community Announcements => Amiga Software News => Topic started by: Karlos on August 16, 2012, 04:27:45 PM
-
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!
-
More info here: http://blog.hyperion-entertainment.biz/?p=683
Published
http://anticusa.wordpress.com/2012/08/16/amigaos-4-update-5-is-out-for-all-amigaos-is-officialy-4-1-5/
Everyone should be running up to Hyperion webiste, hope stability will be finally reached and all forces to OS 4.2
-
Seems like some nice highlights there. I think the full 3.1 installation and roms is a very nice touch
-
Seems like some nice highlights there. I think the full 3.1 installation and roms is a very nice touch
File information for AmigaOS4.1Update5.lha
File size: 38888847 Bytes
File date: 2012-08-16
Download
This is AmigaOS 4.1 Update 5 for the AmigaOne-XE, AmigaOne 500, MicroA1-C, Pegasos II, Sam440ep, CyberStormPPC and BlizzardPPC platforms.
Please read the enclosed ReadMe.guide file for installation instructions.
This update assumes that Update 4 is already installed on your machine.5
-
Authentic Amiga ROMs and Workbench files are provided in the new Emulation drawer.
/me chuckles :)
-
/me chuckles :)
Unlike some that promised it and stolen AROS KS.
-
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.
-
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.
Dont believe its linked since each team works for itself and historicaly those don`t match even close. But its good to see all 3 improving
-
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?
-
Why, when was the last MorphOS or AROS update?
Beats me. Ask the conspiracy expert. LMAO!
Anyway, I wanted this update out back in May or June but such is life in the software world. The delays enabled us to include some important fixes (like Warp3D drivers) so it all seemed to work out in the end.
-
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 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.
-
With better 3.1 integration, its beginning to look more tempting.
-
Unlike some that promised it and stolen AROS KS.
lol how can the AROS roms be stolen btw?
-
Why, when was the last MorphOS or AROS update?
are we talking distros if so the 13th :D
http://www.amiga.org/forums/showthread.php?t=62363
-
are we talking distros if so the 13th :D
http://www.amiga.org/forums/showthread.php?t=62363
I must have missed that. Then again, I have been busy lately.
-
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 (http://www.amiga.org/forums/showthread.php?t=60105):
"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:
-
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.
-
Catweasel! Finally!
-
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?
-
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.
-
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
-
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...
-
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: 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: 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
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)
-
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.
-
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.
-
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.
-
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.
-
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.
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.
-
Update...
Working fine so far this evening, after the system was powered off most of the day. During the week, I use my system in the evening and power off when I am done.
---
redfox
-
@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)
+1 SCSI driver
Advance GUI for Bvision
-
Fantastic update, now Eye Viewer again works fine. Thanks to developers and testers of OS4.
-
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
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.
-
Beats me. Ask the conspiracy expert. LMAO!
Anyway, I wanted this update out back in May or June but such is life in the software world. The delays enabled us to include some important fixes (like Warp3D drivers) so it all seemed to work out in the end.
Thanks Steven.
How much will it improve compatibility with e.g. Warp3D 68k and PPC AmigaOS 3.x software and games?
People already report happy findings :-)
-
With better 3.1 integration, its beginning to look more tempting.
And Warp3D now, closer to MOS AOS 3.x compatibility levels, thumbs up!
As well as first to come with legal OS 3.x and KS files included beside AF
-
Update...
Working fine for 2 weeks and a few days. It appears that my system needed to be powered off and on after the upgrade. I assumed that the autorestart at the end of the install script would be enough. My system was a bit sluggish after the upgrade but was fine the next evening after being powered off for most of the day.
Looking back, I think the sluggishness was a result of a system freeze while I was backing up files to my USB devices before I downloaded and installed the new update. I should have powered off and on at that time, but I may have done a reset from the keyboard and continued on. In any case, I suspect my system was already compromised before I downloaded the new update.
---
redfox
MicroA1-C
AmigaOS 4.1 Update 5