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.
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.
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.
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.
One disadvantage of writing a program relying on web resources is, that you have to update that program everytime the webresource is changed/updated. In the next days the search for MUIMapparium will break again, and the Find by IP/ Find me is broken a while before already.
So I updated MUIMapparium to Version 0.8 I also added some small new features, like some more shortcuts and also by popular demand to jump automatically to the first search result. Best update soon before the search function does not work anymore.
Also the 68k freepascal compiler got some updates which hopefully improve the stability and speed of the m68k-amiga Version.
Worked a little bit on Leu, a click on row/column title it selects the whole row/column as used in other spreadsheet applications. On RTG Screens with 15bit or more colors the selection now blends the background color instead just replacing it, that means you can still see different background colors when selected.
Multi-line is something people where asking me for, so I implemented that, if you are in a cell typing you can use Ctrl+Enter to go to next line, instead of finishing the editing. I got a question, if I plan to support different Font sizes and type, and I’m not sure about that until now. It would need a complicated replacement table from the Windows/Linux fonts to typical Amiga fonts and back. Especially on classic Amiga the Font sizes of Windows and Linux are WAY to big. We will see.
A while before I was working on the cell format (number format, date, time and so on) but this is rather complicated. It needs a bit more time it’s still not reliable but I want to finish it before release the next version. Some of these features (like the selection blending) are already present in the Leu version I gave Paolo Besser for the Icaros64 alpha WIP.
Improved the real time raytracer (no GL, just pure Math-Power 😉 ) a lot today, first introduced movement, standard “wasd”-Movement and mouse look. then I thought it would be cool to select blocks and change/remove them, for that I had to rewrite the raytracer to remember where I hit which block, but then the raytracing part became much slower, so I wrote a second routine exclusively for selecting Blocks (and a face of a block) which worked nicely. Of course much cooler it would be to also set new blocks. Easiest way is to just look at a face of a Block and add there an other Block. And it works well. I made a little movie to show how it looks like now.
You might notice that the image becomes a bit worse when moving. I decided to lower the resolution when moving, so you can fast move but have a nice image when stand ;-).
Again I show that on Icaros64, why, easy, it’s much faster, around double speed I would guess. You might ask why that is the case, easy, you have a lot more registers in x86_64 also for SSE3-Math calculations so much less memory access. And I also guess the optimizer for x86_64 in FreePascal is better than the one for i386. But it comes with a price, the exe is much bigger, 160k for i386, 260k for x86_64, but still rather small when you consider what it can do already 😉
Again playing with 3D stuff, realtime raytracing, but this time a little bit stripped that it also can work on a real 68k Amiga, like the Draco, so without mirrors and so on. The new improvement by Charlie in the FreePascal compiler seems to work as it should be and also increase the speed a little bit, so it’s almost fast. Ok its still horrible slow, but hey the first version needed around 10s per frame, now it’s under 2s.
Also tested with AROS and because its the new “hot stuff” of course on AROS64 and even the image is 4 times bigger it moves smoothly. If you make it the same size as the Amiga68k one, it needs around 8ms per frame but the window is very tiny.
It’s still heavy with floating point calculations so the 68060 is very good to use the 68881 will be much too slow. I also tried the Vampire 68080 which have a much faster but not so precise FPU. Good news it works, bad news it looks broken. I only use Singles everywhere and removed all Round() from the source but still it looks completely wrong, no idea why.
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).
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.
Just playing around a bit, with color and sound. RGB fits onto the keyboard inside the case without any change to the original stuff. React to the sound and with a little GUI to change the config, of course in FreePascal.