I checked the ASL.library units of MorphOS and Amiga 68k against the official C includes of the SDKs. Especially the TFileRequester structure was always a little bit trouble because the old Amiga asl unit still used the old field names rf_* but from V38 of the Library this fields are all names fr_* and some other tiny dame differences (e.g. Dir vs. Drawer). In AROS and AmigaOS4 I only added the newer names because here I do not have any “old” code. This resulted in a big inconsistency between the platforms and need ifdef’s in the final programs. To prevent a direct breakage of the existing sources (e.g. LCL, MUIMapparium) Amiga and MorphOS have both field names in the structure (as case). The aim will be to remove that ifdef’s from the sources.
Finally found some motivation to work on the route display not so difficult at all. But the search for the route I need to think a little bit more. Until now it only shows the saved orders. On double click it jumps to there and also shows the described route points in a different color. That should be ok for now.
Due to user wishes one can now change the color of each track and route individually, which is also saved to the GPX File. Routes and Tracks in GPX have an extension area where you can add own properties without violating the GPX format, which is very nice. The Routes and Track property window have now a Color Button next to the Name to choose the color of the feature (you have to save that before the change is visible in the map).
In principle it would be nice to have the color next to the name in the Track/Route List as a little colored square (like I did for track plot axes). But I’m not sure if and how that is possible at all for such a list, without creating a selfdrawn one.
Besides that I implemented that MUIMapparium remembers the position and open status of the Statistics window, seems some user like to keep it always open to observe the loading status or something like this.
Do you read journals…? I’m not. I seldom read such things and if it happens then science related. But there is still an Amiga related journal the Amiga Future. I saw it once or twice at the Amiga meeting here in Berlin but never actually cared about. But maybe the next issue would be something worth to buy 😉 Especially the one article which already has a preview there.
The very first version of the SoftFPU called femu 0.1 is released and of course I want to try how good (and how fast) it works. It is the first version so no one should expect wonders. It comes in three versions, 030, 040 and 080 (why there is no 020?). In principle I wanted to try all of them but only the 080 Version works on the Vampire. the 030 Version crashes directly, the 040 crashes on first FPU command. So I have stay with the 080 Version.
First again my Mandelbrot program. (sadly the picture output does not work currently, not big endian compatbile 😉 so I can not check if the result is ok)
Mandelbrot results (Runtimes, shorter is better)
Test
68060/50 MHz FPU
68060/50Mhz SoftFPU
Vampire SoftFPU
68030 68882/50 Mhz FPU
68030 SoftFPU
Vampire Femu 0.10
Mandelbrot single precision
0.12 s
9.53 s
3.81 s
2.14 s
38.03 s
11.14 s
Mandelbrot double precision
0.15 s
23.72 s
13.37 s
2.31 s
71.87 s
10.31 s
Thats already rather interesting, it seems the femu calculates everything in double, which makes sense because the FPU always use extended. There was a hint already in the manual that femu needs the double precision math libraries from the system. It seems that femu is just a wrapper to guide the TRAPs to the libraries. Not a bad idea actually. In double it’s even a little bit faster than the FPC SoftFPU, not bad, as guessed in the FPC SoftFPU is a lot of optimization potential 😉
Next the Scimark test:
SciMark2 results (MFlops, higher is better)
Vampire V600 V2+ 128 MB FPU Code femu 0.10
Mininum running time = 2.00 seconds
Composite Score MFlops: 0.08
FFT Mflops: 0.04 (N=1024)
SOR Mflops: 0.12 (100 x 100)
MonteCarlo: Mflops: 0.05
Sparse matmult Mflops: 0.09 (N=1000, nz=5000)
LU Mflops: 0.09 (M=100, N=100)
Vampire V600 V2+ 128 MB SoftFPU code
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)
This SciMark tests are usually done in Double precision so we see the same trend as in the Mandelbrot. It’s very nice that this tests run without any problems already kudos to the coder, it works.
To check for more FPU commands I took out my real time raytracer (ok on Amiga not that real time anymore :-P) changed that to a saving routine of a single picture and compiled for FPU and SoftFPU. It works and the picture looks very nice, as it should be:
TraceRay FPU on Vampire with femu 0.10
As visible in the picture it needed 730 s to render that picture (as I said, not really realtime) with fpc SoftFPU it needs 280s the 68030/68882/50 Mhz needs 224 s. (sidemark on my AROS i386 box that image needs 0.2 s) and for all cases the picture looks good. The femu does what it promised, not actually very fast but reliable. A little bit disturbing of course is the freezing mouse, when the TRAPs appear. But here the coder of femu can’t do anything, as far as I understood he works closely together with the Vampire developer, so maybe he get a faster (or even not-) TRAP mechanism for the emulation in a later Vampire Firmware.
At the moment I still would prefer to use FPCs SoftFPU for MUIMapparium because there the Mouse will not freeze so the GUI feels more snappy.
Just playing around with some 3D Mathematics on a real Amiga 1200 with Blizzard 1230 IV with 68882 (50 Mhz). But the main problem is not the calculation but the drawing. I only use graphics.library functions to be system and RTG compatible. (It uses a a MUI Interface).
I know, not really impressive 😉 but I like it, interesting to learn some 3D stuff. And even a Hires Lace screen with 32 colors, fast enough to use.
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)
Changes:
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 freegeoip.net (old one is too slow currently)
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.
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.
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 http://math.nist.gov/scimark **
** **
** Delphi Port, see http://code.google.com/p/scimark-delphi/ **
** **
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.
