In principle the ARM AROS freepascal works very nicely, but some of the LCL programs does crash, especially EdiSyn and Mapparium have this problem. I try to debug it, its strange that it only appears on ARM (i386, PowerPC, m68k no problem at this point). It seems that it is a classical use after free, but the source seems to be right. I need to check if this also happen on the other platforms and only work by random. Or ARM has special properties which bring this error. With some tricks I come around this problem and got EdiSyn and Mapparium to work. Both work well on RasPi AROS but still crash on exit so I guess there are more problems inside.
EdiSyn and Mapparium on ARM-AROS
Tried a little bit more the ZuPaPlayer on ARM, seems the Zune on ARM is not on the same status as i386. A List event fired on i386, seems never fire on ARM, which makes it impossible to move songs in the list. Because I compiled the libmikmod myself, I increased the buffer for the AHI mikmod module (on i386 AROS I had some stutter problems). It works but now the pause button needs nearly 500 ms before it really stops. Not so nice, so I edited the AHI driver again a little bit and calculate the Buffersize dynamically from the frequency to cover 120 ms (got the idea from the Windows driver). Works rather nicely. So I made a release for ARM-AROS of ZuPaPlayer 0.2
Download: ZuPaPlayer 0.2 for arm-aros
I tried some linking to AROS C Linklibs on ARM-AROS and the basic example with sqlite3 works rather nicely. But more interesting for me would be the mikmod lib because then I could compile ZuPaPlayer for my RasPi.
The main problem is the Libmikmod is not available for arm as binary. But I found the source a while ago. I tried to compile directly on the ARM-AROS and it works. And I was also amazed that also my ZuPaPlayer compiles without much changes… and you would not believe ZuPaPlayer even plays the sounds without any problems 🙂
ZuPaPlayer on arm-AROS
Very nice, my Raspi has a touchscreen, so now I can use my Raspi as nice little Mod Player 😉
Compiled some programs for ARM AROS, most work, but some also do not work, with a rather strange error message. First I will add my new startup code to official repository, then I will try to debug this problem.
Games on ARM AROS
Download for arm-aros:
FPCMines – A Mines clone
ColorIt – Fill field with one color
APict – Simple Image Viewer
Working on the startupcode, added option to alloc a new Stack if the freepascal needed stack is bigger than the stack supplied by AROS. (which is mostly the case, AROS delivers 40k stack, FPC wants 256k). It works, even not completely finished. It’s my first bigger project with arm assembler better let someone check with more arm assembler knowledge 😉
I tried also LCL on arm, but it did not work, the Handlemessage inside MUI/Zune makes the problem. When I checked on the Structures involved. I noticed that on AROS there are two different structures, one for BINCOMPAT mode one without this define. Until now the BINCOMPAT was only needed for m68k, but there is no special m68k-aros but only m68k-amiga and the x64-aros does not work well because AROS on x64 is near to not usable.
The define AROS_FLAVOUR_BINCOMPAT is now defined as default for arm-aros and it seems to work. Compiled the FPCMines as first try and it is working well.
FPCMines on ARM AROS
I uploaded the arm-aros basic implementation to freepascal trunk, ChainQ added syscalls for arm and some other things to make freepascal on ARM possible.
So finally the compiler works as expected, even the fp-ide works now.
FP-IDE on ARM AROS
If someone want to try it: Freepascal for arm-aros with FP-IDE
I found the reason for the crash inside SysInitFPU, it seems it uses by default the wrong FPU type. so Always -Cfvfpv2 has to be added to use the right FPU commands just to make sure I also added the -CpARMV6 to select the CPU instructions suitable for Raspberry Pi and higher. With this changes the helloworld program do not crash anymore. And also the fpc compiler works now (at least the help text).
Freepascal compiler on RPi AROS
I noticed that the official released AEROS for Raspi is named as ABIv0 and the Nightly I used is ABI_WIP (see screenshot some days before). hmm are there differences between this two, so I installed the latest AEROS on my Raspi and tried my hello world 😉
And, it works, without any problems, or crashes.
Freepascal on latest AEROS for RPI2
Maybe someone noticed the rather strange format of my screen shot, which is 800×480. Thats a special touchscreen display for RasPi. The RasPi can be connected with a foil cable to this display and the touch works as mouse move/click. In principle it can also do multiple touches and so on, but I didn’t install a driver for it.
The RasPi is installed on the back of the display and all is put into on side of the delivery (paper) box of the display. In reality the picture looks perfectly clear and sharp, its just the camera interference creating this stripes.
For Aeros this screen resolution is a little bit too low, some icons are outside the visible area, some programs do not work well (Emula for example), but for my needs its ok.
Maybe I install some smaller icons then it should be much less of a problem.
I playing around with my Raspi2 and AROS on it. I tried long time ago already but didn’t get the cross-compiling tools to work. The tools still do no work, but with some manual work, somehow the assembler and linker work, everything I need for fpc 😉
The biggest problem of course is the startup code again, here even more difficult for me, because never used ARM assembler before.
I found the ExecBase at r5, so the most important Data found already. Sadly it crashes then when it enters the PascalMain, I followed it and it seems it crashes inside the SysInitFPU. I have to admit I have no idea about the FPU in Raspi. I remember there are some different modes for FPU. For now I just disabled the the SysInitFPU() and it works. It works somehow with simple hello world application.
FreePascal Hello World application on arm-AROS
The compiler self does not work, just crash.. maybe this missing SysInitFPU has some side effects or more FPU access which crashes. I’m not sure how to continue here maybe I need to ask someone about it.
Included more menus and key strokes for the different functions, the hotkeys for existing buttons is very easy, there is a special field to trigger them (MUIA_ControlChar). That means you do not have to care about, Zune does it care about. But for other hotkeys, like Volume up, down, mute and so on, it is not possible. I did not get it to work using InputEvent field. The event is fired on keypress. I didn’t find a way to check which key is pressed because the Message pointer points to a Zero-ed area, maybe a Zune bug. In the net I didn’t find a source using that function (except directly, but not via a Hook). Of course it is nice to have the hotkeys also denoted at the menu entry. Sadly the MUI_MenuItem_Commandstring still does not work, so the Amiga sign is always shown at the menu entry with the key. I filed a Bug report about it, but I checked the latest source, it’s still not fixed. I looked into the source and found that this field is just not used and sent to the system. I’m not very good at C coding but even I was able to include this, because it’s just equivalent to the enabled flag for example. The Diff of this change is now included for ABIv0 and ABIv1 and it also work in the latest nightly. Hopefully the next Icaros will also include this change, until that the Amiga-key sign is there, but you do not need to press it.
Besides this I also included a hotkey to open ZuPaPlayer if it is hidden. (Ctrl-Alt-z is the default, but can be configured in the Prefs Window). For this purpose the commodities.library unit had to be included to Freepascal.
Download: ZuPaPlayer 0.2 for ABIv0 i386 AROS
ZuPaPlayer 0.2 with Menus and Hotkeys
