Welcome, Guest. Please login or register.
Amiga Kit Amiga Store Hollywood MAL AMIStore App Store A600 Memory

AuthorTopic: A2080 i.e. Vampire 500 V2 on an Amiga 2000  (Read 668 times)

0 Members and 1 Guest are viewing this topic.

Offline Thomas Richter

Re: A2080 i.e. Vampire 500 V2 on an Amiga 2000
« Reply #60 on: August 12, 2016, 08:12:20 AM »
Quote from: psxphill;812438
Berkley RISC-I CPU outperformed every other single chip microprocessor in 1982. People talk about things that are good.

Which was about the best thing you could do in 1982 on a CISC CPU back then - but look, the "boundary conditions" changed over the time, as the complexity in the CISC cores increased, and memory bandwidth did not increase proportionally. In 1982, CISC CPUs where mostly controlled by microcode, hence slow. A 68K required multiple cycles for a single instruction, a much less complex RISC design could be "hardwired" and execute a (simpler) instruction in one or two cycles.  Now, technology advanced. 68060 was hardwired again, and could run many instructions in one cycle - and by offloading some computations to the sEOP, even multiple instructions in parallel in some cases. But complexity had its price - early releases of the 68060 were/are buggy.   It's a complexity/development cost/execution speed trade-off. In 1982, nobody believed that one could hardwire a CISC core in silicon, or those that tried have failed (Z8000, anyone?) due to complexity - and that memory bandwidth and code density was not an issue. Back then, this seemed all plausible. RISC is faster to the market, cheaper to design, simpler to upgrade, simpler to upscale, or so it seemed.  That its design parameters - lower code density - would at some point work against it was not exactly expected.
 

Offline biggun

Re: A2080 i.e. Vampire 500 V2 on an Amiga 2000
« Reply #61 on: August 12, 2016, 08:56:26 AM »
Quote from: Thomas Richter;812454
RISC is faster to the market, cheaper to design, simpler to upgrade, simpler to upscale, or so it seemed.  That its design parameters - lower code density - would at some point work against it was not exactly expected.


Thomas is spot on here!

The main design goal of RISC CPUs was to be simpler and cheaper to do !
The main goal was NOT to have the fastest possible CPU - clock by clock.

A well tuned CISC is harder to develop than a RISC.
But a well tuned CISC is also faster than a RISC.

Offline psxphill

Re: A2080 i.e. Vampire 500 V2 on an Amiga 2000
« Reply #62 on: August 12, 2016, 05:23:06 PM »
Quote from: Thomas Richter;812454
In 1982, nobody believed that one could hardwire a CISC core in silicon

No, you could do it. The problem was the size it took. Microcode allowed you to fit complex instructions into a smaller space. RISC was just an alternate way to reduce the space taken on the die. It was all about pushing the envelope as that is how you got someone to buy your product over someone elses. Once you got your CPU core size down then you could fit in more registers & larger caches.

The Pentium Pro merged CISC & RISC, it had the benefit of being able to run all the same code that a Pentium could (although 16 bit code was quit a lot slower) but was essentially a RISC chip.

The lines between RISC & CISC have blurred considerably and it matters little what the actual code you are executing, because it's likely to be translated into another form anyway.

Memory bandwidth is terrible so running uncached will seriously slow down any cpu whether it's risc or cisc. But as fetching and executing have become a less tightly coupled process, then it's probably not that important either.

First time round executing code it might make a difference, but once it's in the cache (loops or subroutines) then the internal representation is likely to be similar for the same amount of work. You can even fetch and translate code ahead of time.

If a RISC design was able to more accurately predict what code needed to be in the caches (both kept and prefetched), then it would erode any benefit the CISC design had when filling the caches. It may even end up with a positive for the RISC design.

The PS3/Xbox 360 cpu show what a mistake it is to rely on brute force, the PPC in it is very weak but it can run at a high clock speed (but then it needs to get the same performance as the more traditional PPC).

Although code density is enough of an issue that Arm ended up going with a much higher density for thumb code, it's a pity that there wasn't an Arm chip that Apple could have used at the time.
« Last Edit: August 12, 2016, 05:26:29 PM by psxphill »
 

Offline kolla

Re: A2080 i.e. Vampire 500 V2 on an Amiga 2000
« Reply #63 on: August 12, 2016, 06:15:00 PM »
Apple has used ARM since at least the Newton was developed.
B5D6A1D019D5D45BCC56F4782AC220D8B3E2A6CC
 

Offline biggun

Re: A2080 i.e. Vampire 500 V2 on an Amiga 2000
« Reply #64 on: August 12, 2016, 07:27:50 PM »
To clarify the open question:

Goal of the Apollo/Vampire card is _NOT_ to run PPC software.

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

Offline psxphill

Re: A2080 i.e. Vampire 500 V2 on an Amiga 2000
« Reply #65 on: August 12, 2016, 08:14:58 PM »
Quote from: biggun;812486
To clarify the open question:

Goal of the Apollo/Vampire card is _NOT_ to run PPC software.

I don't think anyone thought it was.

If a PPC and Apollo could somehow be plugged in at the same time then we wouldn't have to choose.
« Last Edit: August 12, 2016, 09:01:36 PM by psxphill »
 

Offline kolla

Re: A2080 i.e. Vampire 500 V2 on an Amiga 2000
« Reply #66 on: August 13, 2016, 01:41:20 AM »
Quote from: biggun;812486

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?
B5D6A1D019D5D45BCC56F4782AC220D8B3E2A6CC
 

Offline wawrzon

Re: A2080 i.e. Vampire 500 V2 on an Amiga 2000
« Reply #67 on: August 13, 2016, 03:24:28 AM »
Quote from: kolla;812492
So you plan acc cards for old 68k macs and ataris as well?


i think if anyoune came around with an appropriate expansion design, why not. though f i observe right, you can run macos, dosbox, probably atari and soon aros with reasonable speeds on your amiga/vampire box already, let alone potential standalone system. whats wrong with it?
 

Offline kolla

Re: A2080 i.e. Vampire 500 V2 on an Amiga 2000
« Reply #68 on: August 13, 2016, 08:43:52 AM »
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.
B5D6A1D019D5D45BCC56F4782AC220D8B3E2A6CC
 

Offline Iggy

Re: A2080 i.e. Vampire 500 V2 on an Amiga 2000
« Reply #69 on: August 13, 2016, 10:01:07 PM »
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.
« Last Edit: August 13, 2016, 10:03:27 PM by Iggy »
"Not making any hard and fast rules means that the moderators can use their good judgment in moderation, and we think the results speak for themselves." - Amiga.org, terms of service

"You, got to stem the evil tide, and keep it on the the inside" - Rogers Waters

"God was never on your side" - Lemmy

Amiga! "Our appeal has become more selective"
 

Offline QuikSanz

Re: A2080 i.e. Vampire 500 V2 on an Amiga 2000
« Reply #70 on: August 13, 2016, 10:43:38 PM »
Quote from: Iggy;812515
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.


OS4+ is a much bigger OS so of course it needs more resources, same with all its programs.
 

Offline OlafS3

  • Lifetime Member
  • Hero Member
  • *****
  • Join Date: Oct 2009
  • Posts: 1541
  • Total likes: 0
Re: A2080 i.e. Vampire 500 V2 on an Amiga 2000
« Reply #71 on: August 13, 2016, 10:47:09 PM »
Quote from: Iggy;812515
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.

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

Offline QuikSanz

Re: A2080 i.e. Vampire 500 V2 on an Amiga 2000
« Reply #72 on: August 13, 2016, 11:01:25 PM »
Quote from: OlafS3;812518
And a modern Intel/AMD-System runs cycle around your X5000 at a fraction of cost. Now what? Let Gunnar have his fun there.


+1
 

Offline Thomas Richter

Re: A2080 i.e. Vampire 500 V2 on an Amiga 2000
« Reply #73 on: August 13, 2016, 11:52:30 PM »
Quote from: Iggy;812515
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.
Well, but that's because the 68K is microcoded. The 68060 is not, and it requires only one cycle for all simple instructions. And 4 cycles/instruction also only holds for simple ones on the 68K. I do not know about the 6809, but it is likely that this is a hardwired design. At least the 6502 was,  but of course both are much simpler, so no surprise. If you look at microcode, the Z80 required much more cycles for similar instructions - same problem.  
Quote from: Iggy;812515
As to comparing a 200-300 MHz 68K equivalent (or even 68040 equivalent) to a PPC, that's completely absurd.
To bring this back to an apples vs. apples comparison, you *can* compare it to a 233 MHz G3-PPC, which existed back then. Still have a machine sitting somewhere in the basement. I do not know what the result might be, but I wouldn't be too much surprised if the G3-PPC @ 233Mhz would - on approximately equivalent algorithms - perform worse.

Yes, of course, *that* is a pretty slow machine (an old power mac) by today's standards. Don't tell me, I'm perfectly aware of this.
Quote from: Iggy;812515
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.
You can certainly do that, but then that's not what my software runs on. It would - at best - run under emulation under the PPC, and that gives you yet again completely different figures.

When we talk about about emulation - and we can do that of course - then what do I need a PPC for in first place? I've here a pretty nice i5 sitting in my office. fsUAE is not exactly usable on this machine due to the bad quality of the user interface and the overall integration of the system, but *if* you want to compare raw horse power, not counting the quality of the emulation, the GUI, the system integration and the performance of the chip set emulation, my immediate guess would be that this is quite a bit faster than emulation on any PPC you can buy today.

Unfortunately, that's not exactly a usable solution for me - actually neither the PPC.  
Quote from: Iggy;812515
But then I guess you guys (and Gunnar) know better.
Right?

It's a matter of the problem definition, or your requirements. Not a matter of "knowing better". If your goal is to have an Amiga system that feels like an Amiga system, then that's a perfectly fine option.  
Quote from: Iggy;812515
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.
And I don't have a problem with that, either. Go, have your fun - if this is what you want, why should anyone stop you.

Just because you consider this a good hobby, does not mean I do. But that doesn't make things better or worse.  
Quote from: Iggy;812515
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.
Conspiracy? I don't think anyone here has illusions on the performance of the system, or on why the 68K development was stopped. That was certainly not a conspiracy of any kind. It was a market decision Motorola made, and a plausible one back then with the facts they had. Looking back, with what we know today, it was probably not the ideal decision, but so what. No hard feelings about it.  
Quote from: Iggy;812515
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.

Sure, and your point is? I mean, is anyone seriously considering doing - or willing to pay - an ASIC? It's not a realistic option in first place, so why bother?
 

Offline kolla

Re: A2080 i.e. Vampire 500 V2 on an Amiga 2000
« Reply #74 on: August 14, 2016, 12:41:47 AM »
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.
B5D6A1D019D5D45BCC56F4782AC220D8B3E2A6CC