Motorola 68060 FPGA replacement module (idea)

[psxphill]

This seems counter intuitive. Bit of a dig a Natami management I presume.

I was just highlighting the difference between how the FPGA arcade and Natami projects are being run.
 
It's not a dig and they are both within their rights to do whatever they want and however they want. As soon as I saw the debates about what instructions to add to the N68070, I knew it was doomed.
 
Real Artists Ship.

[ChaosLord]

It's difficult to predict the future, but I can't imagine there is anyone outside of the retro community that will ever have any interest in a 680x0 cpu core.

Your imagination is broken.  Please install Imagination v2.0 and reboot.

 There are far too many other SOC/ASIC/FPGA solutions that have already carved up the market. There is no competitive edge against any of the other alternatives and nobody in business will care if they can run 680x0 code.

You seem to care a lot about preventing any new 680x0 CPUs being built.

Are you now, or have you been an employee of Intel Inc.?
 

The majority of people want something that can run existing software and use existing compilers,

Matt's Level 1 design runs existing software and works with existing compilers.

 adding instructions will cause market fragmentation if anyone is tempted to ever use them. A product that doesn't ship because the people behind it gets delusions of grandeur is no use to anybody.

How is Matt Hey going to prevent MikeJ from shipping the Replay?

I don't think you understand the concept of Reconfigurable Gate Arrays.

Chasing rainbows is all well and good,

I keep trying to ignore your repeated insults of Matt Hey and anyone else who wants to make a faster Amiga but ....  Could you just please stop with the insults?

[freqmax]

Instruction fragmentation may occur regardless how it's implemented. Be it ARM-emulation, FPGA or ASIC.

[Mrs Beanbag]

Regardless of whether adding new instructions is a good idea or not, we should get one to work without new instructions FIRST, then think about what we can add to it later if it still seems a good idea.

[psxphill]

You seem to care a lot about preventing any new 680x0 CPUs being built.

You are mistaken, I would love to see a 68060+FPU+MMU emulation for an FPGA.
 

How is Matt Hey going to prevent MikeJ from shipping the Replay?

I never said it would. It's exactly MikeJ's approach that will mean that it will get shipped. Natami has lost a lot of steam because of their approach and hope of it being shipped goes down all the time.
 

I keep trying to ignore your repeated insults of Matt Hey and anyone else who wants to make a faster Amiga but .... Could you just please stop with the insults?

I think you misunderstand what an insult is. Disagreeing with someone is not an insult.

[Hattig]

First steps first :-)

First - a 68020 compatible implementation.
Then - a highly clocked 68020 compatible implementation with bigger caches
Thereafter - a higher performance (more instructions per clock) version of the above
Subsequently - an FPU and MMU
Eventually - a pipelined superscalar super-68k FPGA implementation that will fit into an FPGA of a future "Super FPGA Arcade" :-D

I think we're at the second of these currently with Yaqube's work. Each step takes time, especially the third and fifth above - the FPU and MMU might arrive earlier.

[freqmax]

I'll agree. Make it work FIRST. If it ships it's a bonus

The beauty with FPGA is that you can ship first, and code later

[Heiroglyph]

Instruction fragmentation may occur regardless how it's implemented. Be it ARM-emulation, FPGA or ASIC.

Not if you don't mess with the instruction set.

If they all look like 680x0's then it's just a different accelerator, like GVP vs. Macrosystems vs. Phase5.

We can get plenty of speed out of hardware made in the last few decades without resorting to specialized software.

[freqmax]

Adding instructions may cause fragmentation regardless of it's implementation. Reread my post

[Heiroglyph]

Adding instructions may cause fragmentation regardless of it's implementation. Reread my post

Sorry if I'm dense, are we agreeing?

I thought you implied that no matter what, fragmentation would happen.

My point was that it wouldn't fragment us unless someone added or removed 680x0 instructions.

I guess I am dense.  I can't take yes for an answer

[Plaz]

I think we're at the second of these currently with Yaqube's work.

So our best option so far for FPGA implementation then is to support Yaqube's efforts? Does he want or need help, are there resources he needs to help things along?

Plaz

[bloodline]

Sorry if I'm dense, are we agreeing?

I thought you implied that no matter what, fragmentation would happen.

My point was that it wouldn't fragment us unless someone added or removed 680x0 instructions.

I guess I am dense.  I can't take yes for an answer

Adding/removing instructions isn't going to fragment, added instructions can be ignored (see the 68020) and removed instructions can be trapped (see the 68060)... Fragmentation would occur if instruction behaviour is altered...

Reusing a previously assigned opcode cold cause problems, unless it wasn't commonly used on the Amiga... If it has potential to improve compiler code generation, or speed execution... then I say go for it!!

[freqmax]

Unexpected behaviour will fragment.

So our best option so far for FPGA implementation then is to support Yaqube's efforts? Does he want or need help, are there resources he needs to help things along?

The best situation is that he release the HDL-resources. Other than that one could start with TG68 and work from there.

[Heiroglyph]

Adding/removing instructions isn't going to fragment, added instructions can be ignored (see the 68020) and removed instructions can be trapped (see the 68060)... Fragmentation would occur if instruction behaviour is altered...

Reusing a previously assigned opcode cold cause problems, unless it wasn't commonly used on the Amiga... If it has potential to improve compiler code generation, or speed execution... then I say go for it!!

I disagree.  If instructions are added, then software will be written that uses them (you'll need a new compiler as well) and every other CPU will not run the software properly.

It's like the Microsoft embrace and extend tactic.  Be compatible, then add just a little change that people want to use.  Pretty soon others are obsolete and incompatible.

Higher speeds are great, but we can't afford more fragmentation.  It's just not worth a few clocks in specific situations when we can use more efficient hardware/firmware.  We're in the age of multi-GHz parts, we can get massive performance increases without resorting to a new instruction set.

If instructions are removed, but you include efficient traps with your hardware, that's fine but awkward for the user.  I absolutely hate dealing with 060 libraries.

[Mrs Beanbag]

If people use the added instructions, the code won't work on other accelerators. So everyone has to have the new accelerator to run the new code, which would be sad.

And what if two different developers add two different sets of ISA extensions? Then there is real trouble.

I don't personally think there is much call for new instructions. Maybe common combinations of existing instructions can be optimised specially.

[Plaz]

The best situation is that he release the HDL-resources. Other than that one could start with TG68 and work from there.

TG68 source looks like a good starting point, but if Yaqube is well on the way to creating the core needed, then wouldn't it be preferred to support that goal instead of duplicating the effort? Is his project so different in FPGArcade that it wouldn't work well here? I've not followed FPGArcade very closely, will the work be open or closed source?

Plaz