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

[kolla]

just remembered. I recall hearing a while back that the vampires weren't compatible with zorro slot expansions. Installing one would render all your other cards inoperable. I wonder if this has been addressed yet?

mmu, and zorro3.

[kolla]

Many years ago I had a router developer board with a PPC440 and FPGA on the same board, and I think maybe it even was in the same chip.

[kolla]

Apple has used ARM since at least the Newton was developed.

[kolla]

Goal is to have a _very_ fast 68K system to run
AMIGA OS 3...
MAC OS 7,  MAC OS 8
ATARI TOS
AROS

So you plan acc cards for old 68k macs and ataris as well?

[kolla]

Nothing, the more the better. Ideally any 68k OS should run well on a 68080, it's too late to adapt the software to the hardware, but with FPGA you can adapt the hardware to the software. I would love to run *nix type OSes (old classics like NeXTStep, Apple UX, SunOS, Domain/OS, as well as modern Linux and NetBSD) on 68080 too, but as it is currently a 68EC080, missing the essential MMU, this is not possible.

[kolla]

For what it is worth, FS-UAE on my macbook (that isn't even "pro") runs in large rings around Vampire, as does FS-UAE my Intel NUC running DragonflyBSD... my only insensitive to get a Vampire would be if SAGA really provides improved experience of the Amiga chipset architecture, I already have excellent RTG experience of Amiga OS with UAE incarnations.

[kolla]

Exactly. It's nice and cool with the 68080, but as long as it remains 68EC080, without FPU and without MMU - what does it hold over emulation? 64 bit this and that and new functionality is only interesting if there is software around to use it. 100% of the software library is legacy, and can make zero use of new functionality.

Does (Free)MiNT run on the 68080?

[kolla]

How does it compare against Qemu?

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

[kolla]

attached comparison 68060 versus Apollo 68080.
Result is very clear.

You mean Apollo 68EC080. A 68EC060 can be overclocked quite a lot from what I have seen, so what then?

[kolla]

Not sure what you ask for..

The max clockrate of the Apollo 68080 in the Vampire?
The max clockrate of the Apollo 68080 in an expensive FPGA?
The max clockrate of the Apollo 68080 implemented in an ASIC?

What is your question?

I am insinuating that comparing 68080 with a 68060 is so-so relevant as there is yet no way the 68080 can actually replace the 68060. I also think it is not right to call it 68080 when in 68k lingo should be named 68EC080 at this point, and then it would make more sense to compare with 68EC060, which many of us run at much higher clockrate than 50MHz.

What impact on speed would (will?) implementing MMU on the 68080 have? (and hence making it a more relevant comparison to 68060)

[kolla]

Wow ... is nothing good enough anymore ?

Well, the 68080 in its current state is not good enough to replace my 68060 systems, that's for sure.

[kolla]

EC in Motorola 680x0 processor naming stands for Embedded Controller. As such it is cut down is some way(s) compared to the full version of that CPU, be it data bus width, address bus width, FPU, MMU or instruction set. Although targeted at the embedded market they are also suitable for general computer use when cost is an issue.

What the Apollo team choose to call their cores and what they choose to implement in them is up to them. The cores are not 68000, 68020, 68030, 68040 or 68060 clones in either Full or EC configurations, they implement the vast majority of (used by Amiga/Mac etc software) instructions from across the range of MC680x0 CPUs as well as new instructions not found on any MC680x0 CPU. Lack of an MMU doesn't require them to label their cores as EC. Inclusion of an FPU is planned for the future. The Apollo Cores in the Vampire boards are FAST for a 680x0 compatible FPGA core on a low cost FPGA.

That is all well and good, so a comparison with FAST existing 680x0 solutions would be much more preferable than a comparison with the lowest possible clocked 68060.

[kolla]

Aside from x86, what other genuine CISC architectures are still alive?

[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.