Playing with locale
Still playing with locale settings on Amiga systems. FreePascal offer a possibility to care about international settings like decimalseparator, date formats and currency symbol. So I looked a little bit into and the system is comparable, still much work, so I’m not sure if really put to every start of a program, or maybe it would be better to put it to a separate unit and you have to include and invoke it by hand. We will discuss that.
Testprogram with Germany, USA and UK Locale Setting
Starting the same test program 3 times and changed the Locale Country setting in between. (For me rather funny that the currency format for positive and negative Values are so different not so nice if you have them in a table) But so far it works very nicely.
Yesterday I was at the Amiga and retro computer meeting here in Berlin, always nice to be there and talk to the people. ChainQ was also there so we worked a little bit on this strange WBStartup problem on MorphOS. As some already mentioned in the comments to MUIMapparium, it is not possible to start fpc compiled programs at MorphOS via an Icon. The programs just do not start directly freeze, the reason is simple, when starting via Icon the WBStartup Message is sent to the application via an MsgPort at the Process structure. Freepascal waits for this Message, which never arrives. After some trying we found, that the needed structures and functions in fpc are in good shape so not the root of this problem. The problem appeared when ChainQ changed the startup code from a assembler one to a pure Pascal startup code. So my guess was that it somehow relates to the needed symbol inside the executable, which defines it as a MorphOS executeable __abox__. Of course I do not have much knowledge about it, just a wild guess. But it turns out that this was quite right. The first problem is that I used an older version of vlink, which seems to have a bug and removed this symbol (because never used). After an new compilation of vlink the __abox__ symbol is there but still it do not work. ChainQ knows a little bit more about this stuff and also knows whom to ask in the inner circle of MorphOS developer what could be the root of it. Some strange things I was able to see, the program I started stopped when starting via Icon. But via TaskManager you can see, two of them are started. An other thing with Snoopium you can check when the program does at the start. Especially the OpenLibrary function is interesting in this case. You can see how the program tries to open the ppc.library, which I learned now, is a sign that MorphOS thinks that this program is an PowerUp executable, which explains the odd behavior. In the end the solution was not so difficult, FreePascal did not set symbol type and symbol size as expected by MorphOS. (The size is important because the __abox__ symbol should point to a longword with value one) It appears FreePascal already have a function to care about such things, which only have to be activated for the MorphOS compiler. Finally it’s fixed again. Thanks for the help.
SetFileSize and more size Optimization
Found a bug that the FP-IDE does not save it’s settings, like the last used size, recent files or Clipboard. All this Data are saved into the fp.dsk file in the same folder where the fp executable resists. I checked it and the file was just zero. I remember that I fixed that problem already once, but It could be that this was before FPC entered the official FreePascal repository and this change did not make it.
I checked on the old branch and really found it. The problem is that a seek behind the end of the file does not work on Amiga systems. The FreePascal Seek documentation does not define what should happen if you seek behind the end of the file. But it seems FP-IDE assumes it fills the File with zeros from the end of file to the new position. I included a fix for it and it nicely work on Amiga m68k. But on AROS it stays 0 bytes after some more debugging I noticed it writes the file successfully, but then at the end it gets reseted to 0 bytes. The call doing that is truncate, which resolves to SetFileSize() on the AROS size. It seems this function does not work as expected or I misunderstand it. Wrote a little test program and really if you write 4096 bytes to a file and try to SetFileSize to a 1024 bytes you get a 0 byte file. a Retest on Amiga results into a 1024 bytes files, as expected. Strange that such a basic function should be non functional in AROS and nobody noticed. The bug seems to be present for ABIv0 and ABIv1 as well. So nothing to do for me here.
This days I used the FP-IDE a lot on a native AGA-Amiga1200 and it is really usable, but I noticed the FPC archive for m68k-amiga is very big for a real Amiga. The download and unpacking needs ages so I got an idea to make a small Release for Amiga which only contains the most important RTL and Amiga units. Today I found some time to create such an archive. It is 6 MB download and around 20 MB after unpacking (the complete archive is around 52MB and 305MB after unpacking). Both archives are available on the nightly page.
Small, Smaller, Smallest
We (ChainQ and me) activated the section linking for the other Amiga Platforms as well. Freepascal for MorphOS for example will now also use vasm and vlink with section linking. The mentioned MUI demo for example has a size of 82k on MorphOS, so a little bit bigger as on Amiga 68k. Sadly vasm and vlink does not exist for AROS currently (except 68k of course) so there we are bind to the GNU tools. But the AROS ld is much more recent so it supports section linking already. The sizes of the MUI demo for the AROS Platforms: i386: 83k, ARM: 86k, x86_64: 144k. Sadly on AmigaOS4 it still not work, it still needs some fixing in the linker and startup code. Of course it’s nice to have this small sizes on NG Amigas, but more important on the 68k Platform, maybe you remember the compilation attempt on a real Amiga (so not UAE) which needed around 3 minutes and 160 MB RAM. I retried that with vasm and vlink today. It is smaller (1.6 MB instead of 6.5 MB) and also need less RAM for compiling and linking (around 100 MB instead of 160 MB), really nice. The speed does not really change, because it is limited by the Harddisk speed, which is around 1.2 MB/s only for my A1200. I’m thinking to use the SCSI of Blizzard 1260 but I need a fast SCSI to SATA Adpater or so, the one I found in Internet seems not so good, no synchronous transfer, questionable compatibility with the SCSI interface of Blizzard.
Small is beautiful
Something really awesome is going on in the Amiga Freepascal world. ChainQ is working together with Frank Wille (the Author of vbcc) to optimize the size of executables created by freepascal compiler. Some things had to be included to freepascal and vasm (the Assembler) and vlink (the Linker) had to be adjusted to freepascal, hence you need the latest nightly to test this. The result is truly remarkable.
Just as an example, I compiled the MUI-Demo from the muihelper session.
With LD it has 321k with the new section linking it has around 50k and of course it still work.
The original binary MUI Demo is around 25k, the difference should be the RTL which needs a little bit space, but also delivers more convenience and securtiy features for the coder (like string handling, memory management and helper functions)
We use the vlink a while already on Amiga m68k because it’s much faster and do not depend on ixemul.library. Now it also creates much smaller files. So no reason to keep the old GNU ld and with the vasm we also do not need the GNU as anymore, so in principle both ixemul.library dependencies are gone. I will test that a while expecially also with LCL applications, they are huge now, I’m curious how somall they can become.
If you would like to test download a current nightly for m68k-amiga. I included the vasm and vlink already and also activated it as default.
The same thing should be also working for MorphOS, this I will try soon, so stay connected.
About this year … 2016
Again a year passed so I will try to give a short summary about things going on in the Freepascal world for Amiga-style systems.
In Januar 2016 a big change in Freepascal was done to fix the Varargs version of the amiga library version. All “array of const” are replaced with the better “array of PtrUInt” which is much better to emulate the open end parameter list
The MorphOS LCL implementation took a big step in the begin of the year until got the usual suspects to work. All resulted in the first MorphOS FPC release including LCL units in March 2016.
A little funny new experience started also in March. I created the first 64Bit ABIv1 AROS distribution. Mainly, of course because I need a test field for the FreePascal AROS x64. For me x64 would be the perfect successor of the i386-aros ABIv1. My suggestion for AROS developer would be to leave i386 ABIv0 as it is, backport changes to there. And change then to x64 ABIv1 (and do not use/promote i386 ABIv1). But the x64 AROS still need much work, many things still crash, much code still cast Pointers to integer so not 64bit ready. This is also the main reason the 64bit distribution did not get much new version, not much changed with the problems there, I retest the usual problems from time to time. Also the FPC 64bit had big problems, which I found out end of 2016 are mainly alignment problems, where AROS made it’s own life much harder than it should be. (reminder “stacked int”s)
EdiSyn got a new Version with some bugfixes and basic printing support. End of year it got also a ARM version of EdiSyn to public with some more advanced features.
I also tried EdiSyn on MorphOS and Amiga. But both have some problems because of the different behavior of MUI and Zune. And I did not took much work on it because on MorphOS there is already a very good Editor with syntax highlighting and on Amiga m68k it’s just too slow. But in principle it works just LCL need some more work.
LCL on a native Amiga got some improvements to work also if no Graphic card is present, like my A1200 and also ported the usual suspects to m68k Amiga.
I used already a Lazarus on Linux to cross compile to AROS i386, in April I created a Lazarus which can cross compile for all supported Platforms (AmigaOS 3, AROS, MorphOS). Because it worked to nicely I planed to release a Lazarus for Linux including the binutils and cross compilers for all Amiga systems. But I noticed it is very difficult, even to write a Manual how to install such a systems. Therefore I decided to create a virtual machine which includes Lazarus, cross compilers and binutils for all Amiga Systems. After Amiga OS 4 was added to Freepascal and LCL I released a 2nd Version including the Amiga OS 4 binutils and cross compiler.
ChainQ implemented FreePascal for OS4 long time before already but because of changes in FreePascal and without a maintainer it did not compile anymore. In April ChainQ resurrected it and fixed some basic things, make it self compiling again. Then I took the lead and implemented some OS4units bring FP-IDE to work and finally the LCL with the usual suspects for OS4. Which resulted to a Amiga OS 4 FPC release including LCL. I will continue to maintain the OS4 fpc but will not improve it much more, maybe someone will appear to continue it especially with the unusual interfaces can be found on AmigaOS4.
I continued to work on applications using my LCL. This time I got the idea to create a Map application showing routes of my bike GPS. I played around with google maps API and openstreet API. Openstreetmap is much better because google maps you are forced to use the google libs which is difficult at AROS. It get some releases for all available platforms. I also experimented with GPS support, first via a extra program later also directly inside Mapparium, which is still not released.
Long Time before I got the direct linking of C static objects to freepascal programs at AROS to work, which was really nice, but no real program resulted from it. On magoriums work on mikmod, I got an idea for a Delitracker like program for AROS, to Play my old modules. I results into my first native Zune program (so without LCL wrapper) ZuPaPlayer. And because Delitracker is working directly on MorphOS and Amiga I concentrated on AROS.
There I also noticed its rather difficult to write MUI applications in Freepascal. In C there are many many macros to make it easier, but they are not directly possible to convert to pascal. There is a muihelper unit in MorphOS with some starts to make it easier. I moved it to ami-extra to make it available to all platforms and extended it a lot. To test and prove the usability of it I started to port the example codes of the official MUI 3.8 release. On Amiga it works very nice on AROS it shows very good the differences of MUI and Zune.
Because ChainQ included support for 68000 processor which need some more alignment care. Because of this I created a little RTL for Workbench 1.3 which is really difficult because much things are not available.
This year also the port of FPC to ARM AROS including LCL and the usual suspects was done.
I try to bring the MUI-LCL to the official repository, started with the basic LCL implementation. Announced at mailing list. We will see how it goes.
Worked a little bit more on the ABIv1 x86_64 started long time before. Found some errors and got the FP-IDE to work and some simple example sources. But LCL and fpGUI still do not work. The main reason for that are the changes between ABIv1/ABIv0 and some inconsistencies of 32bit/64bit types.
Bad thing, changes are not denoted in the C-header files for AROS, so it’s a very annoying comparing work done by hand to find if there are differences. Differences in Library offsets for functions in the most important libs are done and exec structures are also fixed.
FP-IDE on x86_64 AROS
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
Edit ARM Freepascal
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