hmm I did so many changes to m68k amiga but I didn’t try m68k aros again. When I tried it last time it behaved rather strange (see LCL on AROS). But now it seems to work. Maybe its because of my changes with layout or charlies m68k compiler changes. who cares, it work. Even EdiSyn looks ok to me.
EdiSyn and FPCMines on m68k AROS
EdiSyn had some problems on the experimental Icaros, Menu look very strange sometimes it also crashes. I fixed the problem and re-uploaded the archive for EdiSyn. Because yesterday I played around with printing so a basic printing option is also included. It’s really very easy, its like copy the the text file to PRT: with a small header to make the font smaller.
I did some tiny fixes in EdiSyn and some big changes in the LCL also have an influence to the editor. So it makes sense to release EdiSyn again.
Fixed Errors:
Download as always on the EdiSyn Page
I played around with AROS64 and freepascal for x86_64-aros. the compiler self works nicely, only sometimes some crashes because it does not make it’s own stack like the other amiga/aros implementations. I should really implement that soon.
For that I got the AROS source and compiled my own AROS 64 bootable CD and setup a qemu with it. There is no official AROS 64bit distribution now. I remember some announced one long time before but nothing happend. So now I will release my little work, together with a working freepascal compiler and named it „The 100% useless AROS distribution“ or short T100pUAD.
The Distribution gets its own page: T100pUAD Page
It includes some ore themes and freepascal, later I will try to improve it more and update it to the latest changes, maybe the 64bit get a little boost, it really needs it.
The freepascal IDE I did not get to work, always crash at the same place, but it’s deep inside of AROS and maybe some memory corruption before. So rather hard to find a reason.
I wrote a program to Inspect MUI properties. Very helpful to read out positions and recheck the size calculations of LCL. The main problem at the start was how to tell the program which object I want to inspect. The idea was to type the address from debugout. But then I noticed that the Userdata of the intuition Window structure points to the MUI Window.mui object. Thats means I can simply browse through all the windows on the screen and search for windows with a Userdata and try to find if it is a MUI object. Check if the Class of the object is „window.mui“. I tested also with other UserData contents, „mostly“ it does not crash.
But this only works on AROS, I tried the same on MorphOS but there the UserData is always nil. Seems they use an other method to link them together, its a pity.
The program for i386-AROS is named MUIInspector and can be downloaded here:
MUIInspector 1.0 for AROS
Sadly many important fields of the MUI object are not readable so not all important things can be read back to the list.
Be warned, when the program which is inspected is quickly changing, means destroy/create objects, maybe the MUIInspector is crashing. So its really only a debugging tool for me, but maybe other find it interresting as well
This weekend I did some bigger changes in the AROSUnits for better use of variadic functions in the SDK. The „array of const“ is replaced by „array of PtrUInt“ for all variadic wrappers. Because of this changes all this wrappers can be defined as inline and the arrays does not need to be copied inside the wrapper so it should be a little bit faster (even the effect is not that big I guess).
Also all dependencies to objfpc is removed so if someone want to write a freepascal program without objfpc dependency it should be possible now.
All this changes were discussed here.
But this all means that sources using such variadic functions must be changed, I changed already the fpGUI, LCL and example sources.
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.
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.
to everyone who read this 😉 I hope you have a nice christmas meal and some quiet time with the family, I will certainly have.
As Greeting to everyone I wrote a little program, nothing special, just a christmas tree and some falling snowflakes (needed 10 minutes to write in lazarus, I watched the clock).
You can download this little program for:
Amiga, AROS, MorphOS and if someone is interested the Source
Since MorphOS works rather nicely I tried to compare with Amiga 68k some more things have to be changes, especially drawing is much more difficult. AmigaOS3.x does not have the concept of RPTAG_FGColor to set directly the forground color with 24 bit values instead you have to use ObtainBestPen and so on. And there it is difficult to find out how long this Pen should stay before it can be released again. A little bit helping here is the Pen and Brush concept but for Background color and Text color its not really helping. But finally its working. But the picture looks very strange. After some testing I noticed that the GfxMove command make something strange, Even I call it with GfxMove(RastPort, 120, 130); the point is somehere in the negative region for X and Y. But Draw(RastPort, 120,130) for example work. Ok MY GfxMove call looks not like this but more like
GfxMove(RastPort, GetOffset.X + X, GetOffset.Y + Y); (Getoffset is a function which returns a TPoint) It seems that the m68k compiler have a problem with this construct because if I calculate an NX := GetOffset.X + X; and NY := GetOffset.Y + Y and then Call GfxMove(RastPort, Nx, Ny); it work. really strange. Besides it seems sometime it does not update the background and you get something like a ghost pattern hmm still much things to investigate. But for now I’m very happy that it already somehow work.
LCLTests on Amiga, MorphOS, AROS, Linux, Windows
I compiled the two test programs Button (Source) and PaintBox (Source) on every platform I have available.
There we have:
Upper line, Left Linux, Right Windows (via Wine)
Lower line from left, AmigaOS3.9 (WinUAE), MorphOS (via VNC), AROS (Linux hosted)
All programs compiled from the same source without a single ifdef, as you can check at github. Amazing isn’t it :-D.
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.