EdiSyn on MorphOS, at least it does not crash anymore, but it need long time to start and the SynEdit does not show anything, Menu also does not work, hmm strange.
Some more strange things appear, the Edits does not show the contents if the edit cursor is active in it, when one leave the Edit, the test is visible, also the TextEditor and Scrollbars have some strange colors. But it become even more strange: When I start the m68k-amiga version on MorphOS it looks ok to me (also in WinUAE or on a Native Amiga 1200)
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.
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.
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.
I found out why some elements at Amiga/MorphOS are not shown (like the scrollbars and comboboxes) it seems that MUI has very tight size constraints usually MinHeight = MaxHeight. And MUI is rather picky, if you give a bigger place at layout hook, it does not paint anything. I do not understand why a Button needs this tight size constraints, maybe I want bigger buttons.. but ok, not a big thing.. I will try to implement that also in the AROS LCL and maybe should check how to use the LCL constraints.
Amiga LCL with working size constraints
The second good thing is that the crash at close is disappeared at Amiga OS, but at MorphOS its still there, so I guess the issue is not solved. I will write an other test program to test the dynamically creation and destroying of MUI elements. But in principle one could think about a lcl AmigaOS release (its already much more than the first AROS lcl release 😉 )
I played again a little bit with Lazarus/LCL and I was able to get the thing compile on a real AmigaOS 3.9 with MUI 3.8. The result looks rather the same as my previous tries in MorphOS.
But different from the one from m68k AROS it makes the double strange that all windows in the m68k AROS are fullscreen. A bug in Zune? Who knows. The size calculation seems to be different as in i386-aros LCL, the windows are smaller.
