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.
What 2016 will bring
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.
There are still many strange things inside the LCL for MorphOS, especially the size (Window vs Contents) seems different as in AROS, it looks like the window size in Zune AROS is given by the inner size, but in MUI MorphOS its the outer size (with decorations). Hence the LCL calculations are wrong. I included some quirks to overcome this but not really a solution. The main problem is that I need the size of the window decoration before the window is open (so I can not read it from the window self). And then it depend on the window decoration (set by the user) and type of window (set by the application) how big the borders are. At this Point the AROS way is much more convenient for me.
The biggest headache I got with the texteditor, charlie told me I should not call MethodA() by using CallHookPkt() as I’m used to in AROS (MethodA is only a wrapper to CallHookPkt on AROS, as I read from the source). At MorphOS I should use the MethodA from AmigaLib unit, which is an assembler function. I changed all the calls but now the Texteditor.mcc crash, ok I should say not directly the Editor but something around. Looks like some Stack problems, If I switch back to my CallHookPkt() approach it works perfectly :-O. I tracked it down to the MUIM_TextEditor_ExportText which I use to read the contents of the TextEditor control, all other calls seems to work as expected. I have two ideas from it 1. It could be the problem that this Method Call returns something (a pointer the text, PChar) so maybe there is the problem. 2. I’m not completely sure but it could be that the Texteditor.mcc is a 68k element and all the other elements are PPC native. hmm the first sounds more like a reason.
An other odd thing I noticed yesterday already, when the LCL program starts the mouse pointer stutters some seconds (when the MUI objects are created?) usually such stuttering of mouse is not good ;-). I guess with both issues only Charlie can help me but he is still very busy.
Besides I improved a lot of things and tested many example codes to get an idea where we are, looks not that bad, image are not shown at all, some elements crash as expected, some not so expected, still much work but maybe worth to make a first pre-alpha-i-destroy-your-computer-release maybe someone want to try it 😉
You know there must be a screenshot… so here it comes 😛
FPCMines on MorphOS
There is something special on this screenshot, because its made with an LCL screenshot taker (for the source see Smile Screen) which work the same way on Windows, Linux, AROS 😉 and now MorphOS as well.
And the second special is of course the shown program FPCMines (like AROS Version)
Download: FPCMines MorphOS
P.S. I got some questions (ok one) if I dropped AROS support and switched to Amiga and/or MorphOS? No, I didn’t „switched“ or something like, the original plan was to bring it to all platforms. The idea was to bring it to work on the other platforms and maybe some bugs appear which make the AROS port also better/more stable over the time. And it really is working this way, because MUI is much more sensitive and picky about wrong parameter and settings as Zune. The AROS port is already rather mature for my things the most things are working and to be honest I’m the only one really using it. The complete lack of interest is therefore also a reason to extent it to MorphOS (and Amiga68k).
I try to stay away from all this discussions between all the Amiga-like OS (classic, MorphOS, AmigaOS4, AROS) the only reason I do not make freepascal for AOS4 is that the computers for it are way too expensive for my understanding. With MorphOS was the same as I started with FPC on AROS in 2010. But now with MacMinis usable a very nice and cheap machine is available. I don’t see myself as an AROS user (mostly I get this title), but more as a „Amiga-family“-User.
I put all together and made the ColorIt game fully usable on MorphOS, my first MorphOS LCL application. Its far from perfect, but its working. 😉 So here it is:
Download ColorIt: ColorIt for MorpOS
And (of course) a screenshot 😉
ColorIt on MorphOS
After I found out whats wrong with the crash I changed the morphunits on my harddisk to open/close library in initialization and finalization that I can continue testing the behaviour.
I removed some hacks I introduced for this problem and all work very nice. The next step was to activate my own MUI Class again and see if the paint event work as expected. It seems to work but the colors does not look like expected. The reason seems to be that my Buffer rastport only has 8 bitplanes, hence direct color setting does not work. I found our that the window rastport tells me that it only has 8 bits (even it should have 24 as the Ambient screen has 24 bits) So when I create my buffer RastPort and Bitmap I should not use the Depth from Rastport and also not set the Window rastport Bitmap as friend of my bitmap or it end up with 8 bits and the PenMode can not be disabled.
But finally I got it to run and to show that it work I compiled my old (AROS) PaintBox example and the little ColorIt Game.
ColorIt on MorphOS
The fonts are much smaller than on AROS which is little bit strange, and the comboboxes are still missing (see MUI is picky) this I will include later.
Finally I found the reason for the strange crashes on Amiga and MorphOS on destroy of LCL apps. And now I also understand why it was so difficult to find it. It was … drum roll … not in my code :-O. It’s in the library units of MorphOS and Amiga. Little bit about the basics. On AROS I open the Library (belongs to a unit) inside the initialization section and close it again in the finalization section. I’m used to this behavior from windows DLLs. At Amiga and MorphOS a different way is used. The OpenLibrary is done in the initialization section (for Amiga) or must be done manually (MorphOS). On this OpenLibrary call the ExitProc of the unit is connected to a CloseLibrary routine. So far sounds good, but it seems the problem is that the ExitProc is called BEFORE the finalization of the unit, long time before as it seems, hence the muimaster.library is already closed when I try to destroy my MUI Objects which horrible crashed.
I placed some Debug output in the InitMuiMasterLibrary and CloseMuiMasterLibrary and can clearly see that the CloseMuiMasterLibrary happen before my LCL destroy things are called. I will play around a little bit with it. But in the end I have to talk with Charlie (Maintainer of FPC-MorphOS) about this, how to solve this problem.
This explain also other crashes I experienced before (like the crash of CloseFont for example)
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.
I got my two 128 MB EDO RAM pieces for my Blizzard 1260 (with SCSI Kit), therefore I have now 256 MB RAM. Why I need so much RAM, easy, even a very simple LCL Program need more than 150 MB RAM to compile, of course I can compile in UAE but thats not the same 😉 Ok it needs 5 minutes to compile, but who cares, it works.
Compile a LCL program on a native Amiga
