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

[Iggy]

All these execution per clock comments just crack me up.
If you to look at it this simplistically, a 6809 would look just as good as a 68000 in that the 6809 executes memory reads or writes in one cycle while the 68000 requires four cycles.
Of course the 68000 can do this on a bus that is twice as large, so comparing an 8 bit processor (with some limited internal 16 bit capability) to a 32 bit processor (even if it addresses memory on a 16 bit bus), is perfectly silly.
As to comparing a 200-300 MHz 68K equivalent (or even 68040 equivalent) to a PPC, that's completely absurd.
When you have your hardware, run ANY basic benchmark for CPU performance and memory bandwidth and I'll throw you back figures from a relatively slow PPC based system.
If you really think you're going to approach it, you're delusional.
There was a reason Motorola halted development of the 68K.
But then I guess you guys (and Gunnar) know better.
Right?

Look I have an A2000, and this looks tempting, but there is no real contest.
If I decide to buy a Vampire for my A2000, I'm still buying an X5000.
Because even a Tabor board would mop up a Vampire based computer.
And an X5000 is going to be much more competent than Tabor.

You guys can argue whatever you'd like, but you you can't have a separate set of facts because the truth is...well its reality.

So before you sound too much like "the moon landings were fake" conspiracy nut jobs (or worse yet, people dumb enough to buy into Donald Trump), take the tinfoil cap off your head, get a cool drink of water and think this over.

Its FPGA based, and not even a high end FPGA (which would cost big bucks), so its never going to be competitive with an even moderately modern ASIC.

[Iggy]

And a modern Intel/AMD-System runs cycle around your X5000 at a fraction of cost. Now what? Let Gunnar have his fun there.

Seriously? I'm thrilled that Gunnar pulled this thing off.
I worked for several years for a firm that sold 68K based systems.

And its going to completely flatten any other 68K based upgrades.
For that matter, if you were comparing the Vampire to a 200-300 MHz PPC (like those on a Amiga accelerator) it might very well win.

BTW - My X64 system is faster than yours. :laugh1:
But I still like the PPC based stuff.
My over 10 year old 2.5 GHz Quad core G5 PowerMac runs Ubuntu Mate with about the same performance as my Core2 Quad (which in itself is much faster than my i7 laptop).

Its all up to what you value.

My only real problem the Gun is that we were discussing a cross platform game a few years ago, now I regularly get to hear these silly comments "we though about PPC...".
No you didn't because an FPGA based PPC would really suck compared to the real thing.

[Iggy]

Well, for one it runs on real hardware.

Secondly, it's faster than 132MHz PPC PowerMacs from back in the day when running FUSION.  No need for PPC... it's junk anyways.

Again, hilarious, having worked with both.

BTW - 68080 would not be a good designation. That would place it immediately after the Signetics 68070, which performs worse the a standard 68000.
And the Apollo core does perform better than a 68000, just not anywhere near a PPC.

"...it's junk anyways" - Is this the point where we are supposed to descend to quips about each other's mothers?

So, once again, provide any basic benchmark that measures cpu or memory performance.
God, I feel like a bully here.
But I feel compelled to address your sniveling twitness.

[Iggy]

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

Hey Gunnar,
I wasn't sniping at your core, I'm damned impressed.

Nope, it was the tired old argument about ISAs.

But then I guess we could stick things in this order:
68K...PPC...X64
And I still wouldn't be happy, as I really freaking don't like the Intel.

Hey, have you ever considered just a 68K processor replacement?
I'd kill to update a old PT68K4 board with something this radical.

[Iggy]

Can we just lock or split this thread so we can discuss the original topic somewhere?

It's embarrassing how badly Amigans fit their angry, argumentative pseudo-religious stereotype.

This is why we can't get anywhere while the Atari guys can replace their whole OS and hardware from scratch. We'd rather argue over pointless details of which is the one true CPU (newsflash: they all have pros and cons) than to be pragmatic and work together.

"...which is the one true CPU"
And one cpu to rule them all!
Yeah, it gets silly.

As to the Atarians, their work on their OS', and the new hardware (like FireBee)...it still works like an Atari - no thanks.
Although...since they did provide a gui-less OS for my Coldfire development board that's pretty cool.

Hey, THAT'S IT!
We need to chastise ourselves for using every other cpu option except Coldfire (not really, as I explored it and dismissed it awhile ago - but its funny).

[Iggy]

iirc Jim has a long history of hardware design.

I've read Jim's quotes and whether he has a history or not seems irrelevant as he apparently either has developed biases or...he simply doesn't  know what he is talking about.
CISC vs. RISC - the important factor is IPC (or in most cases cycle per instruction).
The reason CISC seems to do more is that the instructions DO, but in how much time?

It is a question of efficiency.

AMD uses RISC at the core of all recent CISC cores.
CISC instructions are decoded internally into strings of RISC instructions.
If the CISC instructions were more efficient, they simply wouldn't bother?

I built my first computer in the '70's (you know, kind of "here's the bare board, now populate it, debug it, THEN try to get software working on it").
I continue to work with hardware to this day.

If I'd paid attention to all the "Jims" along the way, I would have made some pretty dumb decisions.

Remember, success in the market is NOT always tied solely to specific design issues.
The factors that influence  that are far more complex.

[Iggy]

...The Apollo Cores in the Vampire boards are FAST for a 680x0 compatible FPGA core on a low cost FPGA.

No, not really.
The 680x0 is just really slow compared to even the low-end FPGAs of today.

Its an Apples and Oranges comparison.

The former started out about 30 years ago.

[Iggy]

So does intel. You seem confused.  

The point why CISC works better these days is because the instructions are shorter, and memory bandwidth and cache capacity matters more than back then.  

Shorter, more powerful instructions -> more instructions fit into the cache, more work is done per instruction.

Once the instruction is in the internal wirings of the CPU, it does not really matter anymore. The CPU can operate at the full clock rate, and *there* it makes sense to split the instructions up into smaller units because you can pipeline the pieces. It's much more convenient for the CPU core.

That IS a good point, but confused? Not really.
A little bit it favor of one approach, a little for the other.
Using coarse definitions like CISC or RISC is somewhat deceptive.
How would you class specific processors?
For instance, take Coldfire.
It certainly has some reduction compared to the 68060.
But is it an RISC cpu?
After all, its still an offshoot of the 68K family.
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?).
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.

One or the other?
Not a choice I am making, I use whatever works best)

[Iggy]

Huh? How fast an FPGA is depends on what it is programmed to do. Yes, an FPGA will be slower than an ASIC, and that will be slower than raw silicon. But we don't have any.

Yet, technology advanced, and an FPGA can be programmed to be faster than raw silicon back then. That's not surprising.

What might be interesting in how far the FPGA hardware "emulation" performs compared to a software emulation on top of a PPC. I wouldn't hold my breath, but my best guess is that the FPGA is here the better option.

OK...now you have managed to confuse me.
Yes, faster, like ALL modern silicon, FPGAs have benefited from a reduction in process.
So, to give you a crude example, I can run a 6809 in a CycloneIII  based system (like my Altera DE-1) at 25 MHz.
Fastest legacy compatible?
The 63C09 which is listed at 3 MHz (although I run those at 3.58, and some have them clocked at 4 MHz or higher).

680x0?
Exactly the same.  Slow in legacy hardware, faster in newer FPGA based designs.

So crediting Gunnar for the speed of the device is completely deceptive.
And we haven't even addressed the ability to do things in in the FPGA re-implementation that weren't done in the legacy design (these are factors you CAN credit Gunnar for some of, and frankly, they are more important).

So...yes, when running older designs via FPGA there will always be improvement.
Newer designs?
Always a performance reduction.

Any other issues, Thomas?

BTW - FPGA emulation versus the use of a higher end cpu?
I want to know about that answer too.
The factors are complex.
The speed of a newer cpu would be uniformly much higher, but as someone who has had a hand in 6809 emulation under the 68000, I can tell you there is a great deal lost in the interpretation and translation.

However...I wouldn't get ready to inflate yourself at this point as we are talking about FPGAs that only run at about 10% of the speed of dedicated silicon.
Would a Vampire based system beat a PPC in the execution of 68K code?
My guess is that it would be closer to a draw.

Then there are the legacy Amiga elements outside the cpu that the FPGA provides for.
That will get really interesting when it come to comparisions.

However, a decent PC running something like UAE would probably have some advantages in a few areas (and the Vampire would in others).
Again, too complex to address in theory, lets benchmark.

Oh, sorry, one last thing.
What would the Apollo core manage in an ASIC?
Now there is an interesting proposal.

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

[Iggy]

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

hah! now that IS funny. :hammer: