o1i's Planet AROS

April 21, 2015


Hello Core 1, hello Core 2, Core 3 – wake up!

Porting AROS to RaspberryPi is a lot of fun, I told that already. There’s also a lot of frustration and You know that. This time because of 4 CPU cores…

From very beginning I have noticed that the speed of frame buffer was relatively slow. At least not as fast as I would expect form a nearly 1 GHz machine. Well, issue there, ignored first. I followed with AROS porting and came to a point where AROS was booting into desktop and running programs. As a simple example I have added Clock to WBStartup folder, thus making this app start automatically once the system is up. Of course I have had full debug enabled in screen console and over serial port.

Huh, it took AROS nearly 30 seconds to boot. Not bad, but could be better for sure. Slow redrawing od the screen was worrying me but hey, we do have the simplest graphics driver ever. No acceleration, just a simple portion of memory filled pixel by pixel (with some help of our base graphics class of course). So far so good.


Then out of curiosity I decided to take a look at an old raspberry pi model I have on my desktop. I booted it and looked on the Clock and gone mad. Old raspberry pi with arm11 CPU booted in about 20 seconds. 2/3 of RaspberryPi2 speed! Can’t be, I thought. The new machine cannot be that bad, can it? Have I missed some cache setup? Frame buffer can’t be cached, right? Why was linux frame buffer console faster?

Finally I found a forum where Bare Metal guys were discussing their great efforts to develop standalone software for RaspberryPi. Luckily for me one of them had similar issue I had. He also led me to the final solution. It turned out, that the CPU cores of RaspberryPi2 are not silently seeping and waiting for an interrupt when start.elf transfers the control over to the ARM cpu. No, instead they are busy looping and polling the registers, anxiously waiting to start and do some useful work. As you can imagine polling technique is not something very effective, it’s rather the contrary. The additional CPU cores were stealing the precious bus cycles, leaving less for the CPU#0 which was actually running AROS code. Eureka!

There are two solutions and I have found both of them working with AROS. The first one is to extend the config.txt file (the file which is read and parsed by VideoCore). There, one has to add following parameter


It forces the additional CPUs to go sleep and wait for interrupts instead of do busy looping. I tested it and it really helped. After adding that line AROS really flies on that tiny computer! Frame buffer refreshes quickly, display redraws quickly, few demos redraw their windows nearly immediately. Boo! Now the machine not only feels faster than old RPi, it actually is faster.

Letting the additional CPUs to sleep alone is good, but not something I liked very much. Sure, start.elf does good job but I wanted to make AROS do that job. So I started to code :) I wrote small assembly routine, a trampoline which initializes caches and MMU of the woken up core. The trampoline initializes also the supervisor stack and jumps to a routine in C code. At the moment the C routine is rather simple. It checks CPU type, enables VFP and enters endless wait-for-interrupt loop. Ah, the C routine babbles on the system log of course to let me know it is actually working. What I got was:

[KRN] Co]e o Co eUp ani idiwir igr rrutatuots

Uh. Not very readable. Forgot something? Ah yes, there is no locking in our bug() function, which means all cores were fighting on the serial line. Proper locking will come later, since it has to be done right, for now I have only added some delays. This is how it looks now

Bildschirmfoto 2015-04-21 um 21.53.40

Please note that the “Core x up and waiting” lines are sent to the console respectively by different ARM cores. It’s not SMP, not even AMP. It’s just small initialization routine. But at least it work as expected…

And with current setup AROS really flies on the RaspberryPi 2 :-D


by michal at April 21, 2015 08:50 PM

April 18, 2015


Raspberry Pi

Eons ago I was involved in several ARM-related projects. One of them was to make a linux-hosted port of AROS for ARM devices. These were the days full of fun and joy (if everything worked well) and frustration (if everything failed). After that my engagement in AROS dropped nearly to zero. There were, of course, some exceptions like improvements in memory management (TLSF support) or improvements in x86_64 AROS. But none of them were as low-level as I wished them to be.

Since at work we started to use some ARM-based embedded machines for our electronics, I had some fun with coding them. Not really low level, but weird enough :) This all drove me to an idea of buying an ARM platform and make native AROS for it.

IMG_3049 Kopie

Even if there are better machines available, I have decided to support RaspberryPi. One of the reasons was availability of the rPi code in AROS repository – our great developer Nick Andrews has started a port of Aros for that machines already and made a great progress with it. Another reason, a very important one, is a huge community behind Raspberry.

So, the board, the RaspberryPi 2, has been bought :)


During last weeks me and Nick had fun with bringing AROS port back into usable state, rewriting it and improving in many places. Code which was initially not working with rPi2 boards at all now boots equally good (or equally bad) on both rPi and rPi2 into Wanderer, the desktop environment of AROS. The kernel of our system is loaded at a virtual address 0xf8000000. The read-only portion of the kernel is MMU-protected again writes. All caches and write buffers are enabled. Slowly all bits and pieces are improved and we are doing our best to get USB on-the-go up and running. Having it would allow us to actually use Aros on these nice machines already.

Meanwhile, I’m completing our small EABI library for ARM cpus so that we could build entire AROS with gcc5 compiler. Well, fun :)

by michal at April 18, 2015 10:11 PM

April 17, 2015

Icaros Desktop

Your Icaros HTTP server

Icaros Desktop has 'hidden' a little treasure for years, called Snug. Made by the same author of Yafs, the beloved FTP server which allows us sharing files from the AROS machine to the local network, Snug is a lovely HTTP server which does exactly what is meant for: publishing (simple) web pages and allow browsing into directories thorugh a web browser (like Internet Explorer, Chrome or Firefox

by Paolo Besser (noreply@blogger.com) at April 17, 2015 03:21 PM

April 15, 2015

Icaros Desktop

Adding submenus to initial GRUB boot menu

Works on Icaros 2.0.4 are going on, even if I recently forgot to add any status update on this page. So I decided to write a little tutorial about a nice customization I'm adding to the distribution. Unluckily, only whoever will install v2.0.4 from scratch (Live! or Light versions) will see that, while users of current editions will need to manually make some modifications to a single text file

by Paolo Besser (noreply@blogger.com) at April 15, 2015 05:17 PM

April 10, 2015



Over two years passed since last entry on this page — two years only but it feels like eons. I think it’s time to reactivate this blog :)


So, reboot…

by michal at April 10, 2015 02:50 PM

April 05, 2015


A lua shell for FS-UAE

While FS-UAE recently added a scripting interface with a Lua scripting binding, it only provides capabilities to write scripts with hooks that will be called on certain emulator events. I  hacked this scripting interface and added a Lua remote shell. With this shell you can connect while the emulator is running and issue commands. I also started to add disk image related functions to the Lua binding. With these features combined I could show off the power of a scripting shell by writing a tool to insert floppy and cd-rom disk images while the emulator is running – a long awaited and missing feature…

1. Build FS-UAE with the lua shell

The lua shell is for now only available as a source code patch and you need to compile a fresh FS-UAE to use it. But that is not too difficult:

The code is hosted on the lua branch in my github repository:


I also submitted the patch as a pull request for the main line FS-UAE  and hope that Frode will like this feature and include it :)

Clone this branch and start the compilation with the following options:

$ ./bootstrap
$ mkdir build
$ cd build
$ ../configure --enable-lua

Now you can compile it:

$ make
$ (cd dist/macosx && make)  # only on Mac OS X

This results in a new FS-UAE binary with lua shell support.

2. Configure and First Start

You have to enable the lua shell in order to use it.

Either add an option to one of your .fs-uae config files:

lua_shell = 1

or give the option on the command line:

fs-uae ... --lua_shell=1

The lua shell opens a TCP/IP socket on localhost port 6800 and waits for incoming client connects e.g. via telnet or putty.

You can use the following options to change these settings:

lua_shell_addr = "localhost"
lua_shell_port = 6800

Now launch FS-UAE with the lua shell option enabled and have a look at the log files. They usually reside in Documents/FS-UAE/Cache/Logs/fs-uae.log.txt.

There watch out for messages starting with lua-shell:

$ grep lua-shell ~/Documents/FS-UAE/Cache/Logs/fs-uae.log.txt
lua-shell: addr=, port=6800
lua-shell: +listener: 20
lua-shell: -listener
lua-shell: stopping done...

If you see these messages you should be able to connect while the emulator is running:

$ telnet 6800
Connected to localhost.
Escape character is '^]'.
FS-UAE 2.5.29dev Lua 5.2

Ok. Now lets see what you can do in the shell…

3. Using the shell

The lua shell is very similar to the interactive lua interpreter that is shipped with lots of lua distributions (see doc). You can enter a valid lua statement that is then evaluated in the current lua state:

> print "hello, world!"
hello, world!

Note, that the print command is redirected to your shell. Any return value is not printed automatically, you need to prepend a = (or return) before you can enter an expression:

> =2+3

Next to most libs that lua already ships the lua shell in FS-UAE also registers special emulator commands for you (see next section for details):

> =fsuae.floppy.get_num_drives()

This returns the number of virtual floppy drives that are currently emulated.

If you want to quit the shell then enter the quit() command:

> quit()

You can also simply disconnect the connection by closing with telnet or putty…

3. FS-UAE Lua commands

Currently, the following modules are defined with commands:

  • fsemu – generic emulator commands e.g. for changing display
  • fsuae – commands available in the FS-UAE adaption layer of UAE
  • uae – core Amiga emulator commands, e.g. read Amiga memory

Each module is defined in a lua table with the same name and is thus accessed with this prefix. For an up to date list of commands have a look at the corresponding source files:

  • fsemu in libfsemu/src/emu/emu_lua.c
  • fsuae in src/fs-uae/lualibfsuae.c
  • uae in src/lualibuae.cpp

In this post I’ll focus on the drive image functions I’ve added:

  return: the number of floppy drives currently active
fsuae.floppy.set_file(num, path)
  num: index of floppy 0..3
  path: file path of drive image (e.g. adf file)
  return: -
  num: index of floppy 0..3
  return: file path of current drive image or empty string

The same functions are also available for CD-ROM images: just replace floppy with cdrom in the above commands…

Now you can insert and eject floppy images when you run a lua shell during FS-UAE’s operation:

> fsuae.floppy.set_file(0, "/path/to/my/test.adf")  -- insert image into DF0
> fsuae.floppy.set_file(0, "") -- eject image in DF0

You are now able to control your floppies interactively via shell, but there is more…

4. fs-uae-ctl Command Line Utility

You can also write utility programs that use the shell to communicate with FS-UAE while its running.

fs-uae-ctl found in the new tools directory of the FS-UAE source tree is a small Python 3.x tool that allows to manage the floppy and CD-ROM images via command line:

$ python3 fs-uae-ctl df0 # return the current image attached to DF0
df0 empty
$ python3 fs-uae-ctl df0 /path/to/my/test.adf # insert new image
$ python3 fs-uae-ctl df0 eject # remove current image

Use df1 to df3 to access the other drives (if they are enabled).

Use cd0 to cd3 to access the CD-ROM images.

Some extra options allow you to change the host or port where to find the lua shell. Example:

... --port 6811 --host my.host.ip

5. fs-uae-ctl-ui GUI Image Changer Utility

Of course you could do more fancy and write a GUI based utility. Here it is: fs-uae-ctl-ui also found in tools. It requires PyQt4, so make sure it is installed in your Python 3.x setup. E.g. by installing package python3-pyqt4 on a Ubuntu/Debian Linux system. Mac OS X MaxPorts user install port py34-pyqt4.

If you run the tool, you’ll see a nice image change window:

fs-uae-ctl-ui: FS-UAE Image Changer Utility

fs-uae-ctl-ui: FS-UAE Image Changer Utility

Usage is really simply:

First press button Connect to connect with the running FS-UAE lua shell. If all went well then the enabled drives are also enabled in the UI window. See the status line at the bottom for error messages if any.

On an enabled drive slot you can insert a new disk image by entering a new path name into the edit box. If you press button then a file selector will be opened and allows you to choose a new image to be inserted. Pressing the button with the Eject Symbol ejects the image in the drive slot…

There is also a tab for CD-ROMs with the same feature set.

6. Dev Tools and more…

Both fs-uae-ctl utilities use a common Python 3 library that is also shipped. It allows you to integrate lua shell access to FS-UAE with a few lines of python code and also provides some classes that wrap the floppy and CD-ROM image functions… A high level Emu class wraps everything together:

import fsuae
emu = fsuae.Emu()
if not emu.connect():
  print("ERROR", emu.getError())
  print("Drives", emu.getNumDrives())

So writing your own tool is not really an issue…

And user jbl007 of the English Amiga Board already picked up the idea while discussing the lua shell (see EAB Thread) and created his own tool that offers the image control in a very compact menu attached to the systray icon of FS-UAE! See his GitHub Repo:


His launcher fs-uae.py does all the magic…

(BTW: jbl007 has also written a very nice command line frontend for FS-UE called amiga that allows to run FS-UAE for some standard Amiga models without editing a fs-uae config file. It creates the necessary file automatically during startup…)

That’s it… I hope you enjoy the new lua shell for FS-UAE and if you find new interesting uses of it then drop a comment or join the discussion on EAB…

by lallafa at April 05, 2015 05:49 PM

April 02, 2015


AEROS Plus beta avaiable for Raspberry Pi 1 and 2


in case you missed the news:
AEROS beta 9 for Raspberry Pi1 and 2 is available for registered users
at www.aeros-os.org

April 02, 2015 10:21 PM

March 25, 2015


Sliding ..

WinUAE has some nice slider gadgets ("msctls_trackbar32"), which are now available in the AROS port, too:

So the CPU dialog is the most complete one, all gadgets are working as expected.

Ok, not much news, but as the blogger scene is not very active for AROS (at the moment?), I wanted to give you something to read ;-).

by noreply@blogger.com (o1i) at March 25, 2015 03:31 PM

March 18, 2015


Virtual filesystems ... done.

So after quite some silence (and a lot of business trips and other stuff, which kept me away from AROS), I'll post an update for you ;):

From time to time I found a few free minutes, so I could implement all the missing virtual filesystem pieces step by step.

Basically you need to catch all m68k filesystem packets and call the according functions on the guest system. Now AROS as a host is a special case, because the native host filesystem supports the same features as the guest filesystem. The WinUAE problem, that the underlying windows filesystem eventually supports no comments, does not exist on AROS. So the best solution would have been to remove this middle ware completely, but I'll postpone that for a later time.

Nevertheless, now it works. It even works fast enough, the filesystem tasks expects to run in a higher priority than the main uae task. Not only on AROS, even on Windows WinUAE raises the priority. Strange for someone, who is used to Unix schedulers only..

So now, what's next? No idea ;). So back to the gui:
I implemented BS_AUTORADIOBUTTON controls, so that with Windows-native-looking calls to the Windows API the unmodified WinUAE code can interact with the native Zune GUI. Yeah, I know, sounds like gtk-mui. But as I hate gui logic coding and everybody would scream "I like the WinUAE gui more!" anyways, the WinUAE GUI it will be (just with Zune gadgets).

And finally, when you now select a CPU in the gui and start uae, the cpu is really set to the right model and your Amiga boots in the right configuration :-).

by noreply@blogger.com (o1i) at March 18, 2015 03:29 PM

March 13, 2015


New Subversion Server for AROS

The Subversion repository with the source code of AROS has found a new home on a server which is maintained by Neil Cafferkey und Staf Verhaegen. Since the URL didn't change existing working copies can furthermore be used.

That should solve the problem that in the past it took weeks to get an account. The new procedure for getting an account is here.

March 13, 2015 01:45 AM

February 23, 2015


First boot from virtual filesystem!

After implementing some more functions and some debugging, I am now able to boot from a virtual filesystem. All AmigaOS files are stored in a linux-native filesystem and mounted inside uae for AmigaOS to use:
It is still *slow*. I don't know if this is because of the missing jit, the many debug log messages or any other issues, but hey, it at least works so far :)!

Config file used contains:

by noreply@blogger.com (o1i) at February 23, 2015 05:02 PM

February 18, 2015


Getting closer ..

Still no contents, but at least no hang anymore..

by noreply@blogger.com (o1i) at February 18, 2015 10:34 AM

February 10, 2015


Getting close..

Filesystems in uae are very dependent on interprocess-communication. While I really thought, I got this covered and right, somehow all those semaphores always got jammed somehow, resulting in a hang, as soon as the first AmigaOS filesystem packet reached the emulation code. AROS semaphores are just different than Windows Events, which have quite some more possibilities. So I had a look at fs-uae (isn't open source nice?) and found out, that obviously they had to struggle, too, as they provide glib, pthreads and sdl semaphore based uae implementations. So, we have SDL (and pthreads), too, so why not just use that code:
Not perfect, still hangs, but at least I now can see the workbench icon of my virtual work drive. This proves, that the problem was in the semaphore code, as with my own implementation, I got a hang much earlier. Did I say, I have not much time at the moment? But this nags on my mind, so I *have* to do it.

by noreply@blogger.com (o1i) at February 10, 2015 10:42 AM

February 04, 2015


Small steps..

Currently I don't have much time to work on WinUAE, but I tried to get the virtual filesystems working:
It shows up in the early boot sequence, but it does not work later on. It's a first step at least..

by noreply@blogger.com (o1i) at February 04, 2015 11:06 AM

January 30, 2015


Icaros Desktop 2.0.3 now available

A new version of Icaros Desktop is now available for download. It refreshes AROS files to current ABIv0 nightly builds and fixes themes and locale files, which were broken in v2.0.2. It also introduces a couple of nice new features, like italian translation for DirectoryOpus 5 and YouTube Center script, which allows users to download videos from YouTube with OWB, in a very customizable fashion.

For info and downloads, please visit
http://vmwaros.blogspot.it/2015/01/ic ... 03-now-available-for.html

January 30, 2015 09:13 PM