A2080 i.e. Vampire 500 V2 on an Amiga 2000

[kolla]

I've tried fsUAE, which I cannot even use due to its interface. I've found no menu or no button how to setup a harddisk, or to define the kickstart, so I gave up before I could measure anything. It's ok to insert a game disk - that's something I see in the user interface.

My mind boggles - I run FS-UAE on macOS, Linux and DragonFlyBSD, building it myself from git, using fs-uae launcher as GUI - that you, a skilled self acclaimed Linux developer, is not capable of getting it to work on... Linux - is a bit absurd.

I've put *a lot* of work into vamos in the last year, which runs acceptable, on top of the musashi 68K emulator. It's not a particularly fair comparison because it is not a high-performance emulator. The speed is better than my 68060, but not stunning. Without having made detailed measurements, I would say that this is probably a factor of around two at most. Workable, but nothing to call home about. As said, it's a simple emulator, no JIT. Gets the job done I wanted to do, but probably nothing to build a hardware around it.   It's no more or no less "blasphemy" than putting a PPC on it. In the end, if running "foreign" code on it, an intel is considerably more useful than a PPC. At least, there is a software library for it. Concerning emulation, I wouldn't hold my breath - but as long as you have the chipset available instead of depending on emulation, it might be more workable than eUAE.

Why not give Qemu a go, it is currently used by Debian Linux/m68k team (and myself for Gentoo Linux/m68k):

https://github.com/vivier/qemu-m68k

[kolla]

The major issue with endianess comes when you have native software sharing memory with software running under emulation, as Amiga OS is all about sharing the memory.

[kolla]

Yeahbut is it Zorro or a2000 cpu slot?  Pic looks cpu slot to me.

You put the Vampire in an adapter that fits into the CPU slot of the A2000, _or_ you just pull out the 68000 and insert the Vampire there, but that may not fit so well inside the A2000, and in any case it does not matter.

A2000 only has 16 bit Zorro2 slots that were made with 68000 in mind, and these will work well with Vampire.

What would _not_ work, is using current Apollo core with Zorro3 cards, but at this point that is not so relevant, as there are no Vampire cards for A3000(T)/A4000(T) systems.

[kolla]

* We also assume that Zorro 3 cards will run just fine. As we have no Apollo Card for A4000 yet, we can not prove this today - but there is no reason why Zorro 3 card should not just run fine.

There are plenty of hurdles to work around to get Zorro3 working - and it is one thing to support the spec, another to actually support all the trick&hacks to support all the cards out there.

Both A3000 and A4000 make use of the MMUs in the 68030 and 68040 respectively to work around issues.

As the 68040.library requires an MMU to map address space, the fix
described above will not work on systems with an MC68EC040.  Because
burst mode on the 68040 is activated along with the cache, there is
no way to prevent a 68EC040-equipped Amiga from doing full line
bursts when accessing cachable address space.  This means a 68EC040
cannot prevent the excessive reads and writes when reading
non-cachable Zorro III devices that reside in cachable address space.
A 68EC040-equipped Amiga will experience a significant decrease in
performance when accessing non-cachable Zorro III devices.  For this
reason we cannot recommend that anyone use a 68EC040 (or any future
68000 series CPU that has no MMU) as the CPU on a Zorro III bus
system.

http://amigadev.elowar.com/read/ADCD_2.1/AmigaMail_Vol2_guide/node0161.html

[kolla]

* Apollo 68080 is not GPL but you can perfectly legal combine it with GPL VHDL in the same FPGA.
The legal requirement for instantiating several FPGA designs in the same FPGA is that each design is an separate entity for which its license then is valid.

I guess that will be settled in court at some point, the Amiga way