Motorola 68060 FPGA replacement module (idea)

[ChaosLord]

I am curious why there is some idea of a shortage of 68060 chips?  There are tens of thousands of these chips, both 50MHz and 60MHz (MC and XC versions) available from suppliers in China.  These were used in the Northern Telecom call center boards.  There is a thread here about this.  Just pull the chip with the heat sink and put it in your Amiga (or replay) board.

eBay has a slew of these boards, for about 1/2 of what 68060's by themselves are selling for.

Every once in a while someone starts a thread asking why AmigaKit keeps selling brand new 030 and 020 accelerators when what so many ppl want is an 060 accelerator.  The answer that ppl post in forums is that there are no 060 chips available or that they cost ridiculous amounts of money so therefore no 060 accelerators can be built at a profit.  Or they say that since the cheap 060 chips are "from China" they can't be trusted.  Even though everyone who ever bought any of them was pleased with the results.

There is no shortage of 060s.  But there is a shortage of 060 accelerator cards.

[ChaosLord]

I would just like to clarify that MacOS has problems with the 060 because MacOS is crap.  MacOS is so bad that its creator threw it in the garbage and switched to a totally completely different OS.

On the Amiga, the 68060 is totally compatible with all normal software and causes no problems.

In order to make a program be incompatible to the 060 on the Amiga, one would have try really hard to do it on purpose, or do something that is plain illegal, or be banging the MMU or performing some weird esoteric function that no normal programmer would ever have any need to do.

On the Amiga we have MMU.library so nobody needs to bang the MMU.

I have been writing Amiga software since 1985 and none of my C or asm programs has ever failed on the 060.

Microsoft BASIC fails on the 060 because Microsoft BASIC is a pile of garbage that does wildly illegal things.  M$ BASIC won't even work on 020.

[ChaosLord]

Well, there are quite a few Amiga programs - including several of my own that all follow 100% legal programming practices (according to common sense and the RKMs) that will not run on an 060 with superscalar and/or branch caching enabled.  

Are these programs all emulators?

Emulators have to do weird exotic things and/or deal with weird exotic things in order to get good performance.  These weird exotic things are things that a regular programmer never deals with.

I don't recall all of the reasons behind the issues.

I am not entirely clear if your complaints about the 060 are not simply that all the first 060s had bugs in them.  Later on those bugs were ironed out.  Iirc at least one of the bugs only happened when was superscalar mode was active so it could be avoided by turning it off.

I am thinking that if you tried a later revision 060 you might like it.

  I should go look at the mmu.library replacement that we made for EMPLANT and FUSION... I know I commented some things there.

I remembered u coded Emplant but I didn't know about Fusion.  I never actually used either one.  The only mac emu I ever used was A-Max (I think that is what it was called) way back in prehistoric times.

  I know that self modifying code is definitely one of the things that causes a problem when one of the cached instructions in the pipeline has been modified (like a branch table).  Yes, I consider self-modifying code 100% legal.    You are suppose to flush the caches (or turn them off) with self modifying code, but when you do that you are then running at sub-030 speeds.

If u only modify your code once, flush the cache and go on then its not such a big deal... but if you have to do it in a loop then speed dies.

Does your Emu scan opcodes and runtime replace all those ILLEGAL instructions that MacOS used for Quickdraw etc. ?

The 060 really only adds dual instruction pipelining and a 4-way cache.  A higher speed (100MHz+) 040 core would probably be better in the long run, especially if it handled floating point without completely stalling the core like the 060 does.

040 core is slow at math.  060 is fast at math.  040 has no branch prediction too.

[ChaosLord]

Chipram = a good solid 14.? MB/sec unless I am misremembering something.

[ChaosLord]

Some instructions are used less often but reduce branching (my favorite)

Yes!  I love those!  I (and Phil) were always pushing these at the Natami CPU Dezine Dept. but Gunnar did not like them or didn't understand so he was totally against adding a new instruction for this purpose.

[ChaosLord]

The micro and nano microcode instructions roms are being read out.

If they did this for 68060 it would be very interesting!

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

[ChaosLord]

The only 68020 features I ever used are longword multiplies and divides, and scale factors on indexed addressing modes.

And Branches >128 bytes :angel:

[ChaosLord]

I think you mean Bcc.L and BSR.L. Branches up to 16 bit were supported on the 68000. The longword branches are big savers but only on fairly large programs. Not too many assembler programmers create programs >65k.

It's signed so plus or minus ~32k.

I need to make some kind of rule not to write msgs after my beddy bye time

Either that or this is what happens when u don't write any asm code for 4 years... ur brainz turn 2 mush.

The thing is I used to spend many many many hours trying to optimize my code to replace all bcc.w with bcc.b so you would think I would remember that.  For some years (back in early 1990s) I was like Phil, all hardcore 030, 256 bytes of L1 instruction cache optimizing and I would code separate routines for 000.

[ChaosLord]

By looking at code compiled for the 68060, it looks like many compiler programmers didn't understand either. Most 68060 optimized code doesn't do much except replace some trapped instructions, if that.

Which compilers even have an 060 option?

I can't remember SASC even having such an option.   Or maybe it does and I just don't use it...

[ChaosLord]

How common are the bitfield instructions in real code? I never use them.

Every time I ever wanted to use Bitfield instructions I would consult the timing charts and it was always faster to just do things the RISCy way and not use bitfield instructions.  So I have never used them.  I just use good ol' ANDing and ORing.

Phil published some results of bitfield usage years ago on Natami.net.  It turns out that bitfield instructions are used a surprisingly large amount in certain softwares.  Dungeon Master was one.  And various other games that were ported from other systems.

[ChaosLord]

I think the thing with TST being the #1 instruction in SEGA games is either:

A: All those games were compiled with either SASC or GCC which generates silly wasted TST instructions all the time.

B: The Sega Genesis uses PIO (Polled IO) for some things so it has to constantly TST a certain memory location all the time in a loop.

C: All of the above.

[ChaosLord]

I agree... with the MacOS, TST is not even in the top 10 instructions used.

Awesome.  Thanx for the confirmation.

[ChaosLord]

How many LUTs does it take to make a slice?


Trying to figure out which is smaller.

[ChaosLord]

Okey so ur 16-bit 68000 core is about triple the size of that PB8051 Microcontroller thingy that MikeJ is using.

But ur core has triple the style points of a PB8051.