FPGA Replay Board

[freqmax]

Their only concern was compatibility and how it was perceived.  When I showed them the A4000 running circles around their Mac Quadras their concerns were centered around the fact the Amiga was a better architecture.  

Perception, perception and looks. Guess that summarize Apple

Next core: Macintosh Quadra 630 (68040 at 40 MHz)

[matthey]

Coldfire is supposedly faster or could be clocked faster because some overhead was removed so that a more "raw" core remained. Corporate decisions are not known throughout the history for their wisdom

Let me translate. Your "raw" really means "cheap". They made a cost and logic reduced version of the 68k for cheap microcontrollers and embedded systems. They gutted a lot of the power and ease of use of the 68k although they added a few nice instructions back. Some of the 68k simplifications they did are smart though. Dropping (trapping suffices) at least the outer displacement of double memory indirect modes makes sense for the decoder. Reducing instruction sizes is also a good idea although it can be done without hurting power, ease of use and code density. With just a little more logic (instead of a little less in the case of the ColdFire), instruction sizes can shrink while improving power and code density instead.

I can see why some things might be removed, but they'd kept their ISA pretty compatible for years and then just started reusing opcodes. Using previously unused opcodes for new instructions and causing removed opcodes to trigger an exception would have been more logical.

I don't agree. The ColdFire was incompatible from the beginning. The later changes to the ISA used unused 68k encoding space as I recall. I think Freescale tried to improve 68k compatibility with the ColdFire but they ruined it from the beginning by not making it compatible enough. They ran off most of the 68k supporters with incompatibility and poor performance. The early ColdFire processors were lack luster to say the least.

When I showed them the A4000 running circles around their Mac Quadras their concerns were centered around the fact the Amiga was a better architecture.    But, at no time did they ever attempt to stop what I was doing.

I guess you worried them enough that they dropped the MacOS+68k and headed to greener pastures with OSX+PPC . Apple did change their minds about Mac clones so maybe that is when they decided to sabotage the ROM to not work on the 68060 .

[freqmax]

Is there any MacOS-68k clone like AROS for AmigaOS ?

[psxphill]

I guess you worried them enough that they dropped the MacOS+68k and headed to greener pastures with OSX+PPC . Apple did change their minds about Mac clones so maybe that is when they decided to sabotage the ROM to not work on the 68060 .

Apple committed to PowerPC in 1991. They had already started shipping PowerPC machines by the time the Quadra 630 came out, they didn't just wake up one day and decide to switch.
 
Because Apple never shipped a 68060 based Apple and nobody produced an accelerator, it would be tricky for them to make sure it was compatible when making changes. Even if they suspected it wasn't compatible, then there would be no business case for making a best guess at trying to make it compatible. The programmers would never know if they were successful.
 
Mac clones were stopped when Steve Jobs came back. They did by releasing OS 8 as they'd only licensed OS 7 to the clone manufacturers. They did have to stop the clones as Apple's business model is based around overcharging for hardware, if others are cloning it and selling it cheaper then Apple would run out of money quick.

[matthey]

Is there any MacOS-68k clone like AROS for AmigaOS ?

Not that I'm aware of, but you used to be able to download and use some of the old versions of the 68k MacOS for free from the Apple web site. They included 7.5.5 and 7.6.1 which are probably the two best versions for speed and stability.

Apple committed to PowerPC in 1991. They had already started shipping PowerPC machines by the time the Quadra 630 came out, they didn't just wake up one day and decide to switch.

It was clear they were going to support the PPC but not clear that they would drop support for the 68k.

Because Apple never shipped a 68060 based Apple and nobody produced an accelerator, it would be tricky for them to make sure it was compatible when making changes. Even if they suspected it wasn't compatible, then there would be no business case for making a best guess at trying to make it compatible. The programmers would never know if they were successful.

MacOS 7 was compatible with the 68060 with few or no changes. MacOS 8 needed lots of fixes as I recall. It would have made good business sense if Apple had made a 68060 based laptop and used a 68k low end computer line while using PPC for the high end. Memory was still very expensive and the 68060 is a memory miser and watt miser, unlike the 68040 or PPC.

[psxphill]

I don't agree. The ColdFire was incompatible from the beginning. The later changes to the ISA used unused 68k encoding space as I recall.

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.
 
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.
 
It's annoying they didn't make it compatible, although whether it would have made them more money is another matter. So as a business decision it probably paid off, but they'll never know how many coldfires they could have sold to us now.

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

[wawrzon]

ive never fully understood, why trapping substituted instructions have been impossible, but since everybody broke their teeth on it i guess its not worth to explain to noobs.

[psxphill]

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.

I'm not sure why anyone would do that.
 
Intel made the same change when pushing the stack pointer on the stack somewhere between the 8086 & 80386.

[Heiroglyph]

ive never fully understood, why trapping substituted instructions have been impossible, but since everybody broke their teeth on it i guess its not worth to explain to noobs.

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.

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.

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

[ElPolloDiabl]

Coldfire is another dead end. If someone ever gets the money, do a run of 75mhz 68060. You should be able to get close to 10,000 people wanting one.
I like the discussion over at 060 replacement. Sooner or later more of the Amiga hardware will start dying. Without a modern replacement, hardware collectors will become brick collectors.

[freqmax]

Perhaps the prices for an ASIC spin has sunken?

[psxphill]

That's why programs like Oxypatcher and Cyberpatcher replace instructions before they are trapped.

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.

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

[mikej]

Some good news. All the components are in place now and I'm paying the bill.
The last parts should join the PCBs within two weeks, and I am hoping they can get them built before the China spring festival holiday. I should get boards by end Feb.

This is a big step forward as I can now remotely order and build as many as I want. This will also mean the daughterboard can go directly into volume production.
/MikeJ