Archives for Compiler Core

CRT Unit

Posted by ALB42 on 29. Dezember 2019No Comments

Most Tutorials about Pascal use the CRT unit in a very early Lesson. They use it only for ReadKey() to wait for a key at end of Program. It would be of course the same to just use a ReadLn and wait for an Enter.

I tried already to implement CRT before using an old implementation, but exactly this ReadKey implementation does not work at all when KingCON or other console replacements is used.

Now I got a hint in MorphOS Forum (always a very good Source for Implementation hints) to set the console in RAW: mode (using SetMode()) and then just read from the console the pressed keys. If console in raw mode, one can read cursor keys and F keys from the console.

I tried that and on MorphOS and AmigaOS3 it works well, Read blocks until a Button is pressed. But AROS of course is different again 😉 it always returns a Value sometimes 185, sometimes 184, not really know what that means. I thought about some kind of timer event but this should look different.

But finally it works, mapped some keys like F-keys and cursor. Also worked on the output gotoxy and colors, the colors are a little bit tricky, because the Amiga console only supports the first 8 pens (as far as I see it) so I cannot just ObtainBestPen, and the first 8 Pens are usually fixed and not the colors I need. I try to change them with ObtainPen but when they are already taken I just try to find one which has a close color, which does not work very well. Solution unknown.

I compile the example of ReadKey as example3.pas and compiled a little RPG-Game I found which is console based, which is a good testcase for colors and GotoXY. Of course looks not the same as in the DOS console but it is usable.

Not Release

Posted by ALB42 on 18. Dezember 2019No Comments

I guess there was some confusion about the installers I presented the last days… these are not official Releases of FreePascal 3.2. In fact FreePascal 3.2 is not released yet and also no fixed date for it yet.

My work on the installers just show my work preparing the next release that we have a real Amiga style installers with all needed Readme and copyright text that they can serve as official packages and even published on the official FreePascal site.

You can download these packages and test the installer, and that was the purpose of showing them, but please do not distribute them as FreePascal 3.2 releases. (I added also a beta marker at the page and in the ReadMe to make it clear) And do not post news messages about FreePascal 3.2 Release until there is an official announcement.

Thanks!

Installer MorphOS

Posted by ALB42 on 15. Dezember 2019No Comments

And as promised the Installer for MorphOS also to the latest Version. I used my old MacMini (with the acient MorphOS3.8) for that, but somehow it is rather slow. Maybe I’m spoiled with my PowerBook now, which feels much faster. But the MacMini is much better for such tries, not destroying my working setup on MorphOS.

Again a little Video:

Have Fun!

Installer Amiga 68k

Posted by ALB42 on 15. Dezember 20192 Comments

As mentioned yesterday the 68k Amiga Installer needed a little bit more work, but now it is working nicely the same way as the other two.

In the video the customized Option selection is shown.

Next I will test the MorphOS installer again and try to make an own Installer for AROS. Thats a little bit tricky because of the Package system they use, which is nice but no support for it in the Installer as far as I can see. Path and assigns are not added to user-startup but should be made via a Package-Startup file, in the folder and a text file in the Envarc: pointing to this Package-Startup File. I did this already for the AROS install process but not with the Install tool.

Installer OS4

Posted by ALB42 on 14. Dezember 20194 Comments

The release of FreePascal 3.2 gets closer (at least I hope) and with it the first full Release of FPC with complete Support of all Amiga Systems. I created already an Amiga-Style Installer for Amiga OS3 and MorphOS.

Today I added a Installer for Amiga OS 4 which should work on all Amiga OS 4 systems (except the X5000, yes that problem still exists because we have no way to debug it, without such a system available)

I made a little video about the general installation of FreePascal on Amiga OS 4.1 Final Edition Update 1. It needs a reboot at the end, maybe one could add that to the Installer, but I don’t like that when Installers force reboots.

If you want to try out check the url in the Video: http://build.alb42.de

Leu Icaros64

Posted by ALB42 on 3. Oktober 2019No Comments

Paolo Besser works on a 64bit Version of Icaros (see also his website about it). I only try my AROS64 bit FreePascal stuff with my old linux hosted AROS 64 version, and there it worked fine. But the ABI of x64 AROS is not fixed yet, so still changes can happen. And there are some changes, Leu for example crashes on the Icaros64 alpha version, Paolo sent me. It crashes very early in the startup code. I started to debug that stuff but it’s very hard to debug at this point, that early in the startup. But my initial guess was more or less right, because the AROS devs tried to implement SMP they changed a lot of structures for additional locks and so on, so the Offsets of fields are moved. Usually an easy job just compare the the new C includes with my pascal counter parts. but it makes it much harder if defines and alignment comes to play, here also. The define was easy, there is a __AROSSYSTEM_SMP__ define which seems to be always enabled, even AROS is not compiled for SMP use (seems still too unstable) which includes and additional spinlock_t to MsgPort and Sempahore, so far so well. But it seems this spinlock_t is huge, by the definition I would say an Integer and a Pointer, but the size needed in the structure to cover up the missing offset shift is much more… something around 256 bytes. The structure is 128 aligned, this could be a key for that.

Usually that is not hard to find out, just make a small C program and test the sizes and offsets of the related structs, but… who have guessed it … on Icaros64 that is not that easy, because the gcc installed does not work, it just crashes. And btw. collect-aros, which we need fore linking in FreePascal also crashes, so for sure no compiling directly on the system.

But just by try and fail/crash and comparing the results of process and task structure to the output of Scout I got a somehow working version, it’s a very dirty hack, but for now it works, Leu works, FPC works (until collect-aros crashes when try to link, but without linking, everything is fine), FP-IDE is working (with the same problem like FPC of course).

Leu and FP-IDE on Icaros64

There is some more work to really make that structures correct, but for that I will wait until the gcc is working again. The described way to compile stuff for 64bit in C on the icaros webpage using metamake is hilarious if you just want to compile a hello world it’s way overblown. I tried it, but it does not work, also compiling AROS64 from source does not work, I guess you need some pesky parameter when calling configure which, of course, are not described.

Taming my dragon

Posted by ALB42 on 2. März 20192 Comments

I bought a Draco, if you do not know what it is, its a Amiga compatible Clone used for Video editing. It does not have the traditional Amiga Chipset (ECS/AGA) therefore nearly all games will not work. But Workbench based programs and RTG compatible programs will work. For me only interested in FreePascal and stuff its the perfect RTG Amiga and it’s much cheaper than any other Amiga with RTG, Soundcard and a 060 card + 128 MB RAM.

I replaced the (very noisy) Harddisk with a SCSI2SD V6 and removed one of the fans (which was basically for cooling the HD) and now the Draco is nearly silent and very fast, the SCSI2SD V6 reaches the 10 MB/s easily with the Draco SCSI. The Draco also supplies some standard Zorro II slots, I tried a X-Surf 100 to get network access to it (mainly to bring my FreePascal stuff there) but sadly it does not work, even I found some reports that it should work. Maybe the Zorro in my Draco is somehow broken, I cleaned already all the connectors and checked voltages of the power supply but no luck. To get at least slow network I connected an old Raspi via Serial cable to the Draco and used PPP like in the good old days. It reaches the maximum 115.200 baud but even that feels very very slow, at least it works. Maybe later someone can find out whats wrong with the Zorro.

FreePascal works nicely. But some other programs, which should be working (because only use standard API no hardware access) does not for example Delitracker with AHI-Noteplayer seems not really working nicely. Needs a little bit more investigation.

Datatypes for all

Posted by ALB42 on 14. Mai 20185 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 20182 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