Playing more with arm
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.
FreePascal on Raspi AROS
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.
m68k broken again.
It seems the m68k amiga freepascal compiler is broken again. A Simple Hello world program compiled on an Amiga works but when a uses is in the source file the compilation stops with “Fatal: Internal error 201309171”. It happens rather often that the m68k compilation breaks, and it needs always long time to notice it, because I use cross compiling most of the time. (even in UAE native compilation is rather slow). To get faster informed about such things I added a test to my automatic compile server. An E-UAE Amiga with Workbench 3.1 is started and the last compiler is used to compile the example programs. Two of them are also executed (HelloWorld and GenerateMD5, maybe later I write some special testcases). I didn’t have time until now to find out whats the problem, but I hope Charlie can fix that soon.
Back to Workbench 1.3
Chain-Q added support for 68000 to freepascal compiler. It needs special care because it has some additional alignment need on read/write to structures. But to try it on a 68000 Amiga it should be also Workbench 1.3. the current RTL implementation needs at least 3.0. It was rather easy to create a RTL which also works on 1.3 (via defines) but also the init code (written in assembler) must be changed. I have to find out how to make defines inside prt0.as. Then it could be even added to the official repository. I wrote a little testprogram to test the RTL and make some basic alignment tests. Both works well now.
AmigaOS4 Freepascal release package
Added some more units to OS4 freepascal: MUI and networking and created a release archive which will be created as nightly (like the other platforms). You can find them on my nightly folder.
FP-IDE for AmigaOS4
Reached the state of AmigaOS4 compiling and running the FP-IDE 😉 This was the aim of this implementation run, so its proven the library units are there and working the rest will be just work. For LCL at least MUI have to be implemented, but when I see how slow the FP-IDE is already in WinUAE I really do not want to try LCL.
I will clean up everything and commit to freepascal repository and make a release archive.
Amiga Freepascal Release with LCL
I just waited for this fix to make a Release of Freepascal 3.1.1 for m68k-amiga with the new Lazarus component Library. Of course its still early alpha state but it is somewhat usable.
Check FPC Amiga Page for the download.
Of course this archive does work on m68k AROS also. (It does not include FPGui for now)
Be warned: LCL is still is very early alpha stage, so expect crashes. It aims on fast RTG Amigas or even better RTG-UAE, but some simple programs also work on AGA/ECS Screens.
Notice: you need at least 180 MB of free RAM to compile a LCL program
About this year … 2015
This year freepascal got a big advance on many levels, in general with the freepascal 3.0 and for the Amiga-style systems also. Even more advances on the LCL/Lazarus topic on Amiga, AROS and MorphOS.
It began in 2014 already, when I restarted the MUI LCL implementation for AROS. Begin of 2015 I cared more about some applications to test the implementation especially the owner drawn things. So I wrote ColorIt and FPCMines for AROS and tried to write or port some little apps and some more.
A milestone reached in march 2015 when I got the SynEdit component to work. The little test program I used to play around with the needed changes in LCL grew on requests from the AROS community to a full usable Editor, which got the name Edisyn. By improving the editor many additional features are included into LCL, like key events, advanced mouse events, tabs, scrollbars, colors and much more.
With all this improvements I felt ready to give the lazarus ide another try and finally at least it starts. So we are on a good way to bring lazarus natively to work on AROS.
But how about the other platforms (AmigaOS and MorphOS)? I did already some changes in the code with the other platforms in mind. When the resource support was enabled in freepascal I took the opportunity to try to port the LCL for MorphOS and m68k AmigaOS. Which somewhat worked but not in the same way as in AROS especially the layout did not work and the program always crashed on the end. But it gave me much insight how MUI is working also for AROS Zune which is a little bit more error tolerant than the original MUI.
Also on the freepascal front some new things appeared, the support for x86_64 AROS was included, but sadly because of the ABI difference the port is still not finish and unusable. I’m waiting for the ABI switching feature in freepascal. The implementation is done just I need the decision to do it in the proposed way.
In October I did something unusual for me, I did C coding for AROS, trying to code a dynamic Amiga-style Library (in this case sql) to use it in freepascal AROS. But later I found out this wrapper library is not needed and I can directly use the C linklibs as they are.
At the end of the year I took more work again on the MorphOS and m68k Amiga LCL and finally got it to work. So the first LCL programs can be compiled for MorphOS and m68k Amiga.
What 2016 will bring
I hope I can join the two LCL implementations (AROS on the one side and MorphOS and Amiga on the other) together again. Bring the MorphOS port to the same level as AROS, that maybe Edisyn will work. The next logical step would be to continue on lazarus ide and try to make it somewhat usable.
Finally I found the reason for the strange crashes on Amiga and MorphOS on destroy of LCL apps. And now I also understand why it was so difficult to find it. It was … drum roll … not in my code :-O. It’s in the library units of MorphOS and Amiga. Little bit about the basics. On AROS I open the Library (belongs to a unit) inside the initialization section and close it again in the finalization section. I’m used to this behavior from windows DLLs. At Amiga and MorphOS a different way is used. The OpenLibrary is done in the initialization section (for Amiga) or must be done manually (MorphOS). On this OpenLibrary call the ExitProc of the unit is connected to a CloseLibrary routine. So far sounds good, but it seems the problem is that the ExitProc is called BEFORE the finalization of the unit, long time before as it seems, hence the muimaster.library is already closed when I try to destroy my MUI Objects which horrible crashed.
I placed some Debug output in the InitMuiMasterLibrary and CloseMuiMasterLibrary and can clearly see that the CloseMuiMasterLibrary happen before my LCL destroy things are called. I will play around a little bit with it. But in the end I have to talk with Charlie (Maintainer of FPC-MorphOS) about this, how to solve this problem.
This explain also other crashes I experienced before (like the crash of CloseFont for example)
Freepascal 3.0 release
As you might notice the freepascal 3.0 stable release is out. This is the first stable release includes AROS as a “fully supported target“. I created a binary release of this 3.0.1 stable freepascal for i386-aros. It only includes the compiler, FP-IDE and freepascal packages: RTL, FCL and AROS library units. (So no FPGUI, LCL and so on) It’s mainly needed to compile the trunk version as starting compiler. For real life coding the trunk version is a much better choice, because it has some more bufixes and new functions inside. The binary archive can be downloaded at the FPC-AROS Page.
Binary stable releases for Amiga and MorphOS will be created by ChainQ I guess.