Yesterday I was at the Amiga and retro computer meeting here in Berlin, always nice to be there and talk to the people. ChainQ was also there so we worked a little bit on this strange WBStartup problem on MorphOS. As some already mentioned in the comments to MUIMapparium, it is not possible to start fpc compiled programs at MorphOS via an Icon. The programs just do not start directly freeze, the reason is simple, when starting via Icon the WBStartup Message is sent to the application via an MsgPort at the Process structure. Freepascal waits for this Message, which never arrives. After some trying we found, that the needed structures and functions in fpc are in good shape so not the root of this problem. The problem appeared when ChainQ changed the startup code from a assembler one to a pure Pascal startup code. So my guess was that it somehow relates to the needed symbol inside the executable, which defines it as a MorphOS executeable __abox__. Of course I do not have much knowledge about it, just a wild guess. But it turns out that this was quite right. The first problem is that I used an older version of vlink, which seems to have a bug and removed this symbol (because never used). After an new compilation of vlink the __abox__ symbol is there but still it do not work. ChainQ knows a little bit more about this stuff and also knows whom to ask in the inner circle of MorphOS developer what could be the root of it. Some strange things I was able to see, the program I started stopped when starting via Icon. But via TaskManager you can see, two of them are started. An other thing with Snoopium you can check when the program does at the start. Especially the OpenLibrary function is interesting in this case. You can see how the program tries to open the ppc.library, which I learned now, is a sign that MorphOS thinks that this program is an PowerUp executable, which explains the odd behavior. In the end the solution was not so difficult, FreePascal did not set symbol type and symbol size as expected by MorphOS. (The size is important because the __abox__ symbol should point to a longword with value one) It appears FreePascal already have a function to care about such things, which only have to be activated for the MorphOS compiler. Finally it’s fixed again. Thanks for the help.
Some days vacation, used the evenings in hotel to re implement Mapparium in native MUI and with fpimage for loading the PNG files and Drawing. The Drawing is faster than LCL (the LCL wrapper is huge, already slow) but still rather slow. At last I wrote a own Drawing routine which made it fast enough to start it on a native Amiga with Vampire A600. And it’s nicely usable even without FPU but of course on a RTG Screen.
Tried some (Integer) Speedtest, some people asked me about. Of course I’m also interested if my feeling (double 060/50 speed). I used some code from Benchmarks Game. Especially the tests: fannkuch 10 and BinaryTree 15. (68060/50Mhz= A1200 with Blizzard 1260, MorphOS = MacMini 1.4Ghz, UAE/AROS/Linux = Athlon FX 8120 3.16 Ghz)
Speed rel. to 060
Speed rel. to 060
MorphOS 68k emul
So my feeling was more or less right, it’s around double speed to 060, so it’s a nice step but far far away from UAE. More interesting for me would be FPU processing but at this point the comparison would be very dramatic and a little bit unfair because Vampire still have no FPU support (even it’s everywhere announced, but seems even next version will not have FPU).
I bought a neat eat toy for me. An A600 already equipped with an Vampire processor card. A Vampire is an FPGA based CPU card for Amiga 500 and Amiga 600. A while ago I thought already about to buy a Vampire card. The delivery times for it are very uncertain and seems in the order of 6 Month. I even would need to buy an A600 first, I was really to lazy to do such step with uncertain future. But I found an ready to use one one ebay. Maybe a little bit more expensive but thats fine by me, still much cheaper than a 68060 or PPC card. 😉 The capacitors are exchanged but the audio sounds strange, but not a big problem for me. Mainly I’m not interested in the speed but but in the GFX Card which comes with the FPGA on Vampire. Its the only way to get a 24bit GFX card into a keyboard Amiga (except the very seldom BVision for A1200). Of course my for me very interesting if freepascal and it’s programs work with it and good news on this side, it’s working nicely. The only problem (like on my A1200) is the slow harddisk which makes it much slower then UAE but as I read the next firmware should improve that a lot. Of course a screenshot (done with a screenshot program I wrote in FP-IDE directly on my A1200 some weeks before)
Didn’t have much time today, so I only show a cute little program to learn typing, out of the box compiled for AROS TappyTux, also with Mathematics. still not perfect, needs a little bit work, (sometimes the text is outside), it throws 2 hammers and so on.. but even so very neat.
Playing a little bit with loading routines for vector formats and found the amazing fpvector package. It contains also a nice test program to test loading of files. It works already very nice loading of .svg and .dxf Files. For example .odg files does not work some string to float problem. Also the drawing works rather nicely but also shows some problems with the filled polygons. Worth to try to compare with the Linux version.
Still playing with raytracing (so 3D calculations without GL or so) and other 3D Stuff. Magorium converted a nice little raytracing program from C to Pascal. It creates a random scene and calculate it with high precision. It makes a nice pictures. It is using SDL for display and threading, it seems the SDL Threads do not work, so I changed that to use Pascal Threads and now it is working nicely. Again a nice program for SMP 😛 already ready to use multiple threads (at Linux it runs fine with 8 Threads)
After long time I did again a little bit raytracing stuff, magorium found some source, I reviewed some of my old sources. I would be a perfect thing for the coming AROS SMP, ok I guess it will not appear so soon but it’s really a nice thing.
Notice the multicolor shadows and the multiple refelections.
I never worked with SDL before so I searched for a little tutorial for it and came across a YT video showing SDL game making with freepascal YouTube Link.
I tested the source and applied the special changes for AROS (basically to initialize the SDL and other link libs) and it works really a nice tiny game. I will look more to source to understand the SDL behind it. But first of course a little video
The MUI LCL widgetset also got accepted for the official Lazarus repository.
That means the next official Lazarus release will also contain the support for all Amiga Systems and the MUI Widgetset. Sadly the only one usable with the released 3.0.0 FreePascal is i386-AROS. m68k-Amiga has a serious bug, for MorphOS the resource support is missing. Both problems will be fixed for next FPC release 3.0.2. All Other platforms (OS4, ARM-AROS, x86_64-AROS) have to wait until 3.2 because their support was added after 3.0 split. Of course one can use the 3.1.1 compiler for all platforms already, as I usually do and release to public.
But it would be very nice to just install Lazarus via your default package system (deb, rpm, whatever) install your Amiga cross-compilers and binutils(with vasm and vlink it’s really easy) and one is able to use the lazarus as IDE for your Amiga LCL programming.
Today I also got write access to the Lazarus repository, that means I can continue to work on the implementation directly on the official repository.
Already tested and fixed some tiny problems. I will continue to test it on week end, seems there are some new problems inside, at least some of my test codes does not work.