Tag Archives: AmigaOS

First steps towards beta test :D

firstStepsA1222Install

The universe is expanding!

https://www.youtube.com/watch?v=fMSvxQIfq2w

Getting there …

Registration Cards for X5000 pre-release

AmigaOS and the Console Development – Part 2

blog_devPart 2 – The Great Console Rewrite

The 68K assembler version of the console had a peculiar architecture. When the console was opened, it allocated display memory 50% bigger than the size of the window (in those days the console had to be passed the address of an existing window when you opened it). That memory was divided up into a character map, Width by Height bytes, and a similar sized array of character attributes. The addressing of the array was really strange and I think it might have been translated into 68K assembler from BCPL.

The new console had to include:
1) A ReAction window and gadgets;
2) History and display scrolling;
3) Multiple windows (tabbed);
4) Menu;
5) Prefs Settings.

As I mentioned last time, the fixed array size made it impossible to add history features to the architecture. Also, any operation such as an insertion, deletion, window resize or refresh was implemented by unpacking the whole character map and repacking it again. It was designed for a particular architecture and was not adaptable. We decided to use a linked list for the display rows, so that rows could be added or deleted at any time without having to repack a large array. The rows were then allocated and returned to a memory Pool for speed. The independence of the rows made it easy to keep a few pointers to the list, such as “History Start”, “Display Start”, “Display End” and “History End”. Most list operations were simplified by this approach and scrolling speed seemed to be adequate.

The ReAction Window and Gadgets

The old console window was opened by the con-handler and its address passed to the console device. That meant that one program (the con-handler) opened and “owned” the window, but another (the console device) performed all the work on it. That had to change if we were ever going to support memory protection. In any case, it made sense that the program that used the window, opened and closed it also. One of the first changes was that the console device would from now on open and maintain its own window (of course, it still had to accept the address of an existing window passed to it by an old program).

Once the console could open its own window, it could make it a ReAction window with Iconify, Scroll and ClickTab gadgets. If it was passed the address of an existing window, then none of the “extras” could be added since the calling program might have added its own extras, so only “new-style” windows have all the extra gadgets. Now you no longer have to close the Shell when you change Workbench GUI settings!
Most of the gadgets can be independently enabled or disabled by options in the Shell tooltypes.

History and Display Scrolling

One feature of the old design was that a long row could overlap the edge of the display window and “wrap around” onto the next row. You’ve all seen what happens when you make a Shell window narrower – the long rows split into two or more and the text occupies more rows on the screen. To implement this feature with the linked list, we ended up creating “multiple rows” that consisted of two or more rows of text on the screen, but linked, each one to the others on each side. What is more, the new console display had to be able to scroll text on and off top and bottom of the window. The window might even have been resized since the old text was scrolled off the edge, so we had to accommodate changes in window width as old rows of text were scrolled back into view. A lot of work has gone into the treatment of “long lines”!

The current history, consisting of the contents of the linked list of lines, is stored in RAM. In order to save memory, we allow old history to be written out to a disk file once the number of lines of stored text reaches a predetermined limit. You can specify how many lines of text you want to keep in RAM, and what to do once that overflows (e.g. keep it in a disk file or discard it). You can also elect to save the whole Shell session to a file if you wish.

Scrolling the history is easy, you can use the mouse wheel, the scroll bar gadget or built-in keystrokes. If you have selected to write old history to backup files when the current buffer is full, you can even scroll back through the history that has been written to the file. As you do, that history is read back into the current buffer, making it exceed the size limit temporarily. If you like, you can display the number of lines of history in the window title.

Multiple Windows (Tabbed)

Adding a ClickTab gadget to the window makes it possible to switch the display between any one of two or more actual Shells. All Shells share the same window geometry and gadgets, but each has its own independent history and text attributes. You could have one Shell displayed in black on white, another in white on black and others in any combinations you like. When you switch from one Shell to another, the new one is displayed in its own colours and style. You can choose the text to be shown on each tab (you might like to have the current directory, for instance).

From one Shell, you can open a new one by selecting a menu item or a built-in keystroke. The new Shell is a clone of the previous one, that is, it “has” the same current directory, local variables, and so on. However, it is opened using the same “Shell-Startup” file as all the other Shells, so if your Shell-Startup file includes a line like “cd RAM:”, all new Shells will open with RAM: as the current directory.

You can close any Shell individually, or even all at once.

shell-clicktab

Menu

The menu accumulates all the key short-cuts (apart from those for command-line editing) and lets you select or edit settings as you wish. You can also call up the console Help file from the window. The Help file contains all the user documentation for the Shell, the con-handler and the console device. Most of the menu operations can also be performed by built-in keystrokes.

shell-console-prefs

Prefs Settings

There is a Preferences Editor for the console settings. These are the default settings for the console and can be changed by the tooltypes in the Shell icon or the program running in the Shell window. You can also call the prefs editor from within the console window and “Use” the changes temporarily if you wish.

Appearance

You can select the font for the console text (fixed-width fonts only). You can also choose from a plain old “block” cursor, an underline or a vertical bar. You can make the cursor blink if you like.

Text Colours

The “old” console was pretty restricted in its choice of text and background colours. You could use the ANSI escape sequences to set colours, but you could only choose from the system Pens. In the new console, we have introduced a palette of colours from which you can choose your text foreground and background colours. There are four palettes available to the user – you can select your preferred palette from the Preferences editor. The four palettes are the old System Pens, an ANSI set of primary colours, an ANSI set of “faint” colours and a “user” set which you can choose to your own preferences.

shell-console-colours

Text Attributes

The new console supports a few new text attributes, like italics, strike-through and character blink. Italics are spaced out slightly so that they don’t overlap with non-italic characters. The console does not attempt to support proportional fonts.

shell-console-attrs

Name-Completion

Name completion strictly is a function of the con-handler, not the console, but it appears in the console window. You can now choose to have name-completion choices displayed in a “popup” window close to where you are typing. You can then choose from the displayed list. If you choose to see completion “in-line”, you can choose if or when you want the system to beep at you (if there are no matches, multiple matches, or “this is the last match”).

Another con-handler setting in the console prefs is the size of the command input buffer. The old console was fixed at 1024 characters, but now you can leave it at 16 kB or set it to anything up to 1 MB.

You can also change the default Tab spacing (Horizontal Tabs, not ClickTab) from its default eight spaces to two, or eleven, or any value between two and sixteen.

Compatibility with Older Programs

The new console works in either its “legacy” style or its “new” style, depending on how it is opened. While testing it, we have discovered several older applications that depended on unspecified console behaviour or even, in some cases, bugs in the old console.

We have tried to keep the new console compatible with the old, but inevitably there will be programs “out there” that will behave differently. Let us know and we will see what we can do.

New applications can use the newer console features and make the most of them.

Programmer Information

All the above description is user information, of course. The AmigaOS SDK contains the full documentation of the new console API. The AmigaOS Documentation Wiki has also been updated with new information about the improved Shell.

Well, that’s it for now. I hope you enjoy the benefits of the new Shell.

AmigaOS and the Console Development – Part 1

blog_devPart 1 – The Ascent from Assembler to C

It was late in 2003 when I received my first AmigaOne-XE. At that time, like many others, I had to be content to use Linux, and I waited impatiently for the day when I could run AmigaOS on my new machine. In the meantime I built the Boing Ball “case” for it. [The XE board failed in 2014 after eleven years of faithful service. These days the Boing Case is occupied by the AmigaOne X5000]

Early in 2004 I was invited to become a beta tester and had the good fortune to be able to run the 68K version of AmigaOS 4 on my A4000. At that stage most of the old AmigaOS software had been modified (where necessary) to compile with GCC, and the developers were mainly using cross-compilers running under Linux or Windows. Many of the system components, originally written in 68K assembler, had already been rewritten in C or translated to C. Only a couple of months later, the first PPC versions of the system components were released to beta testers and 68K versions were dropped, one by one. Only a handful of third-party components remained in 68K, those for which we had binary licenses only (e.g. ARexx).

During a discussion on the beta tester mailing list one day, one of the developers mentioned that only the console device remained to be translated/rewritten in C. Foolishly I waved my hand in the air and said something like “I’d like to have a go at that!”. Well, I had been an assembly-language programmer for probably thirty years and a C programmer for probably twenty, so I thought it might be fun.

You can imagine my excitement when, some weeks later, an archive arrived in my inbox. It was the assembler sources for the console device, all 26 source files and about half a dozen header files. Where was I going to start? I couldn’t just translate the whole thing in one pass, then sit down and attempt to debug it. I had to be able to switch back and forth between assembler originals and C translations, or I would never be able to even make it run, let alone debug it.

SAS01I decided to use SAS/C, the 68K compiler/assembler package that I had been using for years. Like many other packages, it allows you to mix C and assembler modules freely in the build. I could translate each assembler source file in turn, and with some stubs, call the assembler functions from C or the C functions from assembler. That way I would be able to switch individual modules back and forth between C and assembler at any time. I started by compiling the source on my trusty old A4000, since the A1-XE was by now the beta test machine and the A4000 was the stable development platform. Later, the native AmigaOS 4 version of GCC was released and I was able to compile and build on the A1-XE (it was a bit faster than the A4000, even with its 68060/50 processor!).

Well, the translating job took about nine months. I took each assembler source file and commented out the assembler statements, writing in the C version underneath. Of course, this approach made each source file huge, but it would prove to be a boon later when I was debugging, since I could see the original side by side with my translation. During that time I had to break up some of the assembler source files into smaller modules, just to keep them a reasonable size. I finished up with some 30 C source files.

Here is an extract of part of a translation:

//    lea    cd_RastPort(a6),a1
//    move.b    cu_Mask(a2),rp_Mask(a1)
IGraphics->SetWriteMask(rastPtr, unit->cu_Mask);

//    moveq    #0,d0
//    move.b    d6,d0
//    LINKGFX    SetDrMd
IGraphics->SetDrMd(rastPtr, oldMode);

You can see that the original five lines of assembler have become two lines of C.

The makefile was huge, with half of it commented out at any one time. The SAS/C suite produced 68K code, but from a mixture of C and assembler sources. At first it was all compiled on the A4000, but later I swung everything over to the A1-XE and made that my new development platform.

As the development progressed, there were fewer assembler sources and more C sources, until the first pure-C version was released to the beta testers in May 2005. That version was still compiled by SAS/C and distributed as a 68K binary. There were several more months of debugging and testing, until the pure C sources were compiled into native PPC for the first time in August 2005. At about the same time, the C sources were stripped of the original assembler code and we had a working console device, written in C and compiled in pure PPC. We tested it to destruction and cleared the bugs before it was finally released to the world. Most of the bugs were inconsistencies with the old 68K version, caused by mis-translation or errors in understanding. It had taken a year to translate and debug, but it was a great satisfaction.

The original 68K assembler version of the console occupied 16,212 bytes. Compare that with the last 68K C version (V50.26) which was 42,564 bytes! It just shows how squashed the assembler version was (but that C version did have some debug code as well).

The translated console had several drawbacks. Because the original had been written in assembler, it was very difficult to read and maintain and there were a number of known “features” that were just too hard to fix. Also, the assembler version had been written to minimise code size, rather than to optimise speed or code legibility. There were many tricks employed within the assembler code to save a few bytes of space in the Kickstart ROM. For instance, it was common to arrange several byte-sized variables adjacently in the data area so that four variables could be picked up at once with a long word fetch. Not recognising these tricks was the cause of many a bug in the early days! Also a lot of the ANSI code had been not implemented in order to save space.

Not the least of the drawbacks was that the memory allocated for the display was fixed when the window was opened, and lines of text that scrolled off the top or bottom of the display were scrubbed clean and re-introduced at the other end. It was just not possible to save the scrolled lines to keep the display history. To add a scroll bar and history would need a big rethink of the architecture.

Next time: the Great Console Rewrite.

AmigaOS 4.1 Final Edition SDK now available

blog_devThe AmigaOS 4.1 Final Edition SDK is now available for download from Hyperion’s web site. The official press release can be found at http://www.hyperion-entertainment.biz/

This is a significant update to the SDK which will require a lot of developer support to use properly. New articles have already began to appear on the AmigaOS Development Wiki like Intuition’s new Menu Class article.

We are also planning tutorials and a workshop at the Amiga DevCon 2015 which is before the AmiWest 2015 show in Sacramento, California, USA starting October 15th.

Steven Solie
AmigaOS Development Team Lead

AmiWest 2014 Programming Jam

blog_devWe are extremely pleased to be able to host the 3rd incarnation of the AmiWest Programming Seminar. This is a unique event in the AmiVerse, to bring together Amiga developers, programmers and users to learn from each other and create apps.

In previous years we have taken a more formal approach with seminars and fixed topics. Given the wide range of programming experience on the part of participants, we will try a more free-form approach this year.

To read more and get more information, check out this link:

http://www.amiwest.net/aosps/

Here’s the sign up form:

http://www.amiwest.net/survey/index.php/816728/lang-en

Paul Sadlik
AmiWest Programming Jam Organizer

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.

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!

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.