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.
Traveling is nice, but also nice to be back. As wrote in he travel blog entry I worked on the MUIIDE, especially on the Menu creating stuff, which is quiet difficult things, but prepares other stuff to come (like listview and lists). You can create now very easily Menus with Submenus with the IDE.
There seems to be a little bug, sometimes when I change a combobox active entry, the GUI does not follow it. I debugged it a little bit, and it seems like and updating problem, because after resizing the window everything seems to be normal. Needs some more investigation.
Finally I got it working saving and loading also works now for events, as I described before I had to relocate the complete Eventhandler routine to make that possible (in an abstract way).
Now it’s also possible to add multiple Windows. (But only the first one is open by default), I have to think about how to solve it, but of course you can open the other Windows in the OnShow Event of the MainWindow. Or as I show in the Video on Button Press.
A little demonstration (featuring „awesome drawing skills“ icon 😉 ):
Notice to me, stop Delitracker before recording, or the mouse pointer whips with the Music 😉
After that is finished I guess the next one will be properties which are other classes, like Menu or List at the ListView.
I also have some ideas how to deal with special Values (like the Window inital position, MUIV_Window_LeftEdge_Centered and so on) but this will need a little bit more thinking and of course much work 😛 .
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.
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
Wrote a little Makefile and added the MUIClass compilation to the Jenkins build server. On every change in the repository it will recompile MUIClass for all available platforms. At the occasion I noticed that I did some errors for 64 bit (Integer – PtrInt) also corrected this. The Jenkins compilation create a little archive with the compiled units, IDE and examples. If you download them together with FPC release archive for your platform it should be directly usable. It also creates the documentation directly and as archive on the build server.
The exception handling I mentioned yesterday is improved. To satisfy MUI/Zune I put a try, except into every hook function before calling the Eventhandler, it makes sure the program returns from the hook to MUI/Zune. Of course the basic function is still the same, if the User decide to break the program, it will be terminated or if you connect the OnException event is assigned it gets triggered.
When an exception appears which is not covered by any try/except the program will just end (and print the exception to Debugout) which is not very nice. Again take some idea from LCL and catch all exceptions in the Event handler and show to user as nice MessageBox. But MUI certainly does not like it if you leave the Eventhandler in such a rude way 😉 (at least Zune on AROS) so after it the Eventhandler is dead because Zune thinks this is a circular calling. It’s not true but it’s prevents you to call that event again. Best thing here is to end the application an restart. Therefore I ask the user what to do, ignore the exception, knowing that this will have strange effects, or leave the program directly.
The ignore could be interesting if you have the chance to save your data before closing the program. Of course the writer of program can also override the Exception handling (via OnException Event in MuiApp, as used to from Delphi/LCL.
