Apollo Team announces the Vampire V4

[grond]

Gunnar doesn't appear to listen to his market, the market is so desperate that they are listening to him. ... That does fit my observations that apollo isn't meant for amiga, this is just a test ground so people can do his QA and marketing and then he'll be off.

 Gunnar knows enough about the Amiga to build one from scratch. Why do you think he does not know what needs with regard to compatibility there are? Because he said that nobody would notice any difference if the FPU only computed with 64 bits of precision instead of 80 and that there is an opportunity for a trade-off?  The final core will have FPU and MMU. For technical reasons (the Apollo Core has two independent memory controllers like many modern CPUs do and unlike any 680x0 before it) the MMU will not be 100% compatible to the previous 68k-MMUs as it seems. Perhaps only at first, perhaps forever. The core will also have SAGA. Why would he spend that much work on SAGA if he didn't care about the Amiga market and only used us as guinea pigs?  It's so simple: the stand-alone needs a chipset implementation more than an FPU. Would be stupid to be able to use those great Amiga FPU-programs without being able to see their output, wouldn't it?  Accordingly the scarce development resources are being used for developing the chipset.

[grond]

Because of his refusal to produce a compatible fpu and mmu. He has repeatedly said that it won't have a compatible one. Even the disabled fpu doesn't produce the same results as a real fpu, because of his design.

 This is just wrong. The publically not available FPU is fully 040 compatible. May be you are a little confused about the compatibility among the different Motorola FPUs? The FPU in the 080 can even reach 882-compatibility level with some microcode.  

It's simple. He is only wasting scarce resources on developing SAGA because he can't use code from minimig/replay because he's keeping apollo closed source for his intended commercial use.

 This is wrong for several two reasons but let me tell you the most obvious: he has an agreement with Thomas Hirsch of Natami fame to have access to the Natami AGA implementation. No license problems at all. However, he has decided to code the chipset himself because he thinks it will be easier to incorporate it into the design and to expand it to become SAGA if he writes the code himself. This in addition to the fact that he already had his own untested AGA-implementation to build on.  

I know you want to believe the best in him

 I don't believe in him, I have been working with him. I have his VHDL-code on my harddisk.  

I don't think he'll succeed in the embedded market and it would be nicer if he'd focus on compatibility first.

 There is no either-or question. If you pay him, he will make a ColdFire-derivative of his core for you. That doesn't mean the 080 as seen in the Vampire were ColdFire-compatible (and thus partly 68k-incompatible). There is an 80 bit FPU but it is obviously much slower than a 64 bit FPU, even more so if you use 64 bit FPU macros available in more recent FPGAs.  

Apollo core in minimig on replay would be awesome, if we had the code then we could make changes where we don't like his decisions.

 Yes, and you could save the cost for a M.D. by doing open heart surgery yourself, get yourself a knife. You have NO idea how complex the core is. The entire idea of doing changes to the core yourself is ludicrous. Just the instruction decoder of the 080 is FAR more complex than the ENTIRE open-source 68k cores available (which, btw, have no FPU or MMU AT ALL, are quite buggy, have only partial 020 support at best and thus are far less compatible than the 080 could ever be). I am a microchip developer by profession, I know VHDL. There is no chance in hell I could do architectural changes to Gunnar's core.

[grond]

Our new (open source) CPU core continues to develop

Does it have an MMU and FPU?

[grond]

The 68060 and CM3 softcore does yes.

 The verb is singular but you mention two things to go along with it? What is the CM3 softcore? Farther below you mention an ARM SOC, so are you referring to some ordinary microcontroller running some qemu-type software CPU emulator?  

Even very complex ARM designs are quite clean and can be maintained

 You are a CPU designer and yet compare the complexity of a clean and orthogonal RISC architecture to that of the 68k?    

which is a requirement obviously in a commercial environment.

 Rest assured that Gunnar knows the requirements of the commercial environment. He has designed parts of the POWER8 and recently of some ARMv8 processor.

[grond]

The 68060 clearly contains both. The CM3 is a Rasp Pi ARM SOC
http://www.fpgaarcade.com/punbb/viewtopic.php?id=1221

We are experimenting with a CPU running an emulation for the 68K processor.

 OK, so there is no new open-source 68k softcore. A pretty good software emulator has been around for quite a while even though its CPU emulator isn't 100% bugfree and thus incompatible (yuck!): WinUAE.  

No, I'm asking why Gunnar's implementation is difficult to maintain.

For the same reason the LHC is difficult to build and maintain: it's complicated.  

The 68000 die is extremely simple and elegant actually, the complexity being in the microcoding.
/Mike

Um, yes. The 68k family didn't end with the 68000. And 8 or 16 MHz and an IPC of something like 0.25 doesn't cut it today. Having all flags available for the subsequent instruction to evaluate and executing several such instructions in the same cycle along with the complex address modes available for each of the instruction is something that makes the 68k a few orders of magnitude more complicated than an ARM.

[grond]

Yes, there will be, based on the layout extraction. Initially targeted as a very accurate 68000 replacement, but will be expanded to 68020 asap

Layout extraction? So you are going to do a Register-Transfer Level clone of the 68000? While that is interesting from a tech-archaeological point of view, how do you think such a "core" could be expanded for higher speed, newer architecture, superscalarity and so on? The only practical way to improve the outcome of the layout extraction would be to clock it faster than it was in the original silicon. The 080 already reaches the speed of a GHz 020 in a consumer level FPGA, though. No current FPGA could reach those speeds let alone the fact that you would somehow have to get the "core" to interoperate with more recent peripherals such as DDR3 RAM and the like. I wouldn't want to dig through a network of flip-flops and logic gates and try add a more modern memory controller...

[grond]

Presumably, Tony is doing is best to get the bugs out. However, bugs are normal, and I wouldn't be surprised if the Apollo core also has bugs, too, given that all the mot processors had some issues here and there.

Sure. And we have reported bugs we found in UAE which we use for comparison with what the 080 does. All well.  

The problem I see is inconsistent performance. On eUAE, I see situations where the emulator crawls so slowly it is simply unusable, while a couple of moments later at a different task it runs ahead at light speed. This is simply not acceptable for a good quality of experience.

I totally agree!  

WinUAE: well, it runs on Windows. I don't have Windows, and I don't pay Microsoft to be able to emuate an Amiga. I already have a perfectly working Os, without spyware, thank you.

I don't have any Windows either. But I understand that WinUAE is the mother-of-all-UAEs today.  

It seems that the Apollo core is an out-of-order design

No, it is still in-order but already very complex. ooo would be another order of magnitude more complex.

[grond]

We end up with a more accurate, open source, 68000/20 FPGA soft core - and potentially a faster one as well.

Faster than what?

[grond]

I need a cycle accurate 68000. I can extend this to 68020 and faster performance

This sounds like taking a steam engine apart in order to build a formula 1 car from the insights you get while doing it.  

but I think ARM emulation for the CPU core is the way to go for 68060/MMU/FPU etc.

MMU only if without jit and thus a lot slower than the 080. As Wawa already mentioned, the 080 is faster than WinUAE without jit even when running it on a PC. The ARM SoC certainly is a lot slower than a standard PC.

In any case, it's good to have options. Go ahead with your project, it will certainly find its market. I don't think you need 060 speed at all for your project/product to succeed. After all there even is a market for 020 and 030 accelerators 20 or 50 times slower than the 080. I'm not going to sell my Blizzard 1230 and I can see that there will always be people that want the original Amiga experience and not the what-could-have-been Amiga experience so to say.

[grond]

'What could have been'...hmm, nope 68K was dying.

I didn't specify the assumptions this hypothetical scenario would have been based on, did I?

[grond]

Gunnar is also among the first to sledge other people's work, and boasting about the superiority of his own without any modesty.

You know what? Most people manage to be proud of their work without having illusions of grandeur. I am really sorry that you don't have anything that you are proud of, maybe time to step up the game somehow?

And then there are those personalities who like to stalk other people's projects pointing out their deficiencies and expect to be thanked for it like "thank you for pointing out what an MMU and FPU may be used for; we know how to build a CPU but didn't know that!"

[grond]

this 'Stanley Brothers' form of marketing (qualifying the buyers).

Are you referring to the famous Bluegrass act?