I uploaded some of my sources to my github account. With it also Leu and MUIMapparium. MUIMapparium is 100% written by me, therefore it is now under CC0 License. Leu contains fpspread and some files from LCL therefore it is modified LGPL as the original. Have fun with the code. 😉
I had some interesting and intense discussions the last days. Mainly about my programs and vampire. As you might know I did not want to have my programs on the highly illegal distribution Coffin. You cannot detect Coffin, but it’s a distribution especially made for Vampire, therefore if I block Vampire they will not include my software anymore. Besides the Vampire users could push the Vampire team to condemn this distribution and stop to promote it. All of that did not happen, they still added my stuff, even with the Vampire block and the people became mad about me, not about the Vampire team (or the coffin team). I’m not good at being the bad guy.
Basically the people tell me that I’m an idiot and an asshole because I blocked Vampire, so I give up. The people always told me that Coffin is not illegal because it contains abandon-ware only. Ok, if that’s the case I transform my programs to exactly that and put them all to github, then it is legal and everything is solved.
Don’t get me wrong, I do not have a grudge with the Vampire team. I always hear that, that I’m mad about them because of the FPU issue, which is not true, maybe disappointed, but not more, I use my Vampire mainly as RTG-GFX card for A600, the only one currently available and the FPU I can turn off and use femu (which still works and is rather good).
Again playing with 3D stuff, realtime raytracing, but this time a little bit stripped that it also can work on a real 68k Amiga, like the Draco, so without mirrors and so on. The new improvement by Charlie in the FreePascal compiler seems to work as it should be and also increase the speed a little bit, so it’s almost fast. Ok its still horrible slow, but hey the first version needed around 10s per frame, now it’s under 2s.
Also tested with AROS and because its the new „hot stuff“ of course on AROS64 and even the image is 4 times bigger it moves smoothly. If you make it the same size as the Amiga68k one, it needs around 8ms per frame but the window is very tiny.
It’s still heavy with floating point calculations so the 68060 is very good to use the 68881 will be much too slow. I also tried the Vampire 68080 which have a much faster but not so precise FPU. Good news it works, bad news it looks broken. I only use Singles everywhere and removed all Round() from the source but still it looks completely wrong, no idea why.
As I wrote before I did not get Delitracker to work, and also some other programs, I expected to work seems to have some problems. Now, that was not quite right, Delitracker was working, just the mods sounds very wrong wrong speed too fast and slow at the same time and sometimes it just shows a black screen.. even it’s still playing the background. An other odd thing I noticed, some programs (even my own pascal programs) have very strange timing behavior. Then I remembered that there is even a special Draco Alert when some program try to access the CIA and I saw them when trying to start some programs. My Draco does not have CIAs installed, but of course they are needed for exact (Amiga style) timing, especially when playing modules. I bought two CIAs and installed them today. And voila, Delitracker is working with AHI Noteplayer. With some mods (especially chipies) you can hear that there is a difference to the original Paula sound, but it’s good enough for everyday use, at least for me.
I opened my usual visualization, MonoScope, Quadrascope+ and it’s working very smooth, very fast drawing. This is a little bit odd, or unexpected for me at first glance. I did exactly the same on the A600 with Vampire and the visualization always started to become a little bit slow, especially the Quadrascope+ in combination with MonoScope on bigger Screens (like 800×600) so I disabled the Quadrascope+ there. But here on the Draco, even I make the Quadrascope+ a quarter of the screen and Monoscope and other quarter it stays fast. In my mind this slowdown was always due to RTG vs. AGA/ECS and the DeliGenies are clearly optimized for AGA/ECS. (Vampire was my first RTG Amiga). But now it seems on the Draco everything is smooth and fast, so it’s not an RTG iussue. Very nice.
If you have a Draco, install the CIAs it will improve the compatibility a lot, it’s not difficult, even I was able to do it myself :-P.
Hey ALB do you like all old computers or only Amigas.
Let’s say so, if there is a Pascal compiler for it, it’s counted as a computer worth to care about. 🙂
So I present to you, a pascal compiler on a old GDR (east germany) computer KC85/4, a real machine, not emulator. Signal converted with the Extron and recorded using the Elgato device mentioned before. Basically just a testcase for the conversion/recording equipment
Back to topic, after this little Vampire excursion, I continued working on MUIIDE especially the loading and saving, atm. I just save/load a project file which is a simple XML very easy for Trees to handle in XML and also can save nearly every content. But of course with this it will be not possible to export the source code and reload it to add an additional item… especially if you changed the source. It will be very difficult to make that happen, of course Lazarus does this… but Lazarus is a code monster difficult to dig out how this is done and maybe thats even not transferable to my code. I’m not sure what to do here.
Loading and saving for the properties is already finished and working well, but at this position I noticed that I did the eventhandler keeping wrong this way I can not save them to the project file, seems need some more thinking.
After that is finished I will try to add class properties, like Menu (Window), List (on a ListView) and so on Also thinking about to make the project multi window compatible, so that it really can hold the complete application not just a window, then the root of my Tree should be application and not Window.
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 itbutalsothisyear.
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:
GOLD2 2017-01-23
GOLD 2016-09-05
SILVER9 2016-08-03
SILVER8 2016-07-29
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.
The FPU version is much faster, especially with routes and tracks. If
you experience slow map movement, with the NoFPU version, don’t blame me
(or the program) buy a proper FPU.
With Vampire (at least until Gold 2.9) you have to use the
NoFPU-Version of MUIMapparium. The Vampire FPU is not IEEE754
compatible and therefore does not work with MUIMapparium.
Offline Operation is possible, but only harddisk cached map images
are shown.
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.
A crazy idea came up to me. Would it be possible to create a webpage with a nice javascript Editor which could directly compile FreePascal sources for all our beloved Amiga Platforms. The answer is certainly yes, I googled around to find a small package without too many nodejs, npm and such things, which always fails on my old server ;-). I found ACE which seems rather nice an easy to use. The rest is just some little php magic and of course the cross compilers, which I know already long time how to create and use and voila, ready to use webpage to create a simple (one file) Pascal application for all amiga platforms. I tried it on MorphOS, AROS and even native on an Amiga 600 with Vampire using iBrowse. Of course in iBrowse the editor does not work. I included a special page with a simple HTML textarea for such old browsers.
The compilation speed is much faster as a native compilation.
On MorphOS it runs much better of course the MorphOS OWB is even capable to show the editor, very nice.
It’s a little bit slow because it’s recorded via VNC, in reality it feels rather fast.
AROS was a little bit of disappointment for me. I downloaded the latest Icaros 2.2 especially to test this webpage. But sadly the editor does not show up. No Error message shown. I guess it’s some missing font problem, because when I change the theme the background color changes, only the text is not visible. It’s a pity. I had to switch to the old Browser interface which works nicely but I expected more.
