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.
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.
The Hex Editor slowly gets into shape. Most important function, editing and Value showing. The Value is automatically showed in different types (as Byte, Word, LongWord, QWord) and even more important both endian styles(Big / Little). Later will insert also a function to insert a value as the combined types in both endian styles. For now I only need it for small files, so I load the complete file to RAM and then show it. Later maybe I make a viewer version for very big files, which work directly on Harddisk. But at the moment its not needed.
HexEdit 0.2
HexEdit 0.2
At the moment I need a HexViewer and sometimes also a HexEditor but even at Linux I’m not very satisfied with the functions with the available HexEditors. So I decided to write my own, of course I write it for Linux/Windows (there I need it) but now I always care about that it will also work for AROS. So I compiled it for AROS as well and it worked without any additional actions. At the moment its just a HexViewer. (use cursor keys for move the cursor, page up down to scroll a page, home and end jump to start/end, Tab change binary part to char part)
But I need Editing, search and replace and jump to special positions.
HexEdit 0.1
HexEdit 0.1
Deadwood announced a ALSA AHI driver for AROS Hosted which I tried today, the first version crashed AROS completely. But now the second really works very nice. I take out my mp3player again and it is working very nicely, debugging this way is much better ;-).
When I wrote the mp3 player I wanted to make a video with sound, but sadly I noticed the sound recording of RecordMyDesktop seems not to work, its all quiet the whole time. I tried some trick I found online, (direct alsa, pulseaudio and so on) but nothing helped its all quiet. Then I tried some other programs and finally I found one working kazam has not so many options but enough for my needs. So here is my first youtube video with sound 😉
The sound is a free one from youtube Hero Theme by MK2.
As I said before much better would be to link directly to the C LinkLibs instead of writing this wrapper libraries, in the past I always failed because of the autoinit stuff. But now when creating the libraries I learned a little bit more about how it work and finally I was able to make a statically linked connection directly from freepascal unit to AROS C LinkLib. And it works 🙂
Freepascal program links to C Linklib
I played a while ago a funny tiny game on my phone called 2048, really easy concept but makes fun to play. So I wrote an own game for AROS which is inspired by it really easy and nice to program.
Its called BinShifter Bin because of Binary numbers which results from it and shifter because you have to shift the blocks around. With the arrow buttons or cursor keys you shift all blocks to one
direction. If two blocks with the same number are stacked in this direction they are added together and you earn points. The maximum number for one block is 4096 (like the numbers of colors
of the original Amiga ;-)). The game ends when no movement is possible.
BinShifter 1.0 i386-aros
Bin Shifter 1.0
