When calculating the statistics value for the track export I thought it would be nice to have them for the normal Tracks Properties Window as well and also repaired the color indicator for the right and left axis for MUI (in Zune it worked).
With such a nice weather I drive a little bit more bicycle, therefore the track function of MUIMapparium is more interesting at the moment.
First of course the export I added for the Route also is useful for the track and there even more, because we can print out some additional informations about the track.
Depending on the Program recording the track the data can be very noisy so I added a simple smoothing function.
During my vacation two new Versions of Vampire Cores are released. One (2.7.1) only adds more serial numbers so no actual core changes and the second (2.8) has some bugfixes. One Bugfix is called ‚- minor FPU fix‘, sadly no more information what that means. I heard the rounding issue is solved and MUIMapparium (FPU-Version) should work now, so let’s try that.
But sadly MUIMappaarium still shows nothing and that is because the rounding issue is still not solved in this core (as you see in the picture), also the the precision problem persists. So I’m not sure what they fixed in this version and what happened with the MUIMapparium fixes they showed before 🙁 More waiting.
I just found out you can turn off the FPU with „VCONTROL FP=0“ sometimes it work, sometimes not (just crashing, if this because of my sloppy power on the Vampire or just bad timing, who knows). But after it you can start FEmu as with 2.5 and the testcodes work again. Also MUIMapparium FPU Version is working :-D.
In principle that would be the better alternative to the current situation, implement single precision inside the FPGA and trap the rest, which can then be covered by FEmu. Would make Quake and Demos and so on fast, but would not violate the IEEE 754.
In the current situation Amiga (Vampire) is not anymore IEEE 754 compliant. The Double format is now something like 24 bits significant (like IEEE Single) with 11 bits exponent (like IEEE double) because it can still go to 1e308 but the significant precision is much lower as shown before. Also strange if you multiply two big numbers to produce an overflow for example 1e200 * 1e200 in double precision that would give „+Inf“ or an exception, but Vampire FPU shows 1.8e+308 (something close to the max Double Value) and you can continue to calculate with that.
I played a little bit more with the Vampire FPU the yesterdays example shows an other interesting effect, the calculation of a * 1.3 shows an incorrect result. There is some problem in the last places when comparing with 68882 A1200 or 68060 UAE.
Let’s dig a little bit deeper into that, test how well the double precision calculation works. MUIMapparium needs Double precision everywhere, I tested to make it single but the calculation really get very wrong results (Eiffel tower somewhere near London, such stuff). To test double precision we multiply a very small value to 1 very often to see if it correctly handle the bits. for example like this:
program testfpu;
{$mode objfpc}
var
i: Integer;
b: Double;
begin
b := 1;
for i := 1 to 100000 do
begin
b := b * 1.0000000001;
end;
writeln(b);
end.
as you can see we multiply the 1 in b with 1 and a very little bit more, and this little bit more is just over the single precision limit. How the result look like:
| Vampire 2.7 | 1.0000000000000000E+000 |
|---|---|
| Amiga 1200 68882 | 1.0000100000502183E+000 |
| Linux x86_64 | 1.0000100000494698E+000 |
ehm.. no Vampire thats wrong. Seems it does calculate all FPU calculations in single precision, so even they repair the rounding problem MUIMapparium still would be not usable.
Btw. I tried the same thing with the FEmu back in the days and it worked, as expected.
So maybe thats also the reason for the very good benchmark results… you make the calculations in single instead of double of course you can be much faster (and the original 68k FPUs calculate everything in extented so even more precise). I really think about to go back to Gold 2, it was slower but reliable.
As always the downloads: TestFPU3, TestFPU3.pas
The new Vampire firmware is released V2.7 which contains a Hardware FPU in the FPGA (some seldom 68881/68882 commands are still emulated, like the 68060/68040 also do) but nevertheless, thats very nice for my MUIMapparium (you remember the problem?). Of course I flashed directly the new version, first the bad news, it’s VERY unstable for me, it’s said it needs some soldering because there are some errors on the early Vampire cards which make the power supply to the FPGA bad… something like this and I’m affected with that … so it’s a little bit annoying to work with it because there are drawing errors on the screen and it crashes often. I reduced the screen resolution and ended all background program which made it much better. But nevertheless to really try it out I have to wait until someone fix my card. I can’t do that myself, most scary thing in the world a coder with a screwdriver let alone a soldering equipment :-P.
But this was not the topic of this post. I tried MUIMapparium FPU version on my new Vampire 2.7… good news it starts does not crash, bad news the map stays empty. The same Executable worked well with FEmu (I checked especially before I flashed the new one) on the old Gold 2 and still work in UAE. But the FPU calculation seems to work because the mouse pointer movement shows reasonable coordinates. I was a little bit surprised because even the GUI in the map window was gone. I checked the code ah yes there is a tiny floating point calculation, fine let’s see whats that. An my guess was right it is the floating point calculation, the Button size is calculated by the Font Size * 1.2 to have a little bit more space around it. After adding some debug output it seems that the floating point calculation works well but the rounding always return zero, so I wrote a little test program to test the rounding here the outputs of the testprogram in my setups:
| Vampire 2.7 | Amiga 1200/030/68882 | UAE 68060 emul |
|---|---|---|
a := 5 = 5 a * 1.0 = 5.000000000E+00 Round(a * 1.0) = 0 b := a * 1.3 = 6.499999523E+00 Round(b) = 0 Ceil(b) = 7 Floor(b) = 6 Floor(b) = 6 press enter end |
a := 5 = 5 a * 1.0 = 5.000000000E+00 Round(a * 1.0) = 5 b := a * 1.3 = 6.500000000E+00 Round(b) = 6 Ceil(b) = 7 Floor(b) = 6 Floor(b) = 6 press enter end |
a := 5 = 5 a * 1.0 = 5.000000000E+00 Round(a * 1.0) = 5 b := a * 1.3 = 6.500000000E+00 Round(b) = 6 Ceil(b) = 7 Floor(b) = 6 Floor(b) = 6 press enter end |
Na? who spots the difference. Funny that only Round() have this problem but ceil, trunc, floor not. This also explains why MUIMapparium shows no maps at all, if all is rounded to 0. Ok I have to wait until they fix that… yeah I could replace all Round(a) by Floor(a+0.5) but why should I do that, here is clearly something broken in the FPGA.
You want to try on your own computer – Exe for m68k with FPU: TestFPU and the source: TestFPU.pas
A little bit delays, but as always the summary of last year. Due to personal circumstances I have only little time for these things and also not much mood. I hope this will clear up through out the year.
But back to the review. The year started as claimed in the last summary suggested. The MUI-LCL was accepted to the official Lazarus repository and also did some (little) improvements of it. Sadly I always hit the border what MUI can do so not much advance here.
Charlie improved FreePascal and Frank Wille improved vasm and vlink to support section linking for the Amiga Platforms. This decreases the file size very much. Finally vlink and vasm became the default assembler and linker for Amiga68k, MorphOS and AmigaOS4
FPC for Amiga systems got it’s own Subforum at Amigacoding.de and in the beginning there were some discussion, sadly it slept in again.
Magorium played around with SDL stuff at AROS with FPC and I also used it to bring a gaming tutorial source to AROS. I’m always interested in nice 3D routines or even realtime raytracers. I did before some coding about it but also this year.
Over the easter holidays I was on a trip, and I took my raspberry pi with an attached touchscreen and keyboard with me. Of course with AROS arm installed. Therefore I was able to code at the evenings in the hotel. I started to make a new approach for Mapparium. Mapparium is a nice program (I use it mainly to depict my bicycle tours recorded with my GPS device or iPhone) but the GUI ist still rather clumsy because MUI/Zune does not like this direct placement of positions. On a native 68k Amiga it become very slow because of this huge LCL Layer. I decided to write a native MUI/Zune application, as I did before the ZuPaPlayer, again to learn a little bit how to code MUI and also to fix some serious problems I found in Mapparium. The New Version is called MUIMapparium and went through several releases until the current 0.5 release. MUIMapparium got an own Release page. It still does not have the same feature set as the LCL Mapparium but it works much more smooth, really nice even on a native 68k Amiga especially on a Amiga 600 with Vampire.
Speaking of Vampire, I bought a complete Amiga 600 with a Vampire V2 card, really nice piece of hardware. Very fast (the card just keep popping away from the chip where it should be attached). The only drawback is, that there is no FPU included in the FPGA emulation (so it’s more like a 68030/68020 than a 68040/68060 which has built in FPU). For my programs thats not a big problem, there is a SoftFloat option in FreePascal and it works really well. I never thought about the speed of that routines. Yes, I knew they are much slower than a native FPU calculation but I had no idea how much. Later someone released a FPU-emulation software femu which improved the situation a lot. But still a lot to improve there. I heard that the next released core should have included some more basic FPU function and the femu is somehow more connected to the FPGA. I guess they build a way to prevent the Trap which appears on every unknown FPU command and eats up a lot of time. But I have no idea if this is true and this will ever be released, In fact I doubt it a little bit, seems the whole project is sleeping or so. Just to depict that core releases from Vampire:
GOLD2 2017-01-23
GOLD 2016-09-05
SILVER9 2016-08-03
SILVER8 2016-07-29
SILVER7 2016-07-10
SILVER6 2016-05-16
SILVER5 2016-05-06
SILVER3a 2016-04-04
SILVER3 2016-04-03
SILVER2 2016-02-28
SILVER1 2015-12-25
That means the last FPGA core release was almost a year before, and Screens/Show offs of the coming Gold 2.7 or Gold 3 are there since several month already but no sign of an actual release. (to be complete, there is a Gold 2.5 release, but there the FPGA core is not changed, same build number)
My Blizzard 1260 broke and I send it to repair, (sadly still unknown whats exactly wrong, MACH chips? I have no knowledge about such stuff). For the time without a proper turbocard for my A1200 I bought a Blizzard 1230IV which works very nicely. An other thing the Vampire is missing, is an MMU (at least an Motorola compatible MMU) so until now Linux or NetBSD will not work on Vampire Amiga. But on this Blizzard 1230 it runs… even very slow of course. I did some qemu-m68k stuff on my home server to let some automatic tests run of the freepascal 68k compiler Charlie is improving the whole time. My plan was to also try it on a real Amiga with Linux. Nice, but it really needs ages to do something like compile or install stuff. Maybe when my Blizzard 1260 is back I will try that again.
I read some interesting article about a c compiler in a web browser (in javascript) and I got the idea to promote the FreePascal compiler for Amiga systems a little bit more. it should be possible to create a page with a simple text editor on it, which can compile Programs for all our beloved Amiga systems from pascal sources. I don’t have much php knowledge but for that it’s more that enough. The Online Compiler was born. This project even got attention of a big german tech-news page Heise, which published an an article about that. But also the Amiga community showed some interest by using it and the biggest Amiga journal today „Amiga Future“ wrote an article about Pascal and also published an interview with me.
To keep the enemies separated I kept the Atari online compiler on a different page. Both are still nicely in use by some people.
Currently I try to find some motivation to continue on the MUIMapparium stuff. I already improved it a lot, especially the route finding stuff but it’s still not ready to release. in FPC I was working on the basic threading stuff, like events which were still missing. It was triggered by a change in the FCL package but need the event functionality. It still needs improvement.
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.
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.
Colored routes and Tracks in MUIMapparium
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)
| 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:
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.