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

[guest11527]

How would you class specific processors?

By the instruction set. Not by its internal workings.  

For instance, take Coldfire.
It certainly has some reduction compared to the 68060.
But is it an RISC cpu?

No. Unlike RISC CPUs, it is not a load/store architecture, i.e. it supports instructions such as "add.l d0,-(a0)" which affects memory as a side effect of the instruction. This has a couple of implications on exception handling - and makes it much harder to recover from them.  

Then there is ARM which grows upward in its higher end cpus, and yet strives to service the lower end with a more compact version of its basic instructions.
RISC? Of course, but one that strives to compete in the higher end (where CISC tends to dominate) and in the low end (where simpler cpus provide performance advantages (doubt me? seen any CISC Intel based cpus in cell phone?).

I do not know ARM well enough to tell, but given the size of the instruction and the number of registers, it is very much on the RISC side. Intel does have low-end CPUs (Atom), but they are not very successful marketing them.  

Then there is Power.
Risc?
Well...that was the original intention anyway.
And it holds true if you compare it to Intel's current lineup.

POWER is very much on the RISC side.    

Not a choice I am making, I use whatever works best)

Exactly. And that's precisely the point. My problem is to execute 68K programs. A PPC is not precisely good at it. It requires a software emulation layer, and that makes it comparably slow for the problem I want to solve. I cannot tell you how well it performs. I can only tell you how well my i5 here in the office performs at this problem. With all the emulation layers around it, I'm not very convinced that this is a good solution.

[wawrzon]

Exactly. And that's precisely the point. My problem is to execute 68K programs. A PPC is not precisely good at it. It requires a software emulation layer, and that makes it comparably slow for the problem I want to solve. I cannot tell you how well it performs. I can only tell you how well my i5 here in the office performs at this problem. With all the emulation layers around it, I'm not very convinced that this is a good solution.

you re feeding iggy

 what concens performance we had made some tests once upon a time, years ago, with mixed up float-integer real life apps, like ffmpeg  and ppc emulated 68k rather well (on os4) afair clock by clock. that means s 604 @ 150mhz was three times as fast as 060 @ 50mhz, but im citing from memory and i wont take responsibility for that now. certainly it doesnt mean much even on a single core in comparison to an intel/amd wit jit today. it night havw in the nineties though. dumb, the artificial ppc ideology is lasting here till today.

[psxphill]

I can only tell you how well my i5 here in the office performs at this problem. With all the emulation layers around it, I'm not very convinced that this is a good solution.

Your i5 running what software? If it's winuae then you've got the chipset emulation and windows that wouldn't be running. Once you only have to worry about emulating instructions and not counting cycles etc then you can emulate much more efficiently.

Putting an intel chip onto an amiga motherboard might seem like blasphemy, but it would have even less overhead than amithlon. The only annoyance is big vs little endian. For bytes you just xor the address with 3, for words you xor the address with 2 and dwords are the same. Which works great for aligned accesses (which for 68000 code is fine as it can only do aligned accesses). For unaligned accesses you can either put in a check and branch on every read/write to memory, or x86 can enable unaligned access checking and it will then throw an exception & get the exception handler to figure out what to do. If you are doing a lot of unaligned accesses the former is better, if you are doing very few unaligned accesses then the later is better. But it doesn't look like you can do it on windows, if you don't have an os getting in the way then it's a lot easier.

http://stackoverflow.com/questions/26919269/how-to-enable-alignment-exceptions-for-my-process-on-x64

I found out about a similar situation recently, on later slim playstation 2's (SCPH-7500x or later), the IOP (which handles IO and running PS1 games) is emulated by a PPC chip. The PPC code pretty much just runs an emulation of the cpu code, with only very minimal hardware emulation.

The best implementation would essentially be a modern bridge board, so you could run pc software on it at the same time as running amiga software. Or have it run a 68k emulator and access the amiga motherboard resources. Bonus points if you can make the keyboard and mouse appear as standard pc peripherals, not sure what you'd do about the floppy drive. But it's a dream, power would be tricky but doable, cooling would probably be harder.

[guest11527]

Your i5 running what software?

Several. It's a Linux system. I've tried eUAE, with rather mixed results giving me a system that boots incredibly slow even when emulating a 68040 at full speed (no speed brake active, really), so slow that I can see the workbench drawing the background image tile by tile. Then after a minute, it seems to recover and then works  for *most* things at acceptable speed. Something's broken.

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. Unfortunately, I'm not really into games.

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.  

Putting an intel chip onto an amiga motherboard might seem like blasphemy, but it would have even less overhead than amithlon. The only annoyance is big vs little endian.  

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.

The best implementation would essentially be a modern bridge board, so you could run pc software on it at the same time as running amiga software. Or have it run a 68k emulator and access the amiga motherboard resources. Bonus points if you can make the keyboard and mouse appear as standard pc peripherals, not sure what you'd do about the floppy drive. But it's a dream, power would be tricky but doable, cooling would probably be harder.

Well, that sounds much more like a plan than the PPC experiments here in Amiga land, if you ask me. It would also give you a computer that could do something productive (ehem) if you don't want to run it on an Amiga.

The problem with emulation is really that - depending on what you emulate - the performance might be "very reasonable" to "dog slow", and that on exactly the same machine. See my experience with eUAE. Depending on what I do, it is quite acceptable (excluding anoying user interface glitches, another discussion) to "unbearably slow", as soon as you do something with the chipset.

Yet again, it is a matter of your problem definition: For me, the primary purpose is 68K code execution, and *for that* the vampire is just an excellent solution (or might become one, depending on your needs). A x64 might also be a *workable* solution, with an added bonus on top that you could also run something "useful" and "productive" (i.e. "non-Amiga", excuse the irony) on it.  

What I need a PPC for I still haven't really found out. Nice machine, sure. But that's all about it. Yes, I do have an old G3 Power Mac at home, 233Mhz, ATI graphics. Works - that's the best to say about it.

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

[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

[clebin]

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. Unfortunately, I'm not really into games.

At a guess, you downloaded the wrong version, ie. without the Launcher (listed as emulator only (No configuration GUI)). That requires you to have or create a text config file.

Make sure you download the one with FS-UAE Launcher and then you can set up and save a configuration with hard-disk/kickstart/etc just like in WinUAE.

[Dandy]

...
Putting an intel chip onto an amiga motherboard might seem like blasphemy, but it would have even less overhead than amithlon. The only annoyance is big vs little endian.
...
The best implementation would essentially be a modern bridge board, so you could run pc software on it at the same time as running amiga software.
...

Hummm.
If something like a "realtime endian converter chip" existed and would be used in conjunction with an Intel CPU for an Amiga motherboard or accelerator board - could that work?

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?

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

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

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

[Iggy]

Several. It's a Linux system. I've tried eUAE, with rather mixed results giving me a system that boots incredibly slow even when emulating a 68040 at full speed (no speed brake active, really), so slow that I can see the workbench drawing the background image tile by tile. Then after a minute, it seems to recover and then works  for *most* things at acceptable speed. Something's broken.

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. Unfortunately, I'm not really into games.

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.

 

Well, that sounds much more like a plan than the PPC experiments here in Amiga land, if you ask me. It would also give you a computer that could do something productive (ehem) if you don't want to run it on an Amiga.

The problem with emulation is really that - depending on what you emulate - the performance might be "very reasonable" to "dog slow", and that on exactly the same machine. See my experience with eUAE. Depending on what I do, it is quite acceptable (excluding anoying user interface glitches, another discussion) to "unbearably slow", as soon as you do something with the chipset.

Yet again, it is a matter of your problem definition: For me, the primary purpose is 68K code execution, and *for that* the vampire is just an excellent solution (or might become one, depending on your needs). A x64 might also be a *workable* solution, with an added bonus on top that you could also run something "useful" and "productive" (i.e. "non-Amiga", excuse the irony) on it.  

What I need a PPC for I still haven't really found out. Nice machine, sure. But that's all about it. Yes, I do have an old G3 Power Mac at home, 233Mhz, ATI graphics. Works - that's the best to say about it.

G3 @233? Yes that would be painful. Rather like trying to run an old Pentium cup.
As I have said before, I have a quad core 2.5 G5 Power Mac running Ubuntu Mate.
More than powerful enough.

[JimDrew]

One of the things that was added to the Apollo core is the ability to reorder any bits using a single instruction.  There is also the capability to move from memory to a register (vice versa) doing a byte swap and/or word swap.

PCx is the PC emulation that I wrote.  Intel is in fact backwards endian from Motorola.  So, every word and longword fetch for the instruction look to emulate the x86 CPU requires byte/word swapping.  This adds a lot of extra time.  So, I made a version of PCx for the Vampire board that uses the new instructions... I see maybe a 5% increase in speed over the stock PCx.  Why?  The pipeline architecture is so good in the Apollo core that swaps are virtually absorbed.

[JimDrew]

One of the things that was added to the Apollo core is the ability to reorder any bits using a single instruction.  There is also the capability to move from memory to a register (vice versa) doing a byte swap and/or word swap.

PCx is the PC emulation that I wrote.  Intel is in fact backwards endian from Motorola.  So, every word and longword fetch for the instruction look to emulate the x86 CPU requires byte/word swapping.  This adds a lot of extra time.  So, I made a version of PCx for the Vampire board that uses the new instructions... I see maybe a 5% increase in speed over the stock PCx.  Why?  The pipeline architecture is so good in the Apollo core that swaps are virtually absorbed.  Kuddos to Gunnar.

[guest11527]

So, I made a version of PCx for the Vampire board that uses the new instructions... I see maybe a 5% increase in speed over the stock PCx.  Why?  The pipeline architecture is so good in the Apollo core that swaps are virtually absorbed.

Actually, that doesn't surprise me that much. Given the overall amount of cycles an emulator has to spend to emulate a host CPU - instruction fetch, operation and generation of condition codes - the endian swap is really a minor contribution to the overall execution time. I would guess you would see a similar increase if you would compare a little endian emulation on a (native) 68K with a emulation of a (non-existing) big-endian emulation on the same hardware.

[gertsy]

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?

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