Apollo Team announces the Vampire V4

[QuikSanz]

Not following the analogy.  I think Gunnar is listening to his market.

C= certainly didn't, and paid the ultimate price.

I hope there is an internal audio header for Repulse. That way I can switch between Internal, CDRom and Paula.

[psxphill]

Not following the analogy.  I think Gunnar is listening to his market.

C= certainly didn't, and paid the ultimate price.

Gunnar doesn't appear to listen to his market, the market is so desperate that they are listening to him.

The analogy is that just because people buy things, doesn't mean it's any good.

Also if it were better (i.e. compatible fpu and mmu) then more people would want it. Unless you are saying they purposefully crippled the design to reduce demand.

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.

FWIW Commodore also had more people wanting to buy hardware than they could produce. It was the XOR patent license fee that did them in, not a lack of customers.

[wawrzon]

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.

may be. but then what market would that be for?

030 embedded replacement? but then why even 040 and 060 instruction compatibility? why extra features?

060 replacement? but then why no full mmu and fpu compatibility?

coldfire replacement? it isnt compatible at all, in the shape its tested and provided for amiga community? if it was meant as coldfire replacement why even bother for amiga compatibility?

and what about superaga? of what value is it washing mashine or aircaraft industry? why even bother with amiga chipset if you want an embedded chip?

[Kremlar]

Gunnar doesn't appear to listen to his market, the market is so desperate that they are listening to him.

I disagree.  

The analogy is that just because people buy things, doesn't mean it's any good.

I think that's a poor excuse for your reasoning.  Clearly if Vampire did not have features people wanted they would go with a difference accelerator.  There are reasons why Microsoft and Apple could sell an inferior product, none of which apply to the Apollo team.

Also if it were better (i.e. compatible fpu and mmu) then more people would want it.

True, but more people would also want it if it were:
 - faster
 - standalone
 - had full AGA support
 - etc.

FPU/MMU aren't the only features left to add.

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.

Which explains why AGA support is such a high priority.  Oh wait...

FWIW Commodore also had more people wanting to buy hardware than they could produce. It was the XOR patent license fee that did them in, not a lack of customers.

LOL!  Commodore was in serious trouble way before then.  You're looking back through rose colored glasses if you think Commodore would have lasted.  The  CD32 was OK, but was not going to save the company.  Now, if  you told me that AAA or Hombre or better, along with a new generation of machines was about to be released, I might be slightly on board.

[kolla]

coldfire replacement? it isnt compatible at all, in the shape its tested and provided for amiga community? if it was meant as coldfire replacement why even bother for amiga compatibility?

https://web.archive.org/web/20150901065243/http://www.apollo-core.com:80/

Apollo is code compatible with the Motorola M68K and ColdFire families.

This was two years ago. Since then, the project has turned left and right and left again a few times, for various reasons. Maybe someone realized that his amazing new cpu was not so amazing after all? Maybe he realized that the embedded market already have 68k softcores that takes care of its legacy needs? Who knows.

[wawrzon]

https://web.archive.org/web/20150901...o-core.com:80/

yes, buts its not whats being tested with the amiga community, so if they aim at coldfire replacement why dont they test coldfire features and instead test 68k and amiga features with the amiga community.

besides, what you obviously dont know, gunnar was considering coldfire as base for his project, or as cpu solution for natami project at that time. the threads about it are certainly preserved on a1k, in german. he and his associates have been even sponsored wit coldfire evaluation boards by former bplan owners. and they evaluated it and confirmed it inappropropriate for amiga acceleration task, which was exactly the reason to develop an own faster 68k core.

Who knows.

yes, who knows. so simply draw you occam razor, treat it as a black box and stop trying to find some scar on that project, that only exists in your prejudice. its not for you, it may not be for me, fine. but why refrain to poetry to make it look bad for others?

[kolla]

Gunnar doesn't appear to listen to his market, the market is so desperate that they are listening to him.

The biggest challenge is attracting developers, people willing to commit to the rather big effort it is to move to a new 68k architecture. Gunnar has repeatedly uttered his frustration over lack of people interested in coding for him. He said this why there is no FPU - lack of interest from develeopers. But then he also says that they don't need any more people to "test" the FPU, and the few developers who did offer to help were shunned off because they rather want compatibility than new bling-bling, since new bling-bling means no support in existing developer tool chains, and assembler only. I wonder how long this situation will persist, if someone is willing to update the 68k backends for gcc and clang/llvm to support the Apollo Core - that would be a mile stone.

I also wonder if the Apollo Team has done _any_ research or survey among developers regarding what features they want or lack.

Anyways, if Apollo Core cannot offer the solution wanted, something else will show up.

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

[guest11527]

Gunnar knows enough about the Amiga to build one from scratch.

You always seem to believe that the Amiga is a piece of hardware, whereas it is not. It is a combination of software and hardware in one entire system. I do not doubt that Gunnar has sufficient knowledge on the hardware part, though I have my doubts about "all the rest".

Certainly, as a hardware engineer, the software is usually seen as the "minor inconvenient part that must be somehow made working", but if you look at what the Amiga experience is about, it is also on the software around it.

Why do you think he does not know what needs with regard to compatibility there are?

Well, experience so far?

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?

Is that the case? Do you have evidence for this? I'm not so certain at all. No problem offering a fast 64-bit option, but I would be better safe than sorry.

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)

Huh? The 68060 already had a data and a code unit, as two independent units. Also two MMUs, the code and the data unit.

The MMU will not be 100% compatible to the previous 68k-MMUs as it seems.

No problem with that as long as it is "powerful enough" to address the needs of developers. Just to let you know again: 256K "page size" is certainly not sufficient for debug tools like MuGa. A PPC-type MMU would be, however, "powerful enough" even though it is completely different from the user (supervisor?) perspective.

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.

No argument about the priorities - that's certainly alright. I'm just not fine with general statements like "who the f*ck needs feature XXX". You never know what feature XXX in an Amiga was actually used for, at a certain point in history, and preserving legacy software is at the very heart of the project - as I understand it at least.

[psxphill]

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 of his refusal to produce a compatible fpu and mmu.

The final core will have 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.

Accordingly the scarce development resources are being used for developing the chipset.

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.

I know you want to believe the best in him and I don't actually blame him for wanting to make money. I just think it's a pain in the arse as I don't think he'll succeed in the embedded market and it would be nicer if he'd focus on compatibility first. 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.

[mikej]

Meanwhile we (FPGAArcade) have a very stable/accurate chipset implementation.

The 68060 daughterboard is about to go to manufacture (pictures at Datastorm next week), and the CM3 compute module approach for CPU emulation looks very promising.

Our new (open source) CPU core continues to develop based on reverse engineering and the Replay main board is being updated with 28nm Spartan7. The current Reply1 board will continue to be supported.

More info on my forum or come chat at Datastorm if you are in Scandinavia.
Cheers,
Mike

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

[mikej]

Does it have an MMU and FPU?

The 68060 and CM3 softcore does yes. The new hardware core is designed to replace the TG68K and the first priority is accuracy (required for the AtariST demo scene amongst others).  

The fact it goes an order of magnitude faster than the current core in the Spartan7 is a nice bonus when required. We'll see how it develops. For the 68060/MMU/FPU the ARM SOC emulation offers the best price/performance ratio while keeping the rest of the system in the FPGA. I switch back to the internal core when accuracy is important (A1200/600/500 etc). I agree the TG68K is hard to maintain ( I do a lot of it), and it's important for the whole community we have a next gen open source core.

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

So I am (actually a CPU designer). ^^ So, what you are saying is the core is unmaintainable by anybody else? Sounds like some poor design decisions there. Even very complex ARM designs are quite clean and can be maintained, which is a requirement obviously in a commercial environment. What happens to your customers if Gunnar gets bored then?

/Mike

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

[mikej]

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?     You are a CPU designer and yet compare the complexity of a clean and orthogonal RISC architecture to that of the 68k?      Rest assured that Gunnar knows the requirements of the commercial environment. He has designed parts of the POWER8 and recently of some ARMv8 processor.

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.  It's pretty good at this. Given there is a massive open source effort here, they are pretty refined - and we don't care about the cycle timing as long as it's fast. The rest of the chipset is still held in the FPGA, so all the timing critical video stuff is spot on - and the CPU can get on with it's stuff. Very Fast. It also has build in "fast" memory, and an HDMI for RTG etc.

"clean and orthogonal RISC architecture to that of the 68k? "
No, I'm asking why Gunnar's implementation is difficult to maintain.

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