Unofficial AIBB Version 6.6 patch

[SpeedGeek]

Unofficial AIBB Version 6.6 patch
© SpeedGeek 2021

INTRODUCTION:
Since the AIBB MINIMAL 68060 CPU compatibility patch was
released I decided to develop an enhanced version.
The enhanced version features are essentially cosmetic so
please see the WARNINGS before using this patch.

FEATURES:
- New 68060 code emulates "Unimplemented" instructions
which caused AIBB to crash on 68060 systems (unless the
CPU tooltype was set to 68000/010).
- Runs all original AIBB code on 60000-68040 systems
- 100% PC relative Assembler code
- Patched executable is only 212 bytes larger than original
- Replaces 68040 output strings with 68060 strings when a
68060 CPU is detected. Supports LC/EC variant and Copyback
strings.
- Fixes a typo bug on 68LC040/68EC040 user requester
(68EC060 string is now corrected to 68EC040)
- Updates version to 6.6

WARNINGS:
This patch does NOT update AIBB to fully support the
68060 CPU in the way a benchmark program written
specifically for that purpose would do. It does NOT
functionally affect MOST of the limitations of the original AIBB
code except for allowing it to run on 68060 systems.

UPDATE:
Fixed a rarely occurring address computation bug (Assembler
defaulted to word math) which could cause 68020-040 systems
to crash. There is no AIBB version change for this bug fix
update. The only change is in the name of the patch file
which creates this version.

MD5 bug fix Checksum:
a5810b7542bacd6e2a71c046be3f6652 AIBBv6.6

[Romanujan]

Thanks - great that someone still enhances this benchmark! One suggestion: it would be nice to recognize the Apollo Core and print it out as 68080... EmuTOS already does so.

[SpeedGeek]

Originally Posted by Romanujan

Thanks - great that someone still enhances this benchmark! One suggestion: it would be nice to recognize the Apollo Core and print it out as 68080... EmuTOS already does so.

I'm really quite surprised to have emulation simulation users more interested in my AIBB patches (or at least actively showing more interest) than real Motorola 68K users!

There is a practical limit on what I can do with patching a few hundred bytes of code into an existing executable. But even if I could do more than simple "Enhancement" there is still a long way to go to update AIBB to fully support the 68060.

Since, AIBB was originally developed to support real Motorola 68K systems, any further development (IMHO) should achieve full support in that regard before supporting any third party 68K emulations simulations.

EDIT: I agree the word "Simulation" was better choice of words for this topic.

[grond]

It's not a balloon, it's a Zeppelin, err, I mean, the 68080 isn't emulation but a 68k processor implemented in an FPGA (as ASICs are so expensive to make in small numbers).

[Romanujan]

@SpeedGeek - As both real Motorola 68k (68030+68882) and emulation (FS-UAE) user, I can tell running benchmark inside emulator is more interesting to me - we already know how the real chips perform, but we usually don't know how much emulated Amiga performance you get by, for example, switching to new x86 hardware, or trying to emulate Amiga on Raspberry Pi.

AIBB was originally developed to support real Motorola 68K systems

When AIBB was developed we didn't have a single working Amiga emulator... nor there was any FPGA reimplementation of the CPU available to use.


@grond Apollo Core ending up in ASIC eventually is not completely impossible. For now there are well over 2000 Vampire accelerators ordered for A500 and A600. Hard to guess how many people are waiting for A1200 or standalone version. And just for the new A1200 cases one guy collected something like 150,000 EUR from just 840 backers...

[SpeedGeek]

Originally Posted by grond

It's not a balloon, it's a Zeppelin, err, I mean, the 68080 isn't emulation but a 68k processor implemented in an FPGA (as ASICs are so expensive to make in small numbers).

The debate over hardware vs. software emulation is an old one which I have (fortunately) been able to avoid getting dragged into. It really comes down to individual users opinion's and standards for the definitions of "Real" and "Emulated".

EDIT: I agree the word simulation is a better choice of words for a 68K implemented in an FPGA. However, if you think AIBB should support a third party implementation of 68K (real or emulated simulated) before it fully supports the original Motorola implementation of 68K then I would suggest you develop your own update patch. I have already made my decision.

Originally Posted by Romanujan

@SpeedGeek - As both real Motorola 68k (68030+68882) and emulation (FS-UAE) user, I can tell running benchmark inside emulator is more interesting to me - we already know how the real chips perform, but we usually don't know how much emulated Amiga performance you get by, for example, switching to new x86 hardware, or trying to emulate Amiga on Raspberry Pi.

When AIBB was developed we didn't have a single working Amiga emulator... nor there was any FPGA reimplementation of the CPU available to use.

The performance on real Motorola 68K systems varies considerably as many different users obtain different benchmark results. If emulation users find their benchmark results more interesting that's fine but then please be happy with what you have.

Also remember, AIBB is quite an old program and the fact that it works as well as it does is a testimonial of the impressive coding skills of Mr. Lamonte Koop. Amiga software developer extraordinaire!

[kolla]

Where do one find original AIBB 6.5 these days?

[SpeedGeek]

Originally Posted by kolla

Where do one find original AIBB 6.5 these days?

You can find it here:

http://eab.abime.net/showpost.php?p=1137296&postcount=5

P.S. If you intend to do Vampire/68080 FPU benchmarking you will probably be disappointed. If AIBB detects only LC/EC CPU variants it won't enable the Floating Point code selection gadget.

[Minuous]

Had some issues locating a version that the patch can be applied to.

So I have uploaded V6.6 to the Zone to save others the hassle.

[idrougge]

Why not upload it to Aminet?

[Minuous]

Well, it's just the executable, I would want to upload the full package. Does anyone have a link for the full package? I assume the one currently at Aminet is not it, as it was described by SpeedGeek as a "hacked version" and also seems to be missing some files, eg. AIBB.guide.info

[emufan]

I zoned AIBB_v6.5.dms - includes docs and guide files.
the 6.6 patch does work with this version, tested but not applied.

[ShK]

Originally Posted by SpeedGeek

You can find it here:

http://eab.abime.net/showpost.php?p=1137296&postcount=5

P.S. If you intend to do Vampire/68080 FPU benchmarking you will probably be disappointed. If AIBB detects only LC/EC CPU variants it won't enable the Floating Point code selection gadget.

That 'original' version of AIBB is at least in Falcon 040 install disk:

http://amiga.resource.cx/exp/falcon

With the right tooltypes AIBB starts fine with SoftFPU / femu 0.3 (10-Jul-2017) by Jari 'jarp' Eskelinen.

[utri007]

AIBB doesn't crash with 68060. It works with Apollo 68060, but not with Blizzard 68060.

[SpeedGeek]

Originally Posted by ShK

With the right tooltypes AIBB starts fine with SoftFPU / femu 0.3 (10-Jul-2017) by Jari 'jarp' Eskelinen.

AIBB may start fine with the right tooltypes and SoftFPU, but it's really pointless since AIBB already provides a built in SoftFPU function and it's likely to be much more efficient than any external exception trap based implementation:


The currently available floating point code options are given
below. As indicated earlier, they will affect only tests which
utilize floating-point math in nature.

Standard Math Code
Using this option sets the code type to use software
emulation of floating point routines. This is compatible
with all Amiga systems in use, as it is not hardware
specific.

In-Line Coprocessor Code
This option sets the test code type to that which uses
faster in line FPU instructions for floating point operations.
As not all systems will have a coprocessor available, this
option is not universally available on all systems.

68040 Enhanced Math Code
For use with 68040-based systems, this option allows the
use of FPU code which is more optimized for 68040
processors.
Such processors do not have hardware-assisted
transcendental functions and this option will set up for in-line
emulation of such, alleviating the need for trap-based
libraries such as 68040.library or similar vendor supplied
code.

[matthey]

Originally Posted by SpeedGeek

AIBB may start fine with the right tooltypes and SoftFPU, but it's really pointless since AIBB already provides a built in SoftFPU function and it's likely to be much more efficient than any external exception trap based implementation:

It is not pointless. Compiling with software floating point is usually going to be faster than SoftFPU but the source code is not available in many cases and the authors will not bother to recompile for a cut down CPU like the Vampire's Apollo Core or Tabor's PPC e500V2. It would be nice to know how much performance is lost with SoftFPU by benchmarking. It could help us decide whether we want to go to UAE or AROS Raspberry Pi after our 68060 hardware dies .

[SpeedGeek]

Originally Posted by matthey

It is not pointless. Compiling with software floating point is usually going to be faster than SoftFPU but the source code is not available in many cases and the authors will not bother to recompile for a cut down CPU like the Vampire's Apollo Core or Tabor's PPC e500V2. It would be nice to know how much performance is lost with SoftFPU by benchmarking. It could help us decide whether we want to go to UAE or AROS Raspberry Pi after our 68060 hardware dies .

Well "Pointless" is certainly a subjective term and undoubtedly relevant to the benchmark users intended purpose. That being said, I seriously doubt that Vampire/68080 users really intend to show how much performance is lost with SoftFPU:

http://www.apollo-core.com/knowledge...931&order=&x=1

...and it is also quite unlikely, that they have any intention of helping you to decide whether you should or should not Vampire.

[matthey]

Originally Posted by SpeedGeek

Well "Pointless" is certainly a subjective term and undoubtedly relevant to the benchmark users intended purpose. That being said, I seriously doubt that Vampire/68080 users really intend to show how much performance is lost with SoftFPU:

http://www.apollo-core.com/knowledge...931&order=&x=1

Roman S. had a very good point and almost was banned for it like Cyber Gorf was earlier in the same thread. It was "low quality and shows lack of respect for the coder" to compare the SoftFPU performance to a hardware FPU. Just another disenfranchised Amiga user to "work together to bring 68K and AMIGA back!”.

Originally Posted by SpeedGeek

...and it is also quite unlikely, that they have any intention of helping you to decide whether you should or should not Vampire.

They are helping many Amiga users decide all right but others don't seem to care. Why does everything promising on the Amiga turn to shit?

[kolla]

Originally Posted by SpeedGeek

...and it is also quite unlikely, that they have any intention of helping you to decide whether you should or should not Vampire.

Oh they are very helpful... they will tell you to buy buy buy, and then sell sell sell

[kolla]

Originally Posted by matthey

They are helping many Amiga users decide all right but others don't seem to care. Why does everything promising on the Amiga turn to shit?

Because copyrights.