Archives for Coding

Do it online

Posted by ALB42 on 16. Juni 2017No Comments

A crazy idea came up to me. Would it be possible to create a webpage with a nice javascript Editor which could directly compile FreePascal sources for all our beloved Amiga Platforms. The answer is certainly yes, I googled around to find a small package without too many nodejs, npm and such things, which always fails on my old server ;-). I found ACE which seems rather nice an easy to use. The rest is just some little php magic and of course the cross compilers, which I know already long time how to create and use and voila, ready to use webpage to create a simple (one file) Pascal application for all amiga platforms. I tried it on MorphOS, AROS and even native on an Amiga 600 with Vampire using iBrowse. Of course in iBrowse the editor does not work. I included a special page with a simple HTML textarea for such old browsers.

The compilation speed is much faster as a native compilation.

On MorphOS it runs much better of course the MorphOS OWB is even capable to show the editor, very nice.

It’s a little bit slow because it’s recorded via VNC, in reality it feels rather fast.

AROS was a little bit of disappointment for me. I downloaded the latest Icaros 2.2 especially to test this webpage. But sadly the editor does not show up. No Error message shown. I guess it’s some missing font problem, because when I change the theme the background color changes, only the text is not visible. It’s a pity. I had to switch to the old Browser interface which works nicely but I expected more.

A yes, you will ask where can I try this: here
With Javascript Editor e.g. for MorphOS
With HTML Editor e.g. for Amiga 68k

ECMAScript 5 MorphOS/Amiga

Posted by ALB42 on 3. Juni 2017No Comments

Compiled Besen for Amiga and MorphOS, some more small changes needed (mostly because for both CPUs no jit compiler is available). On MorphOS the it fails with a senseless error message: expected identifier found “”. when checking the position, no error to be found in middle of a parameter definition. Increasing the stack before compiling make it work, little bit strange, thats the first time fpc compiler need a bigger than normal stack (which is 256k defined inside the fpc code). It works nicely.
On Amiga the compilation was much less problematic, but the Exe do not work completely already gives error message on boot up about not initialized variable… most example sources only give this uninitialized variable error message, only this number guessing “game” works. Little bit strange, maybe some m68k compilation problem?

ECMAScript 5 on MorphOS

I downloaded the conformity test for ECMAScript 5 and let it run on AROS and the result is not bad: “Total tests: 1221 Passed: 1140 Failed: 80 Could not load: 1” to put that into perspective my current Firefox (52.0.2 64-Bit Linux) gets following result: “Total tests: 1236 Passed: 1098 Failed: 135 Could not load: 3”.


Posted by ALB42 on 2. Juni 2017No Comments

Today I found Besen by random 😉 “Complete ECMAScript Fifth Edition Implemention in Object Pascal”. If you do not know what ECMAScript is: usually it’s called JavaScript.
With very little changes it runs it compiles with FPC for AROS. 😉


To FPU or not to FPU

Posted by ALB42 on 28. Mai 2017No Comments

When I work on MUIMapparium usually I only work in Linux and test on AROS Linux-hosted. which is very convenient and fast. When starting the MUIMapparium I also tested at the end on every platform if it works and how is the speed. For the last two Releases I skipped this part, due to lack of time.

But yesterday I tried MUIMapparium on my Amiga 600 with Vampire and was shocked how slow it behave. The map moving is just not usable around a second reaction time. I downloaded/compiled older versions to check when this problem appeared. Deep in the back of my brain I guessed already that the fixed position calculation could be the reason (see here). Thats pure floating point calculation and a lot of them. I tested that on the initial implementation and it seemed not too slow, because for simple map moving and zoom only very two-three times this conversation have to be done, so the influence is not very big.

So why it’s now so slow? The difference is that before I tested with a bare MUIMapparium without any marker or tracks loaded. Marker only add a single conversation to the list. But Tracks need a conversation for every recorded (and maybe drawn) point. Remember the most GPS devices measure the position once per second, that means for an hour walk you get something about 3600 points (usually the GPS already strip them from “not moved” points, nevertheless you get around 1000 points). For NG Amigas with their massive computing power especially on the FPU side, this is not much of a problem, 1000 fpu calculation with some hundreds MFlops are just done some milliseconds.
But on Vampire it’s a different story, no FPU, it has to use the softFPU emulation of FreePascal. This raised the question: How fast is the softFPU emulation on a Vampire in comparison to a real 68060 / 50Mhz FPU. The Vampire integer performance is much higher than the 68060 (around twice as fast, see here) but emulated FPU, there is a lot of code needed to emulate that correctly.
I used two tests for that, a simple Mandelbrot algorithm, in single and double precision and the well known SciMark from NIST. Compiled with either with FPC SoftFPU emulation or the 68881 FPU support.

Mandelbrot results (Runtimes, shorter is better)

Test 68060/50 MHz FPU 68060/50Mhz SoftFPU Vampire SoftFPU
Mandelbrot single precision 0.12 s 9.53 s 3.81 s

Mandelbrot double precision 0.15 s 23.72 s 13.37 s

When comparing the SoftFPU times of 060 and Vampire you can see the 2-3 times I experienced before already. But the (often called “very slow”) 68060 FPU leaves the SoftFPU Vampire in the dust far behind it. (In fact the dust is already settled down again, before the SoftFPU finished the calculation). Of course the errorbars for the calculations with FPU are huge, the time is too short for a reliable time measurement, but a bigger calculation just would need ages with SoftFPU 😉 and the trend is nicely visible.

Next is the SciMark, it uses various real life floating point calculation, like FFT, matrix multiplication, monte carlo simulation, if you work in science you know that stuff, if not just believe me that is what science programs do all day 😉

SciMark2 results (MFlops, higher is better)

Vampire V600 V2+ 128 MB SoftFPU code
** ** ** SciMark2a Numeric Benchmark, see ** ** ** ** Delphi Port, see ** ** ** Mininum running time = 2.00 seconds Composite Score MFlops: 0.06 FFT Mflops: 0.03 (N=1024) SOR Mflops: 0.12 (100 x 100) MonteCarlo: Mflops: 0.03 Sparse matmult Mflops: 0.08 (N=1000, nz=5000) LU Mflops: 0.02 (M=100, N=100)

Amiga1200 68060/50 FPU code
**                                                               **
** SciMark2a Numeric Benchmark, see **
**                                                               **
** Delphi Port, see     **
**                                                               **
Mininum running time = 2.00 seconds
Composite Score MFlops:     2.26
FFT             Mflops:     1.18    (N=1024)
SOR             Mflops:     5.05    (100 x 100)
MonteCarlo:     Mflops:     0.86
Sparse matmult  Mflops:     1.81    (N=1000, nz=5000)
LU              Mflops:     2.41    (M=100, N=100)

So it just shows the same trend. Attention: do not compare this MFlops with the theoretically MFlops most speedtests show you (like sysinfo), you can see, how different the tests behave. It depends very strong on which commands are used and how much memory bandwidth is needed.

In conclusion it shows really nicely why the MUIMapparium with a track on a Vampire is so slow currently, because of the slow SoftFPU. Very sad that the Vampire still lacks a proper FPU support. We (ChainQ and me) believe that it is possible to optimize the SoftFPU performance maybe 50% faster or even double, or lets aim for the stars.. 10 times faster than now (I do not believe that is even close to possible at all). It would still be around 5 times slower than a 68060/50 Mhz FPU, for the people believing a SoftFPU implementation could be a replacement for a native FPU in the FPGA.

That means, if it reacts very slowly on Vampire, just remove the track. 😉 I will work on this, reduce the needed calculations, (by using more memory), see at which places I could possibly go down to single precision (not much hope there ;-)) and of course reduce the number of points, in principle a LOD on the Zoomlevel.

if you want to test SciMark you can download the FPu and SoftFPU exe from my server:SciMark FPU Version, SciMark SoftFPU Version. (I would be very interested in 68881/2 Results)

MUIMapparium 0.4

Posted by ALB42 on 26. Mai 2017No Comments

Working more on the Trackview to show the height and speed track, added a simple Popup Menu and a Data Reader. In the beginning I wanted to use the Bubble function of MUI to show the coordinates, but it flickers like hell if you move it over the map (because you have to destroy and recreate every time) and it makes very bad redrawing errors. On AROS for example when the bubble is over an other part of the window, the background behind it will not repaint, when the bubble disappear. On Amiga the background of the window is visible on the edges instead of my curve background. Also added a fine grid for better visibility of Values and heights, still fixed but maybe later can be disabled via menu.

I implemented a on screen (on-map) menu for zooming and to show the side panel, so do not need use the menu. I did that already for Mapparium but there only released for the special ARM version. There is also a key control available, the + and – keys can be used for zooms and cursor keys for movement.

I guess it will need one or two more version for MUIMapparium to reach the features of Mapparium but I guess it will be MUIMapparium will takes the Mapparium place (and Name) in the end.

MUIMapparium 0.3:

Reminder you can use the Example GPX file from the Mapparium page also.

MUIMapparium 0.4 with track view

Playing with locale

Posted by ALB42 on 22. Mai 2017No Comments

Still playing with locale settings on Amiga systems. FreePascal offer a possibility to care about international settings like decimalseparator, date formats and currency symbol. So I looked a little bit into and the system is comparable, still much work, so I’m not sure if really put to every start of a program, or maybe it would be better to put it to a separate unit and you have to include and invoke it by hand. We will discuss that.

Testprogram with Germany, USA and UK Locale Setting

Starting the same test program 3 times and changed the Locale Country setting in between. (For me rather funny that the currency format for positive and negative Values are so different not so nice if you have them in a table) But so far it works very nicely.

Some Curves

Posted by ALB42 on 18. Mai 2017No Comments

LCL has powerful packages for example the Chart component (or the Edit component with Highlighter). MUI already have some, but not so powerful and not available for all platforms (especially ARM-AROS and AROS64). I try to keep on the included basic classes to keep it compatible.

I used the very powerful TAChart component in Mapparium to show the Height/Speed trace of a track. Of course for MUIMapparium I also want to have that, so I started to implement a plot class for MUI. Not so powerful but already very nice with two Y-Axes, Zoom and Autoscale.

MUI Plot component start

It already works rather nicely, as first approach can be used like this.

I designed it already in a very abstract way in principle a TPaintBox for MUI and based on that the Plot class, that means I can use them in other programs as well.

MUIMapparium 0.3

Posted by ALB42 on 14. Mai 20172 Comments

Activated the localization for MUIMapparium currently only for english and german (of course ;-)) implemented also the local library unit for AmigaOS4 so localization is available on all platforms.
I also activated the AREXX interface currently only two commands are implemented: goto lat lon [zoom] to jump to a position and addwaypoint lat lon “Name” to create a waypoint. The Portname is the same as for Mapparium an example script can be found in rexx folder. The AREXX port does not work for AROS, Zune has no AREXX support currently.
I tried to compile it on AROS64 sadly the program did not work, it just freeze. Little bit strange sometimes it start but crash directly. I tried some other programs on AROS64 and they work rather nicely so why MUIMapparium not. The difference was easy it uses threads, finally I found the solution, the Critical Sections in FreePascal are mapped to SignalSemaphores of Amiga. In contrast to other OS the SignalSemaphores are not just simple pointers but a complicated structure. The given size there was ok for 32 bit Systems but for 64 bit the structure is much bigger. I included it for that release maybe someone want to try it 😉

MUIMapparium 0.3:

Reminder you can use the Example GPX file from the Mapparium page also.

MUIMapparium 0.3 on AROS x64

MUIMapparium 0.2

Posted by ALB42 on 1. Mai 20172 Comments

Had some time to work a little bit on MUIMapparium, mainly implemented way points and tracks including loading and saving, same formats as Mapparium. Due to multiple requests I created a OS4 version again, but I have no way to test it. Still it’s only a very early version of MUIMapparium.
MUIMapparium 0.2:


MUIMapparium 0.2 for Amiga


Posted by ALB42 on 30. April 2017No Comments

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.