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 did not know that the Workbench Calculator (Sys:Tools/Calculator) uses FPU if available. By accident I noticed it has the same precision proble as my programs, very easy to reproduce.
see:
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
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)
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:
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.
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.
Tried some (Integer) Speedtest, some people asked me about. Of course I’m also interested if my feeling (double 060/50 speed). I used some code from Benchmarks Game. Especially the tests: fannkuch 10 and BinaryTree 15. (68060/50Mhz= A1200 with Blizzard 1260, MorphOS = MacMini 1.4Ghz, UAE/AROS/Linux = Athlon FX 8120 3.16 Ghz)
machine
BinaryTree
fannkuch
Time [s]
Speed rel. to 060
Time [s]
Speed rel. to 060
68060/50Mhz
42.9
1.0
59.6
1.0
VampireA600
23.4
1.8
28.3
2.1
MorphOS 68k emul
3.0
14.3
33.0
1.3
WinUAE OS3.9
1.4
30.6
2.0
29.8
MorphOS PPC
1.3
33
2.3
25.9
AROS i386
0.6
71.5
0.7
85.1
Linux x86_64
0.3
143
0.2
298
So my feeling was more or less right, it’s around double speed to 060, so it’s a nice step but far far away from UAE. More interesting for me would be FPU processing but at this point the comparison would be very dramatic and a little bit unfair because Vampire still have no FPU support (even it’s everywhere announced, but seems even next version will not have FPU).
As I wrote before the PiStorm is already very nice, stable but not that fast, I heard with the Emu68 it should be much faster (not so much features though, not network, AHI direct access and so on).
I used this manual. Also attached a cooler to the raspi to not let it overheat anymore and it works nicely barely it stays under 70° degree even on whole day use.
You can feel that it is much faster… SysInfo tells you that it is much faster, but to be honest, I never trusted SysInfo so lets get out my old test codes. Sadly the links to the benchmark game are gone, seems the page does not exist anymore, but I still have the sources so still can plan around with 🙂
Especially the tests: fannkuch 10 and BinaryTree 15. (68060/50Mhz= A1200 with Blizzard 1260, MorphOS = MacMini 1.4Ghz, UAE/AROS/Linux = Athlon FX 8120 3.16 Ghz)
machine
BinaryTree
fannkuch
Time [s]
Speed rel. to 060
Time [s]
Speed rel. to 060
68060/50Mhz
42.9
1.0
59.6
1.0
VampireA600
23.4
1.8
28.3
2.1
PiStorm A600 Emu68
11.4
3.8
11.9
5.0
MorphOS 68k emul
3.0
14.3
33.0
1.3
WinUAE OS3.9
1.4
30.6
2.0
29.8
MorphOS PPC
1.3
33
2.3
25.9
AROS i386
0.6
71.5
0.7
85.1
Linux x86_64
0.3
143
0.2
298
4-5 times of a 68060/50, not bad, it also emulates a FPU (68040) so also FPU tests are possible, for example the scimark test:
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)
now for the PiStorm A600 Emu 68 it looks like this
Mininum running time = 2.00 seconds
Composite Score MFlops: 20.35
FFT Mflops: 13.12 (N=1024)
SOR Mflops: 41.80 (100 x 100)
MonteCarlo: Mflops: 6.61
Sparse matmult Mflops: 18.16 (N=1000, nz=5000)
LU Mflops: 22.07 (M=100, N=100)
so here we have around 10 times faster than the good old 68060/50.
Here again it feels much faster because the RTG output is so smooth and the harddisk access is so much faster feels more like UAE speed wise. MUIMapparium for example is really nicely usable scrolls very smooth.
Also the Emu68 boots much faster than the other method and shows a nice boot picture, so you do not see the raspi booting just needs a bit longer than a usual Amiga boot (like you disconnected the Floppy).
And the most important… it seems to be stable same as the other method, some hours of Delitracker playing no crash, rebooting much more reliable than the other method… works always, I think I will stay with this Emu68 for now.
For quite a long time I have a Vampire V2 in my Amiga600, to be honest I never was really satisfied with it. The main purpose was to give RTG to a transportable Amiga and this was back in the days the only reasonable option (besides the BVision card for A1200 with PPC which is way too seldom and expensive). But sadly the Vampire V2 never worked really well, regularly it crashed even after a complete overhaul of the fitting and grounding and so on. Sometimes it wont boot sometimes it will just crash after some minutes. I often let my Amigas play mods with Delitracker, and if that specific Amiga is not able to do that for 2 hours straight (even better whole day of course) without crashing it’s just useless to me. My A1200 with Blizzard 1260/1230 and now TF1260 is perfectly able to do that all day long. My Draco is a bit difficult in that matter. Sometimes it runs a whole day without problems other times it crashes 2 times in a row in an hour. (I guess some AHI problems, because there are also other sound related issues).
But the A600 with the Vampire, that was a complete different story, it never managed to do a half hour Delitracker playing without crashing. After the card and Amiga600 was completely redone, better grounding, some stuff on the Vampire exchanged (or added?) i had the feeling it became a bit better, but just a bit. Still it never managed to make even 2 hours playtime without crashing. That was the main reason the Amiga600 with the Vampire V2 was never used and finally end up in a pile of stuff in the cellar.
Some weeks before I read some interesting articles about PiStorm and that there is a PiStorm hardware to connect a RaspberryPi to an Amiga600 (PiStorm600). I thought that would be a good chance to revive that poor Amiga600, so I took some garlic, a cross and went to the cellar to rescue the Computer.
Luckily I have a lot RasPis laying around (different Versions), bought them when they were cheap and easy to get 😉 sadly I don’t have a RasPi 3A but I have multiple RasPi 3B which should also work, just the USB port is in the way. I use a short extender cable to place the raspi a bit away from the adapter, therefore the additional USB port does not need to be removed. Until now I did not see and negative effects from the cable.
The software installation was quite easy, and after a little bit try and error I got finally the CF card to boot and to crash…. of course I need to de-vampirize the Workbench on there, which was not that difficult.
I bit difficult was the installation of RTG for some reason it did not work the first time I tried only got a nasty crash directly on bootup. Some days later I tried it again and this time it worked. I’m not sure what I did different but now it works. And this is the really good part. PiStorm shows the RTG screen on the HDMI output of the RasPi so you have a VERY clear and stable picture with for example 720p, (something I was never able to setup for the Vampire to work reliably)
It emulates a 68030 and 68881 in the RasPi. It’s not lighting fast or so, it’s around double speed of an 68030/50Mhz I would guess but the RTG is rather fast, so it feels much faster. But the usual Suspects work, so FreePascal and many of my programs, even MUIMapparium the FPU version works nicely.
Network seems to work, but it is rather slow, my PCMCIA card is much faster, but this is also described as still in development, so no surprises there.
Sound AHI via the HDMI from the Raspi, I never got to work, it seems it plays but I do not hear anything, maybe it’s still going to the headphone jack, I did not try. But this AHI is also not very important to me, for me the Amiga Chinch out is enough to play MODs.
And YES I tried it, let play Delitracker several hours random mods from the HD and it worked flawlessly not a single crash, very nice.
Of course it’s not all nice and shine, of course the Bootup needs rather long (around 30 s, it needs to Bootup the RasPi first) and for shutdown, you should shutdown the RasPi first before turning off the Amiga to prevent the sd-card in the Raspi to corrupt.
Also it seems at the moment it has some problems with the ROM mapping, if I use that Kickstart ROM and not the internal ROM, it has big problems rebooting the Amiga, usually it’s easier to shutdown everything and start fresh. Also the Bootmenu is somehow broken and mostly crash. All that do not happen if I use the internal hardware ROM.
At the moment the RasPi inside the Amiga case becomes rather hot and starts to clock down so I will need to a add a heat sink of some sort, but there should be enough space and I should think about additional power to the Raspi because it complains about undervoltage which also causes clocking down of the speed.
But overall not too bad and a good idea to emulate the 68k on the Raspi. I’m rather satisfied.
