Category Archives: AmigaOS

FUSE and NTFS for AmigaOS

280px-FUSE_structure.svgFUSE is short for Filesystem in Userspace. FUSE was created to enable non-privileged users to run file systems outside of the kernel which is a big deal for Unix-like operating systems. In AmigaOS, everything runs in userspace so FUSE is not nearly as important for Amiga users. What makes FUSE valuable is all the file system implementations which use FUSE such as NTFS, ext2, ZFS, etc.

The Amiga Operating System implementation of FUSE has been realized via a project called Filesysbox by Leif Salomonsson. A special thanks goes out to Leif for allowing his hard work to be utilized.

Amiga programmer extraordinaire Fredrik Wikström was then commissioned to port Filesysbox over to AmigaOS. Fredrik took the original code and updated it to AmigaOS 4.1 standards. This work included utilizing advanced DOS features such as object notification and the new file system API which seeks to completely avoid the esoteric DOS packet interface. Colin Wenzel is the main man behind the advanced DOS features.

Master_500pxIn order to test whether Filesysbox was working properly we needed a file system to go with it. NTFS-3G by Tuxera was chosen for this purpose. Fredrik also ported a full suite of tools to go along with NTFS itself.

Both Filesysbox and NTFS-3G are contributions being offered to registered AmigaOS users via AmiUpdate. The software licenses require that the source code be made available so registered users can download the matching source code from Hyperion’s web site in the downloads section.

blog_devIt is hoped that 3rd party developers will become interested in porting more file systems in the near future whether they are via the FUSE API or the new DOS file system API. The upcoming SDK will include everything you need. In the mean time, please feel free to utilize the provided source code and the AmigaOS support forum for assistance.

Finally, a big thanks needs to go out to the AmigaOS beta testing team for risking their hard drive partitions while testing NTFS-3G and Filesysbox. It is demanding and potentially destructive work that should not be taken for granted.

Ready for Music!

blog_softwareThe convenience of AmiUpdate has also allowed a few additions to your AmigaOS system. Camd.library was quietly added a few updates back. This contribution provides a common interface for programs that work with music in the MIDI format to connect with MIDI interfaces or to interconnect between applications. Now programs like Bars&Pipes Professional, AudioEvolution, HD_Rec, Dg-midi-monitor, Horny and CamdPlay will no longer require the user to go download and install camd.library. It will also ease installation of newer programs like Andy “Broadblues” Broad’s Line6PodEditor and his Perl to CAMD Link (Perl Amiga::CAMD).

Now, to make things even easier for the end user, the USB driver for MIDI devices is being added to the default AmigaOS installation as well. This means that if a user plugs in any MIDI class compatible USB device, AmigaOS will recognize the device and make it available to any program.

These additions together make programs for music much easier to install and run, so you can get right in to making music without worrying about the libraries and drivers to install.

71170_l

Bars&Pipes Professional and camd.library are maintained by, and the USB MIDI driver for camd was written by Lyle Hazelwood. Lyle accepts donations for his software at Lyle’s web site.

AmiWest 2013 AmigaOS Team

AmiWest2013-AmigaOS-Team1200AmiWest 2013 is now over and it was a heck of a lot of fun. We managed to grab a team photo this time.

From left to right in the front row sitting down we have Ken Wilde and Lyle Hazelwood. Next row back we have Bill Borsari, Flip LaFramboise, Trevor Dickinson and Tony Wyatt. In the back row we have Matthew Leaman, Val Marti, Paul Sadlik, Steven Solie and Alex Carmona.

A special thanks to Mike Brantley for taking the photo. Mike also took a lot more photos at the AmiWest 2013 show.

I think the big smiles on those faces says it all really.

I also took some time to update the AmiWest 2013 crowd on the current status of the Amiga Operating System which I will now summarize here:

  1. The netbook project initially announced at AmiWest 2011 has been cancelled. Below is an excerpt from an email to me from Ben Hermans dated October 10, 2013 on this matter.

    Despite best efforts by Hyperion and A-EON we were unable to get acceptable and stable conditions and terms from the Chinese supplier (price point, paying terms, required upfront, etc.)…

    The project was therefore cancelled in favour of a more future proof solution.

  2. A-EON Technology announces the Cyrus Plus Beta Test Programme. Follow the link for all the details and how to apply.
  3. Gallium3D Update
    • Software rendering completed
    • Working on the WinSys part of the implementation
    • Challenges encountered along the way:
      • Must be re-entrant, thread safe and multicore capable
      • Must run on a bare minimum system
      • Efficient
      • Possible to load non-Mesa and non-Gallium drivers
  4. X-Kernel Update
    • Task scheduler rewritten in C
    • Removed reliance on data structures (e.g. ExecBase task lists and ThisTask pointer)
    • Moving scheduler to run on auxiliary cores
    • All cores schedule tasks independently
    • Load balancing between cores
  5. AmigaOS 4.2
    • Depends on Gallium3D release
    • May or may not depend on multicore support
  6. AmigaOS 4.1 Update 7
    • Will be needed for Cyrus Plus product release
    • Consolidates all previous updates
  7. AmigaOS 4.1 Update 6
  8. FUSE and NTFS-3G
  9. New development team members since AmiWest 2012

We also had a chance to have a team meeting on Friday night in one of the hotel rooms while at the show. We had the usual Airing of Grievances and a lengthy discussion on where we are going and how to get there. At one point we were interrupted by an outsider who likened the gathering to a secret Masons meeting.

If you would like to come to AmiWest 2014 and join in the fun then keep October 24, 25 and 26 open. There is also a programming seminar planned for October 23 and 24. See you there!

An SDK Update (finally)

blog_devIt has been a long time coming but we finally got around to releasing an updated Software Development Kit (SDK) for the Amiga Operating System. You can download it from Hyperion’s server.

This SDK includes all the usual includes and autodocs you need to use all the latest released AmigaOS features. The AmigaOS Documentation Wiki contains all the higher level information you need and will continue to be updated to help explain everything. The wiki also has a new Frequently Asked Questions section where we will post the most common problems and solutions.

This SDK is also a tad incomplete because I ran out of time to prepare it before AmiWest 2013. Therefore, there will be another SDK update or two sometime after the AmiWest show which will include even more.

We will also try harder to provide an updated SDK much more regularly from now on. Thanks to AmiUpdate we now have a way to deliver all sorts of SDK updates as needed with minimal effort.

Support for the SDK is available from the official AmigaOS support forum. You may also want to give OS4Coding a try if you get stuck on something.

Have fun!

HDAudio driver is complete!

blog_devI am happy to announce the release of the finished HDAudio driver for the AmigaOne X1000!

The driver now supports recording as well as playback. It also now supports S/PDIF optical output.

There have been questions about whether full “32 bit” audio really makes a difference. I’d like to dig a little deeper to better understand the technical specifications.

There are two primary factors that contribute to the quality of a digital sound recording. One is resolution, or how many bits per sample, and the other is sample rate, commonly 44100 or 48000 samples per second.

As you look at the waveform of a sound recording, these two numbers determine the vertical and horizontal resolution of the wave.

I’ll begin with the “bit width” or vertical resolution.

The original Amiga’s sound output supported four channels at eight bits of resolution. Eight bits means there are two hundred and fifty six possible vertical “steps” that can be used as the wave is generated. Now we spread those steps across a -2 volt to +2 volt span and we get 0.015625 volts per step.

At the time of the Amigas introduction, that was a pretty fair sound playback. But only 256 steps is not as “high fidelity” as we might like. As a comparison, Compact Disk Audio is reproduced at 16 bits per sample. This makes for a big improvement in resolution. 16 bits offers us 65536 possible “steps” to spread across the -2 volt to +2 volt range. Now the step size is 0.0000610351562 volts per “step” of vertical resolution. So 16 bit audio is a HUGE increase in accuracy.

Getting back to our driver, AHIPrefs offers both 16 Bit HiFi and 32 bit HiFi modes. But I’ll bet that neither of those modes gives exactly what you might expect. As AHI mixes lots of different sounds together, possibly each sound with it’s own volume and pan settings, it can be useful to have more resolution available to work with. Here’s the clue: ALL AHI modes that say “HiFi” are sending 32 bit data out to the sound device! The “16″ and “32″ only describe what goes IN to the AHI mix routines. if it says HiFi, you WILL get 32 bit output to your card!

Or will you? In truth, while AHI is making it’s calculations using 32 bit registers and 32 bit math, it only promises 24 bits of accuracy. Is this anything to be concerned about? Not at all. I’ll tell you why. 24 bit samples will resolve to a “step size” of 0.0000002384185 volts per step. Wow! That is about one quarter of a microvolt. Those with an electronics background can probably tell you, that attempts to accurately work at those levels are just ridiculous. We have reached an accuracy that is beyond the ability of our amplifiers and speakers to reproduce. Put simply, 24 bits is the reasonable limit of current technology, or at least affordable technology.

So our 32 bit samples are flying out of AHI and in to the HDAudio codec. While the ”container” is 32 bits wide, even the “high definition audio codec” that we have in the AmigaOne X1000 only resolves the top 24 bits. So it seems that in the end, both AHI and HDaudio agree that 24 bits is the reasonable limit for now.

And how about sample rate or the “horizontal” resolution?

How rapidly a sound is sampled and played back can also have a BIG impact on sound quality. It all starts with the Nyquist-Shannon sampling theorem or more commonly the Nyquist theorem. It’s pretty simple. As you record an audio signal, you must sample at at least twice the frequency of the highest pitch being recorded. Any sound that is higher than half the sampling frequency will be converted to noise and nasty noise at that.

So how high do we need? It is generally held that human hearing range is from 20 Hz (cycles per second) up to 20000 Hz. So any frequency above 40000 should be great right? Well Yes and No.

One simple problem is that we still must filter out all sound above half the sample frequency, and most frequency dependent volume controls (graphic equalizers) work with gradual slopes. There is no “hard cutoff” at a certain frequency, so we need a bit of headroom.

But there is another reason. As a high frequency sound approaches the Nyquist rate, we are only sampling about once per half-cycle. While this will reproduce the frequency of the original, it will do it at a bare minimum of accuracy. In other words, as frequencies get higher, they get less detail.

So what does it really matter?
Audio CDs play back at 44100 Hz. Not bad at all.
Television/DVD audio is usually at 48000 Hz. Nice.
With the HDAudio chip in the X1000 we support both of those frequencies.
We also support 88200, 96000, 176400, and 192000.
So we can double or quadruple the sample rates of common media!

At first, I really thought it was all a numbers game, but when developing the driver, I can actually hear the noise decrease noticeably as the playback rates went up!

And that is where I’ll leave off. This was enough of a lesson for one day. I am very happy that I could contribute to the completion of this driver. And the chance to “raise the bar” regarding sound capability was really very nice icing on the cake.

Like many of us, I have been using Amigas for a long time. Today, right here in front of me is an Amiga that supports high definition audio, a modern high performance video card. It uses standard, off the shelf keyboard, mouse, monitor and many USB accessories as well. Most of these we unheard of in the classic days. But with all the new and shiny, it is still AmigaOS to the core.
:)

New AmigaOS Core Developers

blog_devWe are pleased to announce that we have joined the AmigaOS development team. We hope that we are able to contribute some good things to AmigaOS using our skills in coding (Frank) and graphics (Thomas).

The follow is a short description of us and our products.

EntwicklerX:
We are currently working full time, self-employed, developing our games on multiple platforms (AmigaOS, Android, iOS, Windows Phone, Xbox Indies) as EntwicklerX. For about 10 years we have worked together on various software projects in our spare time. The focus in the last 5-6 years was to earn some money with the small bonus that it has allowed both of us to live from it (not enough for a Ferrari but enough to have fun at work). A strict separation between design and programming logic helped us build our products in an effective way with our limited time. While Frank takes care of programming, Thomas builds the graphics. Our subsystem is so sophisticated that Thomas can create and test Layouts without the help of Frank and Frank can use this directly in his code. This saves a lot of time and nerves. Before this, Frank had to compile every time if Thomas wanted to move a graphic a few pixels. ;)

AmiBoing Games

Our Amiga platform AmiBoing is used to bring an online connection to our games for high scores and achievements and it is also used for distributing our games. With more than 200 Users we can say this is the leading online gaming community on the Amiga platform. ;)

avatarImago_small

Thomas:
I care about what the user sees, how users interact with a game, paint graphics, create the levels and take care of our website. I have invested a lot of time into understanding how to create themes for AmigaOS and am still learning. The seamless design of an operating system is very important to me and I hope to play a part in this within AmigaOS.

avatarGoos_small

Frank:
I try to bring Thomas’ graphics to life and love to get the maximum out of AmigaOS using any available techniques to optimize (e.g. compositing). In our projects, I take care of all the programming. Together with Thomas, I am working on the game play and new game ideas. I can do my part in helping the Amiga in all areas of coding and to help current developers.

We are a Team:
Even with the split of responsibilities we will usually work as a team because ideas and their implementation always occur together. We look forward to working with the existing developers and also contributing to any interesting discussions. We will do our best but please note that we are only human and have a finite amount of time to work on everything. Give us time to understand how things work within the developer team. ;)

Best regards and let us say thank you for adding us to the list of AmigaOS core developers,
Thomas “imagodespira” Claus and Frank “Goos McGuile” Menzel.

Some Links:
EntwicklerX: www.entwickler-x.de
AmiBoing: www.amiboing.de
Themes: www.amiboing.de/themes.php

M.A.C.E

ThemeScreenshot

Delock PCI Express Sound Card supported

blog_miscAndreas Goiczyk has reported that the Delock PCI Express Sound Card 7.1 works well with the newly updated Envy24HT audio driver.

Thank you Andreas for letting us know!

If you discover a sound card not listed is supported by an AmigaOS audio driver, please use the contact form on the AmigaOS web site to let us know.

More Noise from ACube

blog_softwareThe VIA Envy24HT audio driver has been updated and now supports the VT1618 Codec. That means you can now use inexpensive PCIe audio cards such as the Syba SD-PEX63034 in your AmigaOne 500 and AmigaOne X1000 systems.

Here is a list of audio cards that are known to work with the Envy24HT audio driver:

  • Terratec Aureon 5.1 Sky
  • Terratec Aureon 7.1 Space
  • Terratec Phase22
  • Terratec Phase28
  • M-Audio Revolution 5.1
  • M-Audio Revolution 7.1
  • ESI Juli@
  • ESI Juli@ XTe
  • Speed Dragon EAU01A-1
  • Syba SD-PEX63034

If you happen to have audio card not on this list which also works with this driver please notify us via the AmigaOS contact form.

Special thanks to ACube Systems for helping to improve the Envy24HT driver.

The updated driver is being delivered to registered AmigaOS users using AmiUpdate. If you have any support issues with the driver please use the AmigaOS support forum for assistance.

Confessions of an Audioholic

blog_devThe HDAudio driver has recently been released to AmigaOne X1000 owners. This driver supports the built in “high definition audio” chip used in this computer.

I am the last coder to work on this driver, but like a relay race, much of the hard work was done before it was passed to me. Davy Wentzler, Alex Carmona, and René W. Olsen did a lot of the heavy lifting before I started on the project.

As far as I know, this is the first AmigaOS 4 driver to support the High Definition Audio standard. this is a new specification from Intel, destined to replace the older AC97 standard. This new standard includes lots of improved specifications in audio fidelity.

We can now play sound out the back and the front headphone at the same time. This has led to having “All” as an option when choosing an output.

It is possible to signal the software when a plug is inserted or removed. And it’s even possible to do a quick “impedance check” when a device is plugged in, and then make a good guess about whether it is a microphone (low level), stereo feed (line level) or the output from an MP3 player (higher level).

The HDAudio standard offers us a lot of new features that we will be exploring for a while to come.

The process of “bringing up” this driver included a few good challenges.

AHI reads a “modefile” that describes the basic features of the sound driver. It opens the driver and asks it to go looking for a matching sound card. If one is found, the driver / card is added to the system.. but when sound gets played it gets more interesting..

AHI specifies to the driver how many channels, how many bits per sample, and how rapidly the samples are about to start coming in. The driver needs to set up the sound chip for this, but it really NEVER talks directly to that chip! Instead it sets up the SB600 (Southbridge) with details about buffer sizes and all the other info that AHI just provided. It also builds up a “command buffer” for talking to the sound chip, and a “response buffer” that lets the chip answer. So we now have the southbridge set up to carry sound for us, and to also handle all our control communications with the sound chip as well.. Easy, right?

Imagine how overwhelmed I was on the first day of reading all this code!

704px-amiga_1000dp

Amiga 1000

Fortunately the ground work was well done already. I started by just testing the ability to send commands and get responses. Looking over the documents, I see a command to tell the chip to “beep” all by itself, without any audio data. That was the first success! Not too fancy, but it’s proof that we can talk to the sound chip. Alex Carmona picked up that code, and used it to make a “boot sound” for X1000 owners that sounds a LOT like the original Amiga 1000.

Next up, I separated the AHI part from the SB600/sound chip part. My thinking was that it’s easier to divide and conquer. Then I worked hard on opening the audio path to the sound chip. Before too long, I had noise, but it never sounded quite right. It turned out that the buffers feeding in to the sound chip had to be handled a bit differently. I’ll try to explain:

The normal way to feed a constant stream is called double-buffering. The idea is simple. While the audio chips are playing buffer A, I’ll be filling the next sounds into buffer B. Once the player moves into buffer B, I’ll fill more into A, and keep on going. Simple, right?

Of course it is never as easy as it sounds.. A bit of digging and I learned that instead of two separate buffers, the SB600 really wants one continuous block of memory! Simple enough, I’ll just get one big block, and draw an imaginary line halfway through it.

Now to keep things simple, I start by asking AHI what size it’s buffers will be, then I make the SB600 buffers the same size. Really one big buffer the size of BOTH AHI buffers combined.. but the sound wasn’t right yet. Keep digging.. AHI gets the buffer size it wants, the SB600 gets one big buffer, which looks to AHI like two buffers side-by-side.

Now it turns out that the sound chip has buffer size limits too, and they are a LOT smaller than any of the previous buffer sizes!

The final result is one big memory block for the SB600, split into two buffers, each sized to match what AHI wants, with each of those buffers split into as many smaller “segments” at or below the max size that can be handled by the sound chip. Wow. One block of memory divided up three different ways, depending on which way you look at it.

kiss-band

Not the KISS principle

I’ll mention here that I was looking for ANY way to make it simpler.. and all of this “memory geometry” would change with every change in sound settings! So the K.I.S.S. principle took over. I decided to configure everything AFTER AHI to ALWAYS run in 8 channel 32 bit quality. Running that way, I can easily “upsample” ANY sound format coming out of AHI to one stable format. If AHI sends me mono, I copy it to left and right, and zero the other six. If it sends stereo, the last six stay muted too. If it sends me 16 bit audio, I just shift it to the high word of the 32 bit samples.

Once all that buffer stuff was wrestled into submission, we finally got good sound coming out!! Success!!!

The modefile that came with the driver had only ONE mode. Not really a good way to show off such powerful audio chips. But the previous modefiles were created with tools that we don’t have, and I could find NO documentation.. So I got to spend a day or two studying the modefiles. Once I got a good idea of how they worked, I wrote a program called ”makemode” that converts a text file to a working modefile. If you need a tool, write it! This expanded our driver capability to as many modes as I choose to support (currently 3, including 7.1 audio). And as a side benefit, new modefiles can be created as quickly as they can be described. The sample rates have been increased as well. This chipset and driver support up to 192kHz, that’s about four times higher than the old “normal”.

The Beta test team has been a HUGE help in finding the little bugs that I missed. These last few versions have been pretty well behaved. If you are reading this then a public release must be “real soon”. We still have more to do, S/PDIF optical output and sound recording are still on the “to do” list. But the sound is playing, and that’s not a bad place to be today.

It has been a big team effort. Davy, Alex, René, the Beta team, and Steven for taking ENDLESS emails when I ran out of hair to pull out.

If you really read all the way to here, you get a special bonus tip: When you open SYS:Prefs/AHI to adjust the driver settings, you might try dragging the prefs window a LOT wider. The rear-panel connections for line out, line in, and microphone in are all described with the color of the correct connector listed. With six color coded jacks on the back, this might be helpful to get it into the right hole in one try. :)

Now that X1000 owners have an open PCI slot, what will be the most popular new “toy” to play with ?

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