Archives for Compiler Core

Datatypes for all

Posted by ALB42 on 14. Mai 20184 Comments

I created the datatypes unit for AmigaOS4 and AROS and rewrote the ones for Amiga68k and MorphOS. OF course the aim is again to make them more or less compatible to each other. Of course also wrote a little test program and compiled for all systems which works nice.

DataTypes test for Amiga68k, MorphOS, AmigaOS4 and AROS

Now I have to learn how to actually use Datatypes in a program, especially seems sometimes the datatypes seems to scale down to 8 bit (256 colors) even the screen has 24 bit which I do not understand and if there is a way to let the datatype scale the image to the right size. I use the BitmapScale from graphics.library but this is awfully slow (At least on AROS, even my straigh forward nearest neighbor routine is faster than that).

Installing FreePascal …

Posted by ALB42 on 8. April 2018No Comments

Working on a Installer script to installing FreePascal for Amiga using the official way. In the past I often used Installer scripts but never wrote one. It looks very close to LISP (brackets everywhere ๐Ÿ˜‰ ) luckily the scripts are just saved as text. You can peek into other scripts, how to make some of the more difficult parts. For the basic structure I found a nice program in Aminet InstallerGen, it provides a nice MUI Gui to create the install steps, which also helps to understand the language.
The first version is finished now. You can select the installation type, minimal, typical, full and customized. On customized you can select the packages to install. (see image) Of course it also adds the needed entries for assign and path to the user-startup. The plan is to create some more such installers to install more packages, afterwards, like LCL, MUIClass or the FPU-enabled units.
For MorphOS and OS4 this should be easy to create from it. On AROS it will be a little bit different, there is no need to alter the user-startup, you only need to register it as a package.

Vampire V2.7 with FPU

Posted by ALB42 on 2. Mรคrz 20188 Comments

The new Vampire firmware is released V2.7 which contains a Hardware FPU in the FPGA (some seldom 68881/68882 commands are still emulated, like the 68060/68040 also do) but nevertheless, thats very nice for my MUIMapparium (you remember the problem?). Of course I flashed directly the new version, first the bad news, it’s VERY unstable for me, it’s said it needs some soldering because there are some errors on the early Vampire cards which make the power supply to the FPGA bad… something like this and I’m affected with that … so it’s a little bit annoying to work with it because there are drawing errors on the screen and it crashes often. I reduced the screen resolution and ended all background program which made it much better. But nevertheless to really try it out I have to wait until someone fix my card. I can’t do that myself, most scary thing in the world a coder with a screwdriver let alone a soldering equipment :-P.
But this was not the topic of this post. I tried MUIMapparium FPU version on my new Vampire 2.7… good news it starts does not crash, bad news the map stays empty. The same Executable worked well with FEmu (I checked especially before I flashed the new one) on the old Gold 2 and still work in UAE. But the FPU calculation seems to work because the mouse pointer movement shows reasonable coordinates. I was a little bit surprised because even the GUI in the map window was gone. I checked the code ah yes there is a tiny floating point calculation, fine let’s see whats that. An my guess was right it is the floating point calculation, the Button size is calculated by the Font Size * 1.2 to have a little bit more space around it. After adding some debug output it seems that the floating point calculation works well but the rounding always return zero, so I wrote a little test program to test the rounding here the outputs of the testprogram in my setups:

Vampire 2.7 Amiga 1200/030/68882 UAE 68060 emul
a := 5 = 5
a * 1.0 = 5.000000000E+00
Round(a * 1.0) = 0
b := a * 1.3 =  6.499999523E+00
Round(b) = 0
Ceil(b) = 7
Floor(b) = 6
Floor(b) = 6
press enter
end
a := 5 = 5
a * 1.0 = 5.000000000E+00
Round(a * 1.0) = 5
b := a * 1.3 =  6.500000000E+00
Round(b) = 6
Ceil(b) = 7
Floor(b) = 6
Floor(b) = 6
press enter
end
a := 5 = 5
a * 1.0 = 5.000000000E+00
Round(a * 1.0) = 5
b := a * 1.3 =  6.500000000E+00
Round(b) = 6
Ceil(b) = 7
Floor(b) = 6
Floor(b) = 6
press enter
end

Na? who spots the difference. Funny that only Round() have this problem but ceil, trunc, floor not. This also explains why MUIMapparium shows no maps at all, if all is rounded to 0. Ok I have to wait until they fix that… yeah I could replace all Round(a) by Floor(a+0.5) but why should I do that, here is clearly something broken in the FPGA.
 
You want to try on your own computer – Exe for m68k with FPU: TestFPU and the source: TestFPU.pas

Updated vlink and vasm for fpc

Posted by ALB42 on 12. Februar 20182 Comments

The creation of vlink and vasm for Amiga is always a little bit difficult, hence I seldom do that. But Charlie told me, that the creator of vasm and vlink also supply executables for most of the platforms. Even the rather uncommon 68k asm with standard syntax (instead of Motorola syntax) are there. Long text, short meaning, the vlink and vasm for Amiga 68k, Amiga OS4 and MorphOS are updated in the nightly Release packages. And with this it will be much easier to keep them up to date.

Unify ASL

Posted by ALB42 on 21. August 2017No Comments

I checked the ASL.library units of MorphOS and Amiga 68k against the official C includes of the SDKs. Especially the TFileRequester structure was always a little bit trouble because the old Amiga asl unit still used the old field names rf_* but from V38 of the Library this fields are all names fr_* and some other tiny dame differences (e.g. Dir vs. Drawer). In AROS and AmigaOS4 I only added the newer names because here I do not have any “old” code. This resulted in a big inconsistency between the platforms and need ifdef’s in the final programs. To prevent a direct breakage of the existing sources (e.g. LCL, MUIMapparium) Amiga and MorphOS have both field names in the structure (as case). The aim will be to remove that ifdef’s from the sources.

Amiga Linux the next day.

Posted by ALB42 on 3. Juli 2017No Comments

Of course the freepascal compilation did not work, still needs some link library and stuff. (Hint for later at least libc6-dev and libgcc-5-dev is needed) I restarted first a plain compilation and hmm it still runs ๐Ÿ˜‰ the tests will need to wait a little bit. Besides that of course I played more with the system, of course its even slower that way because the compilation is running in parallel. Installed some packages I need on there, telnetd for example, sshd just slows the poor 68030 to much down. For file transfer I want to join it the normal NFS network I have already. But when installing nfs-common I was really shocked it has python as recommend, really? Python for NFS? On my normal computer I do not care it’s usually there already but on Amiga, space (and more important installation time) is short ๐Ÿ˜‰ so need to with “–no-install-recommends” But my personal opinion is when a simple network file protocol from the early years of Unices pull the most hyped script language monster (15.5 MB additional crap!) then there is clearly something wrong in your package system.

IPv6 on an Amiga

As you can see the compilation still runs ๐Ÿ˜‰ (the Assembler as runs currently on other TTY) and even IPV6 works! An Amiga doing IPV6, welcome to 21. century (no Amiga OS is currently able to do that). The system runs rock stable (uptime already 28 hours) even I stress it with parallel installation and other changes and let the compilation run. Very nice and stable just a little bit slow.

ALB goes crazy episode 9842: Linux on 68030 Amiga

Posted by ALB42 on 2. Juli 20174 Comments

To help ChainQ with the FreePascal for m68k compiler bug finding I installed a qemu-m68k on my server together with a chroot environment to let the FreePascal testsuite run. An ChainQ really found a lot of bugs. I also improved the chroot environment. The number of fails falled down from 160 to 34 which is a good value more than i386 (around 20) but better than PowerPc (around 40) ๐Ÿ˜‰ already a nice achievement. But I thought it would be even cooler to start the test suite directly natively in a m68k Linux environment. (also qemu-m68k maybe has some bugs :-P) The only real hardware I have available for that is my Amiga 1200 with 68030, luckily it has a MMU so Linux will be possible. (The Amiga 600 with Vampire does have no MMU therefore Linux is not possible to use) Informations about this topic are very hard to get and most of the links are dead today. So in the end I compiled the kernel (3.16.7) on my own and created a initramfs by hand. For initial root I used the chroots debian environment I use already for the fpc tests. But systemd made me much headache, it was much easier to write a own little init script. Finally the systems boot and even the PCMCIA card works, I can SSH to that server.

Linux on a Amiga 1200 with 68030

The next is installing FreePascal and try to run the compilation and finally the test of course. There are some unexpected problems here. Usually the latest FPC from trunk requires the latest stable FreePascal version, that means at the moment 3.0.0 or 3.0.2 but both can’t compile the trunk because some features missing in 3.0. I tried to merge them from the trunk but failed to many things missing and not easy to identify which else should be merged. So I will use the 3.1.1 as starting compiler (and ignore the warning that this is not supported ๐Ÿ˜› yeah I’m a real outlaw) sadly it also have some problems I have to check later. For first try I just start the testsuite with the compiler cross compiled on my other Linux (x64) computer. The testrun started today at 22:15 will it run completely and if yes how long will that need? a week? ๐Ÿ™‚ We will see.

Compiling/Testing FPC on m68k Linux

Playing with locale

Posted by ALB42 on 22. Mai 2017No Comments

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.

Symbols

Posted by ALB42 on 30. April 2017No Comments

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

Posted by ALB42 on 5. Februar 2017No Comments

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.