FPGA Replay Board

[matthey]

I know coldfire was incompatible from the beginning, but for years Motorola had done their best to keep the 68000 ISA compatible across all their processors. Even the MOVE SR change can be emulated using a trap.

They did a good job although there was at least one incompatibility for properly written code when going from 68000 to 68020. I believe it was the way the auto increment works on the MOVEM instruction. Something like MOVEM.L SP,(SP)+ will behave differently on 68020 than 68000.

There is some dead encoding space that would benefit from reusing the encoding space which is limited without using A-line or F-line (reserved for trapping and coprocessors).

Lots of things were removed from coldfire, but if they'd just made those trap then apart from a speed drop there wouldn't be a problem. Some instructions on coldfire did something similar to 68000, so they used the same opcode. They should have trapped the original opcode and implemented it as a new instruction, made the implementation the same or implemented a mode where those instructions can be trapped or not.

Trapping non-longword aligned stack accesses would have gone a long way to help 68k compatibility. Most 68k instructions that were dropped can be trapped.

[matthey]

They also removed some that we use a lot.  On these it will trigger an exception that you can trap.  Trapping the missing ones is too slow, making the CPU upgrade become a downgrade.

That's a good point. Even if 100% 68k compatibility through trapping was possible on the ColdFire, it would be very slow. That's why programs like Oxypatcher and Cyberpatcher replace instructions before they are trapped. The net effect is that emulation would probably be similar speed with the number of trapped 68k instructions on the ColdFire. Emulation speed would be helped a lot by having similar instructions but then much faster CPUs than ColdFire are available for emulation. The only reasonable use I see for a ColdFire Amiga solution would be a CFv4+fpga using the CF SoC I/O capabilities which are low end but cheap. The CF CPU could be used for basic service operations much as the fpgaArcade uses the ARM CPU.

There are instructions that look like a certain 68k instruction that actually do something different on the Coldfire.  There's no way to tell when you hit one of these instructions because it is a valid Coldfire instruction, so your program just does the wrong thing with no way to fix it.

There really aren't very many conflicting encodings. DIVSL/DIVUL<->REMS/REMU is the only integer one I know of in user mode. The ColdFire instruction only returns 1 of 2 registers that the 68k does. I have studied this extensively as I even wrote a new 68k compatible ISA that adds many ColdFire instructions. MVS, MVZ, BYTEREV, BITREV, FF1, SATS have no 68k ColdFire conflicts. MOV3Q and the MAC instructions use A-line which doesn't conflict but the 68k doesn't use. CF TPF is 68k TRAPF.

[matthey]

Perhaps the prices for an ASIC spin has sunken?

The community could partner with a company that makes embedded processors like the makers of the 68k Fido which probably started as an fpga CPU and was turned into an ASIC. We would still need to develop and fully debug a 68k fpga CPU before we turned it into an ASIC. A CPU designed to be efficient in an ASIC is a little slower in fpga but easier to create and maintain. A community Kickstarter project could help fund the ASIC creation by the business. By the way, the AmigaOS would need substantial changes to run on the FIDO which is more compatible than the ColdFire and very "responsive" but only 66MHz.

I'm pretty sure they replace the instructions after they are trapped the first time, not before. Hitting one trapped instruction is not a big deal, it's when you hit one every time through a loop.

That's how they work which is more prone to problems than trapping while still not full speed. The missing instructions on the 68060 are, by default, trapped every time using the 68060.library.

[matthey]

I can tell you in secret that I'm working on a new board which integrates an FPGA and 060 CPU together with other goodies. It won't be a direct replacement of any existing Amiga mainboard.

Will it have Ethernet (100Base-T) ..?

How about full speed PCI with 4-5 slots? PCI ethernet, USB, GFX and sound cards are available for almost free. Maybe a little more memory? Price? Spill the beans! Your secret is as safe hear as any public forum .

[matthey]

So why not just have a faster 68020 CPU in FPGA rather than adding a real 68060 daughtercard?

The 68020-68060 user mode integer instruction and addressing modes are practically the same. The 68060 and 68040 have MOVE16 but I'm not aware of any compiler that ever used it. The main difference between supporting 68060 and 68020 code involves supervisor mode, the FPU and MMU. The TG68 does not have this support and it would be difficult and time consuming to add. The reason for a real 68060 is:

1) speed
A highly efficient fpga CPU will have a hard time reaching 68060@50MHz performance (not clock speed) in an affordable fpga.

2) compatibility and stability
There is nothing like the real thing for compatibility. The rev 6 68060 is practically bug free.

3) FPU, MMU
There is no fpga 68k CPU that supports an FPU or MMU yet.

[matthey]

There were a couple for the Amiga that did when you turned on the 040 optimizer, and all of us assembly guys used MOVE16 whenever the 040/060 was present.  Also, the Mac OS used it extensively on their 040 based models.

I have looked at a lot of disassembled Amiga 68k code. I have not seen any version of GCC, SAS/C or vbbc generate a MOVE16 instruction. I have not looked at MAC code so perhaps CodeWarrior generated MOVE16. MOVE16 is generally not used in general purpose code because of the alignment restrictions and the fact that the cache is bypassed.

I still think emulating the supervisor/user modes and some other simple added instructions would go a long ways with the FPGA core to make it 020 compatible.  This is something I am interested in looking at when I get ahold of one of these boards.

I haven't seen a list of the instructions supported by the TG68 but I thought it was fairly complete as far as 68020 integer instructions. It has MOVEP and the bitfield instructions which are common on the Amiga. A 68k Macintosh emulator probably needs more support though .

MOVE16 was at least used in some of the CopyMem patches: http://aminet.net/package/util/boot/CopyMem
 

Sure, there are a few patches on the Amiga but MOVE16 is only worthwhile when copying data greater than several kilobytes and the Amiga doesn't copy data that big very often. MOVE16 is barely worth using on a 68k Amiga and I'm the author of CopyMem mentioned above. Linux would be a different story as it copies large amounts of memory and flushing the caches when doing so would likely deteriorate performance.

[matthey]

Some software uses it and the replay board isn't just an Amiga, it would make sense to reuse the same cpu core for running MacOS or any other operating system.

True. MOVE16 shouldn't be very difficult to support and it may be possible to provide a speedup when using it. Difficult would be CAS and CAS2 which the Macintosh also uses.

I'm not sure I'd argue that it's not worthwhile if I'd actually released something that used it.

I'm not afraid of the truth whatever it is . There probably are Amiga programs that benefit from using MOVE16 for larger memory copies but they would be rare. Also, future programs could potentially benefit.

Hehe that is how I always felt about it.  I was a really hardcore asm coder and yet I never used Move16.  I coded a bunch of special purpose copy routines for high speed screen updates.  I thought about making a special version for use on CPUs that have the Move16 instruction but I was like, meh...   So all my gfx copying routines just use move.l.  I really should force myself to write a move16 version.  Someone told me once that it conflicted with certain hardware.  Any truth to that?

There was a MOVE16 bug in some early 68040s. Recovery after a crash while using MOVE16 may not be possible as ThoR mentions in the Mu 68060.library docs. I haven't heard of anyone having a problem using MOVE16 though.