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

[psxphill]

https://plus.google.com/communities/103199122169081959411 for those who didnt know what address to look for....

Looks very nice.. Vampire is bringing Amiga back to life

Almost makes me wish I'd kept the Amiga 1500 that I sold a few years ago. A silent power supply would definitely do it.

[psxphill]

Not really. You should keep in mind that the PPC has longer opcodes, and performs less operations per opcode as it is a risk processor.

PPC & 68060 appear to have quite similar instruction rates. RISC processors were designed for the type of operations that C compilers needed. So there may be times you can code something more efficiently on a 68060, if you're writing in a compiled language then the difference won't be anyway near as pronounced as you say.

The problem is that getting an FPGA to run at a speed equivalent to a 100mhz 68060 has taken a long time and is likely the top end of performance for that FPGA no matter what CPU you are simulating. It doesn't make sense to him because you would have to dedicate the same amount of time to create a PPC and it would only have the performance of a 100mhz 68060. You can beat that with ancient PPC that nobody wants to buy anymore because they are too slow.

[psxphill]

PPC was Motorola's attempt to jump on the bandwagon of the latest fashion at that time, which was "risk".

I'm struggling to take you seriously as you keep calling it "risk" when it is RISC.

Motorola got into the PowerPC project because IBM had persuaded Apple to switch from 680x0 to a new chip based on their POWER architecture. Apple invited Motorola to join. Apple knew that Motorola had more experience in making single chip microprocessors, but also having two sources gave them more bargaining power.

I'm sure there are examples of 1 68060 instruction needing to be expanded to 3 PPC instructions. But the question I would ask is how often those types of expansions occur & whether it's mitigated by any situations where the opposite occurs and whether the PPC can run multiple instructions more often than the 68060.

I'm reasonably confident that if someone put the same effort in then they could create a PPC that has a similar real world performance to a 100mhz 68060. Finding that person is the hard part. Especially as it's far slower than the original PowerUP boards, let alone the SAM/X1000 etc.

What would make sense is for there to be a board that allows you to fit an FPGA and an off the shelf PowerPC, so that people don't have to choose between vampire or a phase 5 PPC.

[psxphill]

Sure - as said, RISC ("risk") was a fashion statement back then, and people believed that it would be a beneficial architecture. In some sense, this is true, but I would believe that history tells now something different.

It was a beneficial architecture when it was introduced, not a fashion statement at all. What happened over time however is that the percentage of a chip that is risc vs cisc became so small that for computers the benefit is towards the chip that has market traction, which was x86 and is now x64. The phone market has proved that when there are other factors in play (like power usage and licensing the cpu to use in a SOC) that a RISC cpu like Arm can still sell in large numbers.

The Pentium Pro was Intel's first chip where the code was translated into another form, which is effectively executed by a RISC cpu. The translated code is cached, so loops are fast etc.

Again, I consider this somewhat pointless given the rather small software library for PPC on the Amiga - or possibly - the typical "applications" Amiga has found today. That's of course a completely different argument.

It's in my eyes mainly a retro system - if you want to make it fast by a modern CPU, one would pick an intel design and RTG graphics and not PPC and custom chip graphics. Wait, that's called a PC, right? (-:

I'm not talking about making it as fast as a modern CPU. I'm talking about making it fast enough to run late 90's Amiga PPC software. That sounds pretty retro to me. It wouldn't hurt if it could go quicker of course, but compatibility and price are the most important aspects. Arguing to use RTG graphics instead of custom chip graphics seems a little odd, on a thread about vampire which has it's own custom graphics.

Apple had developed a secret quad-core RISC chip that was very powerful (for the time) but would make new Macs incompatible with the 68k software base. Sculley was not enthusiastic about this at all (I think because it was a leftover from Jobs and the mac market was pretty soft for this kind of shock by 1988).

Project Aquarius was going nowhere.

http://lowendmac.com/2006/growing-apple-with-the-macintosh-the-sculley-years/

Sculley loved it, he hated that it was going nowhere and the chip designer they had hired thought it was impossible.

Anyway, IBM, Motorola, and Apple watching the rise of Wintel felt this could benefit them all to some degree. IBM had POWER but no real traction, Apple riding a dead end platform, Motorola looking to help fight off Intel. The AIM alliance was a good one.

Motorola wasn't there to help fight off Intel, they were there to make money. Apple had decided to ditch the 680x0 cpu's, but aquarius and all the other internal projects had failed. Motorola's own RISC CPU (the 88000) was a disaster, so after IBM contacted Apple and got them excited about POWER then joining up with IBM was Motorola's only chance to hold onto some of the pie.

Apple even had an OS running on x86 before they had it running on PPC, but when that project collapsed they quickly hacked something together to run on PPC and then bought NextStep. They knew that MacOS7/8/9 were a problem, but all their efforts to move away had failed. OSX has always run on x86, even though they never sold it until they started selling x86 hardware. I suspect they regretted choosing PPC for a long time, it was only the Pentium 4 failing that gave them any cause for celebration. When Intel realised they had to do something serious and went back to the Pentium 3 design and improved it to make Intel Core, then there really was no stopping them. The PPC didn't recover and even the PS3/Xbox360 cpu cores aren't that good.

https://en.wikipedia.org/wiki/Copland_(operating_system)

But we seem to be going off topic, PPC wasn't a great choice. But it was a choice that Phase 5 made, so it would be nice to be able to run PPC software as well as taking advantage of the new software for vampire.

[psxphill]

Oh, 'mon. Back in those days, it was "RISC" here, "RISC" there, all around.

Berkley RISC-I CPU outperformed every other single chip microprocessor in 1982. People talk about things that are good.

[psxphill]

Now if the CISC CPU upgrades and does 4 instructions in a single cycle then the CISC CPU does the amount of work of 8 RISC instructions per cycle.
This means now the 68080 CISC CPU is many times faster then the RISC.

Very easy to understand.

It is easy to understand. However the 68060 didn't do 4 instructions in a single cycle. So it sounds like you are comparing optimised vampire to an existing PPC chip, which wasn't relevant to the decision made to switch from 680x0 to PPC in the 90's.

It's also not relevant now, unless you can software emulate the PPC on vampire quicker than a phase 5 PPC board.

I'm interested in how maintainable that 4 instructions in a single cycle is. I assume that doesn't involve touching ram in any way, i.e. both code and data all fits in caches. Also how complex are the instructions?

X86 would have been a much better choice, but a choice that wouldn't have been accepted by users that are driven more by ideology than technology. The x86 chips are probably an unorthogonal mess, but they are still high performing, powerful chips.

I don't think enough Mac owners would have cared what CPU it had, as it would still have been marketed as better than a PC. Apple didn't even wait for x64 to jump to Intel and they have ditched support of x86 now. If Microsoft dropped support for x86 then there would be mass outrage, but it's socially accepted that it's ok to hate Microsoft. If you disrespect Apple then you damage the brand and then people might question why you paid extra for it in the first place.

[psxphill]

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.

[psxphill]

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.

[psxphill]

Oh no, trust me... PPC is junk.  I know it quite well!  I would use an x86 over a PPC any day.

I'm sold, lets forget these slow fpga's. Who is going to make an i7 accelerator for the a1200?

[psxphill]

this way it wouldnt give us mmu either as it doesnt work with jit.

It could, you might even be able to use the x86 mmu/virtualisation to do it.

Then you don't need to do anything special with memory apart from endian issues.

You'd probably need to use one of the low power i7's that they use in the surface pro 4. A core m3 would probably be good enough though http://ark.intel.com/products/88198

[psxphill]

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?

What is the speed of something that we will be able to buy and fit to an a500/a600/a1000/a1200/a2000/a3000/a4000/cdtv/cd32?

[psxphill]

Here is the AIBB speed comparison of the cards that you can buy TODAY for A600 / A500  / A2000 / A1000

http://www.apollo-core.com/index.htm?page=performance

Where can you buy one today? All I found was a place to pre-order one.

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

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