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).
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 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
** **
** 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: 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.
P.S.
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)
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.
Working on a very old bug. I’m not sure if someone noticed it, at least nobody reported it. The coordinate to pixel conversation was not very precise because it used a average resolution for every tile. This works well for higher zoom levels where the resolution does not change much inside a tile. But for lower zoom levels, especially the whole world picture this is certainly not right any easily visible when using way points. See for example Mapparium 0.6 on the right side of the image, all way points are (and tracks) are shifted to north. The solution was not very difficult but needed some thinking, basically a rounding error and precision problem.
MUIMapparium (Left) and Mapparium (right) Waypoint position comparison and german locale
I also start to play with localization. I never did that before, especially not in FreePascal but it’s not very complicated, just diligent work to replace all strings. So next version will also be available in german (and maybe later some more languages, at least I got an offer for french localization). There is one small problem with that, there is no locale library unit in FreePascal for AmigaOS4 so either I make some defines to turn it off for OS4 or implement the library unit.
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.
OpenStreetMap viewer for Amiga-Systems. The map can be moved around an zoom. It is possible to set waypoints, or load recorded tracks or waypoints from GPX, TCX, KML or KMZ files. The speed or height curve can be showed and inspected.
Downloads
Please use MUIMapparium due its more recent and more powerful.
MUIMapparium, the next Generation
There is a new implementation of Mapparium in pure MIU/Zune code which makes the whole program 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)
To move the map, click and hold the left mouse button inside the map. Zoom can
be changed with mouse wheel (Zoom in = mouse wheel up), +/- buttons or double
click into the map.
To search for a position on the map type in keywords into the search bar on the
top of the window and press „Search“ the sidepanel will open automatically.
The side panel can be also open or closed by clicking on the panel opener on
the left side next to the map. In the side panel you can find the search
results, tracks and waypoints. Double click to a search result, a track,
a route or a waypoint centers the map onto this feature.
A Double click onto the lower panel copies the middle coord to clipboard using
geo syntax.
To jump directly to a position type in the two coordnates separated by space
„Lat Lon“, or via geo: URI: „geo:lat,lo>?z=ZoomLevel“
To search for a location of an IP-address type ip: for example
ip:8.8.8.8
To add a new Waypoint select in the sidepanel the a waypoint entry (or the
„waypoint title“) and press „Add“. A waypoint is created at the current
position.
To create a new route select the „Routes“ entry and press „Add“ a new Window
will appear to define the start and end point. You can either use the current
position in the map window or use the two edits to search for your
destinations. Do not forget to press enter when you typed in a new start or
end and select the right address (double click) in the view underneath.
Choose route type (car, bicycle or foot) and if it should be the fastest
or shortest way. You also have to choose which service you want to use.
YOUR is more reliable but supports no informations where the order takes
place, OpenLS is sometimes rather slow, but makes better directions.
A double click on one of the orders zoom to this specific area (not available
for YOUR). To copy the orders to clipboard active the view and press Ctrl+C.
Mapparium on AROS
History
0.6
ADD: Image List with EXIF position Data
ADD: Image preview
ADD: AREXX commands for Add images to imagelist
ADD: Menu for Main window and ImageList
ADD: Active Route color
ADD: Overall statistics
FIX: Color settings
0.5
FIX: AROS invisible search text
ADD: Routing calculation via YOUR or OpenLS
FIX: better Prefs window
ADD: Save/load routes from GPX
CHG: Open TrackView or RouteView on Show/Edit Button
CHG: Moved Track title edit into TrackView
ADD: Context sensitive Add Button
ADD: Possibility to hide/show tracks/route
FIX: Faster drawing for 68k Amiga
0.4
ADD: Clear HD Cache by Button in Prefs to a certain zoom level
ADD: Find current position (by ip)
ADD: Search position by ip (type: ip:x.x.x.x to search)
ADD: Get address for current position
ADD: Zoom in by double mouse click
ADD: AREXX port with commands „goto“ and „addwaypoint“
ADD: Loading of Garmin FIT data
ADD: Other color for active track
FIX: Umlauts fix in search header
FIX: Search by Return press in search box
0.3
FIX: Invisible texts on OS4
FIX: Go offline if internet is down
FIX: Start folder for load/save dialogs
FIX: Filter for dialogs
FIX: Version informations
ADD: Load tracks from Garmin TCX files
ADD: Set size of middle marker
ADD: Support for geo: URIs
ADD: DblClick to lower panel copies middle position to clipboard as geo: URI
0.2
ADD: Show Height/Speed map of recorded tracks
ADD: Marked position in curve mark also on the map
ADD: Support for KML/KMZ Loading
FIX: Optimized image keeping
0.1
NEW: Initial Release
ADD: Load OpenStreetMap tiles
ADD: Load and Save Waypoints and tracks from GPX Files
A Text to Image Application for all Amiga Systems (using Stable Diffusion). Inclusive „Magic Prompt“ insert a basic idea and magic prompt reforms it to a better prompt for the model. Or if you have no idea at all press „Random“ to get a random Prompt for a nice image (sometimes gives an idea for more)
Requirements: – Internet connection – MUI (3.8+) – Datatype (PNG)
This is the first and only AROS x86_64 (ABIv11) distribution of the world.
Note: The change of ABIv1 to ABIv11 results in a complete incompatibility to earlier version 0.1 and 0.2 of T100pUAD. That means programs compiled for older Versions will just crash.
And the name is program, until now its not really usable, very unstable and very little programs available to start on. (Now with some of my programs installed, MUIMapparium, Hex2, MUIPlot, MCAmiga, AYA, AmiTube and of course FreePascal)
It’s mainly aimed to really brave people and people want to play with Free Pascal on AROS64, because this is for what I need it. to develop and test 64bit AROS Free Pascal.
Download:T100pUAD Linux Hosted Version 0.3 Size: 270 Mb. MD5: a952fcad08f1cb50364306a899c6f1ed
How to use:
Unpack at Linux x86_64 you will find a folder T100pUAD with 2 Startup scripts inside (StartAROS.sh and StartAROSwithNet.sh). Use them to start AROS, a new window will open with AROS running.
older ISO Version:
Removed because it is not compatible anymore with the current ABIv11
Be warned
The 64bit AROS is still in a very early stage, I would call it pre-alpha, it will most likely: crash your computer, delete your data, post awkward pictures of your facebook and twitter account, sell your stuff and partner on ebay. So be warned and do not blame me for that.
