o1i's Planet AROS

August 25, 2015

Icaros Desktop

Accessing the Tube!

In Italy we have a motto which says, once translated into "barely English", a single image worths a thousand words. That's why I can't really stop myself from sharing the following image with you: Yes, this basically means Deadwood has made the miracle and yes, you will be playing YouTube videos on Icaros Desktop starting with next update. No more scripts to download

by Paolo Besser (noreply@blogger.com) at August 25, 2015 01:57 PM

July 28, 2015


Hard drive tab..

Not working yes (buttons not yet activated), but at least displays the actual config.

Now if SourceForge would come back to life, I could commit all that stuff. This all will be a big commit, no chance to ever track the single changes..

by noreply@blogger.com (o1i) at July 28, 2015 02:45 PM

July 23, 2015


Happy birthday Amiga!

Happy 30th birthday, Amiga!

Your journey has started 30 years ago, on 23rd July 1985,
when the first Amiga 1000 was introduced to the clueless public at a clumsy, but epic event.
This journey is never ending, still going on after 30 years.

We love you.

by noreply@blogger.com (Álmos Rajnai) at July 23, 2015 07:48 AM

July 09, 2015



The Listtree class is .. not my friend ;-). But somehow with a lot of trial and error, I managed to get it working:

Well, the nice icons are missing (I tried to get icons working , but did I already say, Listtree is not my friend?), but it is close enough to WinUAE:

by noreply@blogger.com (o1i) at July 09, 2015 01:42 PM

May 12, 2015


Combo Boxes

WinUAE in Windows has nice comboboxes to select rom and adf images:

AROS only offers Cycle and String gadgets or listviews. None of the three can give you the functions of a combobox. I tried to work around it, but ended up with a lot of useless spent time, as those three can#t emulate all combobox features.

Even back in gtk-mui times, I wanted a combobox custom class, so now it was time to code one:

It even works with type-ahead ;-). There are still some minor bugs left, or some bugs in other parts of the gui were added during combobox development.

So there is still progress, but as always, time is much too limited to really progress fast.

PS: Forgot to mention, I moved my development environment to Debian/64bit, so from now on, x86_64/ABI_V1 is the primary target.

by noreply@blogger.com (o1i) at May 12, 2015 01:14 PM

May 01, 2015


Spin locks and the beauty of conditional instructions


Low-level toying with multiple CPUs without proper locking mechanisms is asking for trouble. I have already seen many cryptic boot logs form native AROS on RaspberryPi2 which you simply cannot decode. This happens every time when more than one core tries to speak over serial line.

The locking primitive which we have just added to AROS is a spin lock. It does not have an owner, so one cannot re-enter it — trying to do so will result in an endless loop with no exit. The spin lock can be obtained either for reading or for writing. When spin lock is in read mode, it can be acquired by many clients but as long as at least one of them is holding a read lock, code willing to switch it into write mode will have to wait. When spin lock is in write mode, it gives an exclusive access to not more nor less but only one caller. Until it is released again, no other code will be able to obtain the lock at all.

So, here it goes, the spin lock:

typedef struct {
    volatile unsigned long lock;
} spinlock_t;

#define SPINLOCK_INIT_WRITE_LOCKED  { 0x80000000 }

The spin lock comes with three default initializers for those who want to put it in some defined state into e.g. data section. The lock uses one 32-bit value which defines the state of lock:

  • lock == 0 – the lock is in its free state, everyone can lock it in either mode
  • lock > 0 – locked in READ mode. Everyone can lock it in READ state (up to 2^31 times, then it wraps), but attempting to lock it in WRITE mode will blocks until it is free.
  • lock == 0x80000000 – the lock is in WRITE mode. Further attempts to lock it in either modes will block.

The code for locking and unlocking uses the LDREX and STREX instructions which guarantee exclusive access to addressed memory. The code uses also a nice feature of ARM processors – conditional execution of instructions. Let’s look at the code – it assumes that register r0 points to the lock

    mov       r3, #0x80000000
1:  ldrex     r2, [r0]
    teq       r2, #0
    strexeq   r2, r3, [r0]
    teq       r2, #0
    bne       1b

Only one single loop inside. When the function finishes, the spin lock is acquired in WRITE mode. How does it work? The LDREX function reads the lock value into r2 register and marks exclusive access to addressed memory. The lock value is compared against zero. If the lock value was not zero, then the WFE instruction will be executed (please note the “ne” suffix). It puts the CPU into sleep mode until either an interrupt or an event from any other core is sent. If the lock value was zero, the WFE instruction is not executed at all. The next one is conditional variant of STREX. It is executed only if the lock value equals zero (spin lock is free, note the suffix “eq” after STREX). The STREX stores register r3 at address pointed by register r0. If write succeeds, i.e. exclusive lock was still granted, register r2 will be set to value 0, if write fails, r2 will contain value 1. Finally, register r2 is tested against value 0 and, if it’s not zero, we jump back and repeat.

Please note, that in second comparison r2 can contain one of three values:

  • 0, if STREXeq was executed and succeeded,
  • 1, if STREXeq was executed and filed,
  • 0x80000000, if the lock was already acquired and our CPU went to sleep (WFEne).

The last case means, that CPU has received either an event (from another CPU core when it released a spin lock) or an interrupt was triggered. In both cases the CPU will re-attempt to acquire the lock. It wakes up, STREXeq is not executed, 0x80000000 is compared against 0x00000000 and if they are not equal, CPU does a branch. Nice, isn’t it?

There is one more scenario to be considered. What happens if there was an interrupt triggered between LDREX and STREX? Well, in that case AROS code needs to release the exclusive memory by either issuing a CLREX instruction (ARM v7 cpus and up) or by issuing a dummy STREX instruction to some arbitrary memory location. In that case the interrupted code will re-attempt the process of obtaining a spin lock.

Now after the locks were added and properly used, you can turn this:

[KRN:ide27 modbces 08_dritpri fl #s veacion nam00:
0 (0147300 7ff0)
nif8 1or08# 1ls @ 0x50 "ex0c.
 iKRar C
e f81a03tr: p110 .2
 41N]expansi CPlib60ry01
 815f] Core105CP2 =600001bu
libra Cor
 80e f70: 100001
e @ 0e500c:ec00
0x0001889a 8RN]41o"er2 .library@
b3e10 C1 e41 Bootstrad t.re @ 0x0"
[d0c: or9 2 cpu1 ontek.reizurc12
+ KR1a1Ca8e 2 cp 01tx @ 0pr00e3eb0
08] 0fm2948_ini4_c1r 43

into this:

[KRN:BCM2708] Initialising Multicore System
[KRN:BCM2708] bcm2708_init: Copy SMP trampoline from f800074c to 00002000 (100 bytes)
[KRN:BCM2708] bcm2708_init: Patching data for trampoline at offset 80
[KRN:BCM2708] bcm2708_init: Attempting to wake core #1
[KRN:BCM2708] bcm2708_init: core #1 stack @ 0x000b4380 (sp=0x000dc370)
[KRN:BCM2708] bcm2708_init: core #1 fiq stack @ 0x000dc390 (sp=0x000dd380)
[KRN:BCM2708] bcm2708_init: core #1 tls @ 0x000dd3a0
[KRN] Core 1 Boostrapping..
[KRN] Core 1 CPSR=600001d3
[KRN] Core 1 CPSR=60000193
[KRN] Core 1 TLS @ 0x000dd3a0
[KRN] Core 1 KernelBase @ 0x000b3ec0
[KRN] Core 1 SysBase @ 0x000b3200
[KRN] Core 1 Bootstrap task @ 0x000dd3c0
[KRN] Core 1 cpu context size 2124
[KRN] Core 1 cpu ctx @ 0x000dd460
[KRN:BCM2708] bcm2708_init_core(1)
[KRN] Core 1 operational
[KRN] Core 1 waiting for interrupts
[KRN:BCM2708] bcm2708_init: Attempting to wake core #2

by michal at May 01, 2015 06:17 PM

April 27, 2015


All your nightly are belong to us

Yay, I’ve killed all nightly builds. Sorry 😉

That was the short version. Last weekend I was busy with removing some legal hacks from AROS sources. The hack on the schedule was commonly used ThisTask pointer in the SysBase. Now, at least in my local branch of AROS for RaspberryPi the SysBase->ThisTask points to a nirvana place where all code is either happy crashing, or dead, or both. ThisTask points to NULL :)

No, it didn’t disappeared completely. The ThisTask pointer has been moved (and is used there) to something similar to a thread local storage. It is local, but not local for a thread. It is local to a CPU core. On RPi2 we use four independent local storages and each of them has it’s own ThisTask pointer. Don’t hold your breath, it’s not SMP yet. Far from it :) The scheduler works only on the CPU#0. At least for now.

The TLS is used exclusively by the kernel.resource, which knows best about the low-level part of the system. Exec has become two new architecture-specific macros, named GET_THIS_TASK and SET_THIS_TASK(x). On all architectures they do expand to SysBase->ThisTask, on RaspberryPi they expand to TLS_GET(ThisTask) and equivalent TLS_SET. What about the rest of the AROS code? Well, in that case the only sane way to get ThisTask shall be used — the FindTask(NULL) call.

And here we come to the point where I’ve killed all nightlies. During my ThisTask removal fun I broke accidentally one macro in AROSTCP network stack :) It should be fixed already.

by michal at April 27, 2015 08:27 PM

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 😀


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