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
The flickering is much better, the picture was painted too often and the message loop was polled too seldom. Optimized this a little bit, now it happens very seldom. When I started this tests first I implemented a simple Speedtest which does the same calculation for one second and then count the successfully calculated pixels.
So of course would be nice to have it also in this graphical server and optimize the number of pixels requested from each client. I noticed the Amiga 1200 with 68060 50Mhz only finished 3-4 Pixels per second, I know it is slow, but that slow. (Besides this I’m surprised how fast the MacMini with MorphOS is, nice :-)) But then I remembered that the m68k freepascal does not use the FPU. By default it uses softfloat routines, which of course are very slow. But my automatic compiler server also compiles the FPU version of all units (enable at compiler with -Cf68881 and use FPU compiled units). The fpu compiled version is much, much faster now 200 px/s. Wow now the amiga really add some pixels to finished image. (Before also some, but less than a line ;-))
Speed test of the „Amiga Cluster“
It should be noted that the 192.168.0.122 (and 127.0.0.1) is a Computer with eight cores but only one is used here (in fact, two because 127.0.0.1 is AROS hosted on the same computer), I didn’t implement multicore threading.
I played again a little bit with networking things, especially on different platforms. Very nice that the most sources now compile out of the box at Linux, AROS, Amiga and MorphOS only very little ifdefs inside, and even they could be omitted by extending the Amiga-like-RTLs with some unix functions.
I wrote a little Lyapunov calculation program which sends the pixels to calculate via network to other computers to let them calculate. Lyapunov is very good for such things because it has very little inputs and results but rather long calculation time per point.
I compiled and run the client for all platforms I have available currently:
- i386-AROS (Linux Hosted – AMD FX 8120)
- powerpc-MorphOS (Mac Mini)
- m68k-amiga (Amiga1200 68060/50)
- x86_64-linux (AMD FX 8120)
- i386-linux (Intel Atom 230)
- arm-linux (Raspberry pie 1)
All compiled from the same source.
The Server and Image Viewing is done at AROS.
The power of Freepascal/Lazarus at its very best.
The white pixels are already send to some client but the result is not arrived.
The image is flickering a little bit (therefore in the movie sometimes no image to see) because I didn’t care much about the image plotting. I’m not sure why the image is flickering maybe the network communication take too much time so not enough time to draw the image.
Working on the HexEdit and a little bit documentation especially MUI. Also updated the online documentation.
I created a archive of my complete LCL for m68k AmigaOS 3.x. Much things already working (all PaintEvent things does not work, so Labels, Panels and so on does not appear, but should also not crash).
So if anyone want to try Lazarus LCL on a real Amiga or UAE here is the archive, be careful its 55Mb and you will need at least 16 Mb to compile the examples, for bigger programs you might need even more.
Download Amiga LCL 0.1 alpha
for more informations read the „ReadMe“ inside the archive.
