Currently I’m working on the idea I had long time before. A pascal interface to MUI classes. MUI uses Amiga boopsi interface to access the GUI elements. But thats not very convenient, especially for pascal users. I started already two time an approach to create such classes. The main problems are the fields which can only set in the moment when the object is created and the TagLists which does not tell you the type of a field you have to cast everything to integer. In LCL I supply the properties as Create parameter TagList, so it’s just the same as using the plain MUI functions.
In this MUIClass implementation the pascal classes will only collect the field values and create the MUI objects on the actual application run and window open. You have more chance to interact with the objects before the MUI objects get created.
It makes the MUI programming much easier, I like it. I’m thinking to change some of my programs to that system, the code looks much easier to read. The code is on GitHub under a public domain license.
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.
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 MUIMappariumandwentthrough 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:
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.
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.
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.
Still playing around with this raytracing routine, implemented a better GUI, full MUI of course. It looks very like the one from WireDraw… yeah, I just copied that and replaced the engine, simple as that ;-). Added movement and rotation of the camera and a List of all items so you can move one after the other, and of course calculate that in high resolution and save it. Yeah, just fun no real use but it’s to damn hot for serious work. Would be interesting how fast that works on MorphOS, especially my G5 2.7 Ghz maybe try next week.
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)
68060/50 MHz FPU
68030 68882/50 Mhz FPU
Vampire Femu 0.10
Mandelbrot single precision
Mandelbrot double precision
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)
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)