MUIMapparium is an alternative implementation of Mapparium using directly MUI/Zune instead of LCL.
This version is much faster especially on 68k Amiga. It still needs an RTG card but a non_FPU version is included, but if it is too slow (especially with tracks and routes showing) do not blame me, buy a FPU. On the long run MUIMapparium will replace the Mapparium, at the moment it does not have the same features (but rather close)
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)
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)
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.
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 😉
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.
Some people ask me to supply a Version of the MUIMapparium presented yesterday. No problem, please just remember it’s heavy work in progress, not much is working currently. In principle only Mapping and searching function, but this is already nicely working on all my available Amigas. Please note the m68k-Amiga Version needs RTG (or it will just crash), OS3.1+, MUI of course and without network it’s not really useful ;-). The Amiga Version works nicely on Vampire A600 (RTG Screen) but should also work with every 68020+ Amiga with graphic card, just a little bit slow perhaps. (FPU is not needed, in contrast to Mapparium)
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.
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:
b := 1;
for i := 1 to 100000 do
b := b * 1.0000000001;
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:
Amiga 1200 68882
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