Archives for Amiga

MUIMapparium 0.5

Posted by ALB42 on 9. Juli 20173 Comments

I decided to release the next Version of MUIMapparium even not all features are finished as I planed just to get the bugfixes out. Routes (calculated directions) can be loaded from GPX and showed on map. But I did not implement the route finding and direction command showing until now. Especially the Track curve plot was still very buggy, and of course I described in a previous blog post the pixel to position calculation which is now much better, much more precise but also much slower than before, with FPU it does not make big difference, but with SoftFloat not really funny. Routes and Tracks are now pre-calculated for the current zoom level. If the zoom level is very small and the track therefore not really good to see, only some pixels wide, it does only paint some points of it, which makes the overviews much faster. Still, with SoftFPU on 68k it still will be too slow if you have some Tracks/Routes. The drawing of Tracks/Marker/Routes can be completely switched off in Menu or buy a FPU 🙂 The package for Amiga68k does contain a FPU and Non-FPU.
I also created a little GPX file with a Track, some Markers and a Route to test the features. (Even you can use any GPX/KML/KMZ/FIT File you can find on the Internet as well)

  • Bugfix: imperial units
  • Bugfix: key mapping
  • Bugfix: 2nd track curve drawing
  • Bugfix: Date/Time loading from GPX,KML,KMZ files
  • Level of Detail for Tracks
  • Precalculation of Trackpositions (Speed optimization for NonFPU systems)
  • Route drawing
  • Marker in Plot, shows also a marker in the Track
  • Turn off Marker, Track and Route drawing via Menu
  • Define Directory for Images via ToolTypes: e.g. DATAPATH=DH1:TmpDir
  • Change find IP to (old one is too slow currently)
  • FPU Version for 68k
Downloads: MUIMapparium Page


MUIMapparium 0.5

Amiga Linux the next day.

Posted by ALB42 on 3. Juli 2017No Comments

Of course the freepascal compilation did not work, still needs some link library and stuff. (Hint for later at least libc6-dev and libgcc-5-dev is needed) I restarted first a plain compilation and hmm it still runs 😉 the tests will need to wait a little bit. Besides that of course I played more with the system, of course its even slower that way because the compilation is running in parallel. Installed some packages I need on there, telnetd for example, sshd just slows the poor 68030 to much down. For file transfer I want to join it the normal NFS network I have already. But when installing nfs-common I was really shocked it has python as recommend, really? Python for NFS? On my normal computer I do not care it’s usually there already but on Amiga, space (and more important installation time) is short 😉 so need to with “–no-install-recommends” But my personal opinion is when a simple network file protocol from the early years of Unices pull the most hyped script language monster (15.5 MB additional crap!) then there is clearly something wrong in your package system.

IPv6 on an Amiga

As you can see the compilation still runs 😉 (the Assembler as runs currently on other TTY) and even IPV6 works! An Amiga doing IPV6, welcome to 21. century (no Amiga OS is currently able to do that). The system runs rock stable (uptime already 28 hours) even I stress it with parallel installation and other changes and let the compilation run. Very nice and stable just a little bit slow.

ALB goes crazy episode 9842: Linux on 68030 Amiga

Posted by ALB42 on 2. Juli 20172 Comments

To help ChainQ with the FreePascal for m68k compiler bug finding I installed a qemu-m68k on my server together with a chroot environment to let the FreePascal testsuite run. An ChainQ really found a lot of bugs. I also improved the chroot environment. The number of fails falled down from 160 to 34 which is a good value more than i386 (around 20) but better than PowerPc (around 40) 😉 already a nice achievement. But I thought it would be even cooler to start the test suite directly natively in a m68k Linux environment. (also qemu-m68k maybe has some bugs :-P) The only real hardware I have available for that is my Amiga 1200 with 68030, luckily it has a MMU so Linux will be possible. (The Amiga 600 with Vampire does have no MMU therefore Linux is not possible to use) Informations about this topic are very hard to get and most of the links are dead today. So in the end I compiled the kernel (3.16.7) on my own and created a initramfs by hand. For initial root I used the chroots debian environment I use already for the fpc tests. But systemd made me much headache, it was much easier to write a own little init script. Finally the systems boot and even the PCMCIA card works, I can SSH to that server.

Linux on a Amiga 1200 with 68030

The next is installing FreePascal and try to run the compilation and finally the test of course. There are some unexpected problems here. Usually the latest FPC from trunk requires the latest stable FreePascal version, that means at the moment 3.0.0 or 3.0.2 but both can’t compile the trunk because some features missing in 3.0. I tried to merge them from the trunk but failed to many things missing and not easy to identify which else should be merged. So I will use the 3.1.1 as starting compiler (and ignore the warning that this is not supported 😛 yeah I’m a real outlaw) sadly it also have some problems I have to check later. For first try I just start the testsuite with the compiler cross compiled on my other Linux (x64) computer. The testrun started today at 22:15 will it run completely and if yes how long will that need? a week? 🙂 We will see.

Compiling/Testing FPC on m68k Linux

An replacement

Posted by ALB42 on 29. Juni 2017One Comment

My Blizzard 1260 card is broken a while before, I sent it to someone to repair, but this will need time. That means my A1200 is rather useless currently. Which is not a nice situation. I decided to buy a Blizzard 1230 IV with 68882 FPU. Later when my 1260 is back maybe I can revive my other Tower A1200 to use that card. The card arrived today amazing it is even with the original package and manual, I did not expect that, very close experience to when I bought my Blizzards back in the days.

Blizzard 1230 IV in Original package

Now I can make some additional tests about FPU speed and compatibility of FreePascal. First again the Mandelbrot test again together with the old Values:

Mandelbrot results (Runtimes, shorter is better)

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

Mandelbrot double precision 0.15 s 23.72 s 13.37 s 2.31 s 71.87 s

and again the Scimark test:

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
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)

Amiga1200 68030+68882/50 FPU code
Mininum running time = 2.00 seconds Composite Score MFlops: 0.29 FFT Mflops: 0.15 (N=1024) SOR Mflops: 0.56 (100 x 100) MonteCarlo: Mflops: 0.13 Sparse matmult Mflops: 0.29 (N=1000, nz=5000) LU Mflops: 0.34 (M=100, N=100)

The Result stays very bad for SoftFPU even the 68882 is around 5 time faster than the SoftFPU on a Vampire. That fits also to the results I saw in the apollo forum, someone showed a
SoftFPU emulation result of AIBB FMath Test resulting in a runtime of 9.73 s, my new 68882 solve this test in 1.51 s. That means the 68882 is 6.5 times faster than the Vampire with SoftFPU emulation and this time its independent from FPCs SoftFPU implementation, seems the FPC SoftFPU is not that bad actually.

Show me some routes

Posted by ALB42 on 28. Juni 2017No Comments

Working again a little bit on MUIMapparium. I want to include some more features before the next Release 0.5. I included marker for the plot which is then also shown as little triangle in the map. I’m not really satisfied with the colors and visibility of the current open track and marker for the point maybe I get a better solution later. The marker is atm. only one pixel wide, in principle it would be possible to make it 2 pixel or 3 pixel, but that looked a little bit too massive.

MUIMapparium with Track Marker

Another thing I wanted to include for the next version are calculated routes and maybe also photos with EXIF tags. If this is done MUIMapparium has the same Featureset as Mapparium, even a little bit more. I started with Routes which is not very difficult, some routines even can be reused from tracks drawing and so on. It only loads tracks from gpx files currently (created by Mapparium for example). The creation of a new route will be the next step.

MUIMapparium with a Route

Also visible in the image is the new possibility to disable all Marker, Tracks and Route drawing. Helpful if you have many items and want to concentrate on the Map or so (or just to increase the speed).

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

Fix it Felix…

Posted by ALB42 on 5. Juni 2017No Comments

I found a holder for my Vampire in the Amiga 600.
The current solution are just two little feet attached with some tiny screws.

Of course two feet always wiggle around and after transport the Amiga 600 I have to open the case and press the CPU adapter to the right position.

The holder on Thingiverse should improve that. To spoil the result it works, if it is stable on some transportation, we will see ;-).
I guess the holder is meant to use without the ROM chip holder. The holes one the lower side to attach to the mainboard are a tiny bit shifted. Therefore I had to drill some new holes. Luckily the holder has enough spare place for the Vampire so the whole thing can be moved some millimeters.

The holes for the upper part on the right side are missing (or moved to the end of the lower part, a little bit strange). But not a big problem because I used tiny self-drilling screws. It seems very tight and fixed now. I shaked the whole Amiga 600 a little bit still seems perfectly in place. We will see on next Amiga and RetroComputer Meeting in Berlin when I carry it around a while.

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”.

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:

Downloads: MUIMapparium Page


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

MUIMapparium 0.4 with track view