Vampire V2.7 with FPU

Posted by ALB42 on 2. März 20188 Comments

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

8 comments to "Vampire V2.7 with FPU"

  1. flype sagt:

    Hi, thanks for the report.

    Could you please compile same with shortest code ? such as :

    ——————

    program testfpu;
    uses
    Math;
    var
    a: Integer;
    b: Single;
    begin
    a := 5;
    b := Round(a*1.0) ;
    end.

    • ALB42 sagt:

      First Thought: „Seriously? You asking ME to help debug your FPU, after …“
      Second Thought: „Whatever, it doesn’t worth it.“

      The simplest example I could create is this:

      program testfpu2;
      var
        a: Integer;
      begin
        a := 5;
        halt(Round(a* 1.0));
      end.

      it returns the result of the rounding as error code
      so a:
      testfpu2
      echo $RC
      should return 5 but returns 0 with current 2.7 vampire.
      Downloads: TestFPU2 TestFPU2.pas

      Have fun!

  2. flype sagt:

    Thank you.

    “Seriously? You asking ME to help debug your FPU, after …”

    After what ? What did i do to offense you ? My purpose is to help the team, just that, located the faulty code by disassembling it.

    Anyway, thanks for the reduced code, i will look into it.

    • Chain-Q sagt:

      @flype
      The Round() on 68k always uses a helper for now, because FPC’s Round() is defined to return an int64 value (signed 64bit integer). This cannot be done by the hardware on 68k, so the code currently calls the round helper, which is a pretty big function, and depends on the IEEE bit-correct result of all operations, as it does some integer bit tricks on floats. (There could be some special cases added, when the expected integer result is less or equal to a 32bit signed int, but that’s beside the point now.)

      What’s more worrying is the previous multiplication miscalculation by 1.3, which contains the following three instructions:

      moveq.l #5,d2; fmove.w d2,fp2; fmul.d #1.3,fp2

      I’d start with this, because Round’s internal implementation depend a lot on the implicit rounding behavior of the FPU (when loading to-from FPU registers), which seems to be clearly off, and without that working correctly, round would never work.

      And the usual rant: there are several compiler testcases out there. Even UAE’s emulation has chunks of validation code. Either no one ever cared to run those, or they did too big corner cuts to squeeze the FPU in the FPGA. To be seen.

    • Chain-Q sagt:

      BTW, if it’s relevant, the FPC RTL enables overflow, operand error and division by zero exceptions, and uses round to nearest mode with default precision. (Which is extended, IIRC). It does so by loading 0x3400 into the FPCR. It currently compiles no 040/060 specific instructions, everything is ‚882 code only.

  3. flype sagt:

    Ok, thanks ALB42 and Chain-Q for the inputs.

    The Round() issue is now fixed in the next Vampire core.

    MUIMapparium runs well now, both CPU and FPU versions are OK.

  4. Niding sagt:

    @ALB42

    When Gunnar was asked the same question on IRC, he estimated next Core update in 1-2 weeks, giving people time to register. This time several people can get their boards whitelisted. Wether or not flype/the team can provide you a fix while waiting, thats up to them to answer. 🙂

    Anyhow, my comment is based on IRC reply this weekend.

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert