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

[psxphill]

What I need a PPC for I still haven't really found out.

Need? Isn't this all just digital pornography?

There are some PPC demos that I'd like to be able to run. There are demos that need a faster 680x0 than ever existed as they were purely written for and tested on *uae.

Other than that it would probably just sit there looking cool.

[psxphill]

I mean - as far as I understand all the hardware talk - Amiga code should run on Intel CPUs, once the endianess of the code is changed, right?
Or did I get it completely wrong?

Does something like an "endianess converter" chip exist?
I seem to remember having read somewhere that there actually are CPUs where the endianess does not matter - it is changed "on the fly", IIRC. So there must exist something like an "endianess converter" chip, right?

Amiga code won't run on Intel CPUs unless it's translated, but once translated it's usually the memory accessing that takes a lot of the emulation time. In this environment you could simplify everything apart from the endian.

Some CPU's can just switch between all instructions using big or little endian, like some PPC's (although some are fixed little or big endian).

An endian conversion chip is possible in theory, but in practice it would need to be inserted inside the intel cpu because when accessing the data cache the signals don't ever escape the chip. Disabling the cache would be far worse for performance than doing the endian conversion in software. Converting a 68000 to little endian on the other hand would be trivial.

[psxphill]

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.

That is a problem if you want little endian AROS and big endian AROS in the same memory map. Amithlon solved the problem with an alternative GCC build that automatically converts x86 to big endian. So you can build native code that runs in the same memory map, but the memory reads/writes are slower because of the overhead.

The emulator always has to do the endian conversion, although there are various ways you could try to reduce the overhead.

[psxphill]

That's, however, not quite what Gunnar offers. As far as I understand, they have some sort of unit that can control caching, though it remains unclear to me to which extend it is flexible enough to allow the above.

I'm sure he can make it flexible enough, he just refuses to make it compatible with old software. The 68040 issue may not be applicable if he's not doing bus accesses in the same way.

[psxphill]

The second problem is the cache granularity of 16 bytes per entry. The 68040 cannot see modifications of RAM in Zorro space only, and a dirty cache line is always written back completely, regardless of which individual entry is dirty. That is at least the source of the DMA problem and (one) source of the need for CachePreDMA/CachePostDMA().

That again can be solved by deviating from the 040/060 and having byte granularity in the write cache. My guess is that Gunnar can't see what we're making a fuss over. However I'd rather see the 68060 replicated warts and all, at least as a fallback option.

[psxphill]

likely. but the fuss you are making is wasted with the uninvolved.

Who knows where it will lead, it doesn't particularly waste my time.

I've not given up on Apollo yet, but I'm also looking at other fpga systems (not amiga targetted). It's not been announced yet and I'm still unsure whether that one will also be run by an unfriendly overlord..