Happy Easter

Brussels, March 31, 2013

Easter seems like an appropriate time to provide a short update on the development status of a few key components of the upcoming AmigaOS 4.2.

  • Exec SG  : kernel development has been forked off into an experimental and stable branch, to facilitate field testing of potentially drastically new features such as the scheduler, separate address spaces, 64 bit address space awareness etc.
    The task scheduler was completely rewritten in C and now implements the long planned “pluggable” scheduler functionality  : the scheduling algorithm can be changed on the fly, during runtime depending on factors like task’s preference and CPU load, different CPU cores using different scheduling algorithms. The re-write of the scheduler also allows for load balancing which is required for proper multicore support.
  • Work is in progress on yet another Power ISA implementation.
  • Gallium  : bumped to Mesa 9.1, i.e. OpenGL 3.1. Software renderer already implemented, work on hardware accelerated drivers within the framework of Gallium will benefit substantially by the experience gained developing Warp3D drivers for the AMD Radeon Evergreen range (Radeon HD 5xxx/6xxx).

Please note that whilst work on AmigaOS 4.2 is in progress, work on other components is also ongoing and will be made available via AmiUpdate to registered users of AmigaOS 4.1.

Hyperion Entertainment’s management and the AmigaOS 4.x development team wish to thank all of you who have provided much needed support of our efforts by buying AmigaOS 4.1 (either as a standalone copy or together with suitable Power(PC) based hardware available from our hardware partners A-EON Technology and A-Cube Systems.

We greatly appreciate your support and wish you a Happy Easter  !

Classic Cinemaware Returns to AmigaOS

As stated in the official press release, Cinemaware’s original 68K games have been re-released for AmigaOS.

Wings

Screenshot of Wings™ on the AmigaOne X1000

Using original Amiga ROMs and Workbench files along with the UAE emulator, current AmigaOS 4.1 owners can enjoy complete Amiga 68K emulation on their PowerPC based systems. The RunInUAE package by Chris Handley makes it possible to double click on each game to automatically launch UAE. There is even a JIT compiler in the works which should dramatically speed up emulation when it is completed.

dotc-a500

Defender of The Crown® on the AmigaOne 500

Each Cinemaware game utilizes WHDLoad to enable it to run with a simple double click of the mouse. WHDLoad may be registered to remove the nag requester and help support even more original Amiga game conversions.

All that said, the emulation is not 100% perfect. This is where you come in. UAE is very configurable and specific config files are provided for some games. If you know of any tricks to help improve those UAE config files please share them. There is also the decision to use WHDLoad versions of the games. Some people prefer ADF versions instead. Please consider helping us improve the games and possibly provide ADF versions as well. The best way to get in contact with us is via the contact form or the support forum.

rr-a500

Rocket Ranger™ on the AmigaOne 500

AmigaOS 4.1 Update 6 users should note they must have the Emulation and RunInUAE updates applied to their systems for smooth operation. If you have not yet updated, this is a great reason to do so.

I would like to thank the AmigaOS beta testing team for helping to find and fix the many issues that cropped up during beta testing. A special thanks must also go out to Lars Fuhrken-Batista of Cinemaware and Ben Hermans of Hyperion Entertainment for making this project possible.

Steven Solie
AmigaOS Development Team Lead

Are you AmiUpdated?

blog_updateSince the release of AmigaOS 4.1 Update 6 there have been over 25 updates released via the integrated AmiUpdate system.

AmigaOS customers can expect many more updates as we catch up on component releases. There may even be some new features slipped in now and then to keep things interesting.

Simply select “Update software…” from the Workbench menu and apply the updates when it is convenient to do so.

If you have any troubles with the new software update system remember that support is available at support.amigaos.net and we’ll do our best to help.

AmigaOS 4.1 Update 6 Released

AmigaOS 4.1 Update 6 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:

Update 6 is a rather unique update in that it includes no bug fixes. What Update 6 does include is a new and more efficient way of delivering bug fixes. A new “Update software…” menu item on Workbench now launches AmiUpdate which will now handle all future AmigaOS software updates.

Since AmiUpdate does not do much without a back end database, a new AmigaOS update database has been created. This database tracks dependencies between components so that users can be assured they are applying the correct updates to their specific systems. The rollback facility may be used to undo updates in the event of problems.

Users are strongly encouraged to install Update 6 as it will be the only way to receive future AmigaOS updates between major releases.

Special thanks to Simon Archer for his amazing AmiUpdate product and the AmigaOS testing team for their invaluable effort on this release.

Yet Another AmigaOS Core Developer

Please welcome Fredrik Wikström as our newest AmigaOS core developer.

Fredrik has been busy on the Amiga scene for many years and has produced a lot of very useful software. More information about Fredrik’s work can be found on his web site.

Given Fredrik’s exemplary track record, I think we can all expect some very good things from him.

If you have used Fredrik’s software in the past, please also consider a donation to show your appreciation. If bounties are more your thing, he has been working on a few at Open Amiga.

Steven Solie
AmigaOS Development Team Lead

New AmigaOS Core Developers

Please welcome our newest AmigaOS core developers: Alex Carmona and Lyle Hazelwood.

Alex has been a dedicated beta tester and programmer for many years. He has decided to take the leap to OS development. Now he can fix all those bugs he has been filing…

Lyle took the plunge and purchased an AmigaOne X-1000 system. He has been a very active developer ever since. More information about Lyle can be found at his web site.

Their names have already been added to the credits page on the AmigaOS web site. You can also find both of them actively helping people on the AmigaOS support forum.

Memory Page Locking Confusion

With the introduction of the AmigaOS Documentation Wiki and the uploading of the latest Amiga ROM Kernel Reference Manuals we have been given the opportunity to bring the Amiga Operating System’s documentation up to date. Although not complete, several dedicated volunteers have been slowly improving on that documentation.

One of the most confusing changes to the API has proven to be Exec’s new LockMem() and UnlockMem() function calls. These functions are use to lock and unlock memory pages. Normally, a programmer should not have to worry about memory pages nor worry about what the swapper is doing. Such details should be left to the operating system. However, in special circumstances (e.g. device drivers) it may be necessary to use LockMem() and UnlockMem().

What really confused programmers is the fact that we advocated the use of UnlockMem() even when the programmer did not explicitly call LockMem(). The issue was primarily centered on MEMF_SHARED memory which, by default, is automatically locked. That in itself isn’t really a problem. Add in the fact MEMF_ANY memory is translated to MEMF_SHARED memory and you have the potential for a lot of locked memory pages and thus ineffective use of system memory.

AmigaOS programmers are always trying to be helpful. Pretty much everyone jumped on the bandwagon and declared this API change as a travesty of enormous consequence. Why didn’t the FreeVec() function unlock the memory for them? Why must UnlockMem() be provided the size of the memory to unlock? They were very close to rioting.

After much discussion and fact gathering, the AmigaOS development team have officially changed our minds. The new advice is to never call UnlockMem() unless you explicitly called LockMem() in the first place. The wiki has already been updated to reflect this.

AmigaOS programmers are also rather attentive. “What happens to those implicitly locked memory pages when I don’t call UnlockMem()?” The truth of the matter is that some pages will actually be leaked. That is, some of those memory pages will not be moveable and thus not swappable. This does not mean the memory is not available to the system. This means the underlying memory pages cannot be swapped.

Now before resuming the riots, please take a moment and think about this. The system has been running fine for years now without programmers calling UnlockMem() on implicitly locked memory. We only recently explained this on the new documentation wiki. Something deeper is indeed going on here.

Without going into all the internal details, the system will automatically unlock memory that has been freed even if you forgot to call UnlockMem() on that memory. This is not true for every memory allocation but it is true for the majority of the memory in the system. This is why everything has been running fine for years now.

So what is going to happen to those lonely locked pages that can’t be automatically unlocked? The plan is to modify Exec’s discrimination between MEMF_SHARED and MEMF_PRIVATE memory. They will be moving to their own page caches. This effectively eliminates the problem entirely without a single line of code changed in your applications.

We are very sorry for the confusion. In the end, we figured it all out and I think this new advice (only call UnlockMem() if you called LockMem()) is very easy for programmers to follow.

Steven Solie
AmigaOS Development Team Lead

AmigaOS 4.1 Update 5 Released

AmigaOS 4.1 Update 5 has now been released.http://upload.wikimedia.org/wikipedia/en/0/05/Boingball.png

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:

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 Permedia2 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!

Xena – Signs of Life

The first tools for programming Xena (no, not the Warrior Princess) are now ready for distribution.

The XMOS XS1-L2 chip built into each AmigaOne X1000 with a unique local bus connected directly to the PA6T.

These tools provide the ability to load programs directly into the the Xena chip as well as monitor most of the internal registers as the code is executed.

Unlike other XTAG devices, no adapter board, USB port, or JTAG cables are needed. We can access all of this directly from the AmigaOS command line.

In addition to the new tools, a new AmigaOS resource named xena.resource is included to arbitrate access to the new hardware features.

I have also included a simple .xe file that will flash two LEDs on the AmigaOne X1000 board, as a “proof of programming” demonstration.

These tools were ported from code provided by Segher Boessenkool. Please be sure to thank him if you see him around the XCore Exhange Forums.

The tools are available now and can be downloaded directly from Hyperion’s web site by all registered X1000 users. The new tools and documentation will be added to a future release of the AmigaOS SDK as well.

Information on XMOS chips, compilers and other tools are available at their web site.
Excellent community resources may be found at the XCore Exchange.

I hope these tools provide a beginning into the exploration of these Xciting new features.

For more information about me please visit my web site.

LyleHaze

Introducing the AmigaOS Documentation Wiki

The AmigaOS Documentation Wiki is now available.

This new wiki is meant to fill a gap which we have been struggling with since the launch of the AmigaOS 4.0 project: proper user and developer documentation.

This wiki is using the most up to date, original AmigaOS documentation we could obtain permission to use as a baseline. It is true some of the information is rather dated and/or obsolete. But a majority of the information still applies to AmigaOS 4.0 and beyond. In my opinion, it is better to start with something rather than be staring at a mostly blank wiki.

We are also seeking to reestablish AmigaOS related standards and registries. The official SANA-II standard can now be found here. The IFF FORM and chunk registry is now here. The classic Amiga Manufacturer ID registry is here. Special thanks to Neil Cafferkey for the SANA-II wireless extension and James Jacobs for taking care of the registries all these years.

Editing rights to the wiki are currently limited to registered users only. We are looking for volunteers from the Amiga community to help out. If you would like to contribute in any way, please contact us using the contact form on the AmigaOS web site. Any help would be greatly appreciated!

Steven Solie
AmigaOS Development Team Lead