FPGA Replay Board

[matthey]

No it is not; demos bang the hardware quite bad.

Banging the hardware doesn't have to mean incompatible. Frank Wille's SqrxzOCS game port bangs the hardware but works on 68000-68060, OCS-AGA, AmigaOS 1.x-3.x, is hard drive installable and properly exits.

So, yes, we NEED proper settings, with cpu-selection and speed-setting to be able to watch the demos as intended

As a minimum:
7.14 MHz 68000
14.28 MHz 68020
50 MHz 68030
50 MHz 68060
66 MHz 68060 (some demos actually rely on this... )

Then again, this is to watch demos.. If all you want is to fire up the good old games, then "stock" settings would probably be enough.

So we need settings for every possible 68k processor at every possible speed of every possible accelerator with every speed of memory with OCS, ECS, or AGA on an Amiga 500, 600, 1000, 1200, 1500, 2000, 2500, 3000, 3000T, 4000, 4000T, CDTV or CD32 and cycle exact in both CPU and all custom chips so we can watch poorly programmed old demos. Mike might be busy for awhile. We could have new and better demos (as well as apps and games) on a faster and enhanced CPU and custom chips in a fraction of the time. Basic compatibility is good but supporting every poorly written program is ludicrous. We can patch what is important and make videos of troublesome demos.

[matthey]

xxx MHz enhanced 68020 FPGA mode - single cycle as much as possible, cache, ~100MHz
xxx MHz 68060 (>100MHz) or until it blows up.

Yee Haw! Now you're talking. Have you worked on or planned for a superscaler core? Will you put 64 bit integer instructions back in the 68060? Do you plan on adding any enhanced instructions or addressing modes? How about an FPU? Some demos use the FPU you know .

[matthey]

@Hattig
I agree that a stable and debugged 68020 compatible core is the priority but it's much easier to implement what has previously been planned for when programming. That is why I think a standard for 68k enhancements should be worked on now, which I have been doing. It's too late when everyone has conflicting and incompatible enhancements.

[matthey]

I actually think there should be no effort put into enhancing the 68k beyond what Motorola did. Potentially a CPU that does everything that an 020 to 060+68882 can do. But I wouldn't care if it's just an 060 that only supported the instructions an 060 did, it doesn't even need to be superscalar if the instruction rate was good enough.

Why? If you are satisfied with a slow retro experience then you can use the 68000 or 68020 cycle exact cores. Motorola did enhance the 68k beyond the 68060 (in some ways) with the ColdFire. Instructions like MVS/MVZ and BYTEREV would have been *very* beneficial on the 68060 and the support can easily be enabled in compilers. A 5-15% speed increase and a 5-15% code reduction should be possible for new code with a negligible difference in speed (parallel fpga use) or compatibility of old code. The only worry is that the core grows too big but a simpler standard could be met that would fit but still provides a nice benefit. If we developed this, it could attract the attention of developers (embedded use) and there is a possibility of a return to a hard chip/ASIC in the future. The 68k has an industry leading ease of use and code density even today. It can be even better and modernized to compete with other modern processors.

If you have any technical knowledge of x86, ARM, PPC, or 68k then you will appreciate some great ideas in this enhanced 68k ISA:

http://www.heywheel.com/matthey/Amiga/68kF_PRM.pdf

[matthey]

Indeed, m68k is far from dead in embedded. The gnu toolchain and linux kernel gets lots of updates from companies that do commercial embedded solutions using m68k, there are several commercial FPGA implementations of m68k etc. Extending m68k beyond 060 is just great. What is the legal status of the m68k architecture compared to ARM and MIPS?

This is the classic answer by the Natami creator:

In the Amiga world people get sued out of fun. But in the real world to which Freescale belongs people get sued only for money.
 
 It is only a nice story when Gunnar tells that we had a conversation with the ColdFire/M68k Division Manager of freescale. That we asked him if a custom made MC68060 with higher speed than the classic ones could be available. When he declined we got on asking if we could at least get/license some source HDL code to use in an FPGA. He told us that the MC68060 is built in some kind of HDL source. He regrets but it is absolutely not possible to get/see/license this code for anybody in any form. The only thing he could do is to provide us contacts to companies who sell 68k IP cores. Freescale itself doesn't do this, it is not their business. Then Gunnar asked him what might happen if we wrote our own IP. He said that Freescale will not have a problem with that and that, in his opinion, we do not need any permission from Freescale even if we are about to sell it. But we can not expect any technical help or support from Freescale when we decide to do so.
 
 This is just a story which happened some time ago. We do not need prove or evidence of that. This only (sadly) shows that this is the end of the road for the 68k. The business of this division of Freescale is to sell competitive embedded ColdFire chips, not software. These chips *must* not compete with faster PowerPC which is a different division at Freescale. As said, in the real world they would only sue us for money, not for fun. It would be money if we decide to sell 68k compatible chips running at 600MHz at a price of 1,5$ per piece. Then the discussion here might be justified. But it is not because we won't because we can't.
 
 I just wonder why AMD is still selling x86 compatible CPUs. Ah, right, I forgot. They use a completely different opcode than intel.
 
 Meaning that it might be worth continuing this discussion. Since we AND Freescale are not really involved because both do not have a problem with this topic I would emphasize to discuss whether an opcode is copyrightable or patentable in talk, not as an NatAmi question. For now Freescale does not have any interest in high-speed 68k. The moment this changes we are the first to get a 2GHz 68k dual core and just drop the softcore '50 (sorry Gunnar/Jens) and get the chip mounted onto a SyncZorro card. But immediately.

[matthey]

dozer, darthx, why go through all the effort and make an a1200 clone if it ain't compatible enough to run all sw designed for the a1200?
patching/capping stuff sounds like a very lame approach. not an option if you ask me.
then i would be better off with uae.

The fpgaArcade will *attempt* to run all software for a *stock* Amiga 1200 using the cycle exact 68020 CPU core. Asking for full compatibility of a modified Amiga is like heavily modifying a sport car with a souped up engine, turbocharger, NOS, all the bolt-ons, custom body panels and paint job, racing seats, racing gauges, a lowered suspension, and low profile tires and wheels and then going back to the dealer and asking for support when you have a problem. Some of us here are asking for a whole new sports car built to a high spec with an enhanced engine (CPU) and body (custom chips). We know it wouldn't be the same as the old model, but the drive ability and controls would be similar but better .

[matthey]

What Amiga 1200 software will only run properly using a cycle exact 14mhz 68EC020?

Probably not much. The 14MHz speed would slow some games down to a playable speed but I expect the following would matter more:

1) Caches the same as the 68020
2) VBR in original location
3) No fast memory

[matthey]

There are really games on the Amiga that run too quick if you have an EC020 faster than 14mhz? I thought everything was tied to the vertical blank, so the speed only changes depending on whether you're running in 50hz or 60hz.

Yes, there are Amiga games that run much too fast although most are old games for the 68000 and early AmigaOS. Sometimes timing problems are because of bugs like failing to call graphics.library WaitBlit correctly.

[matthey]

PCI does not help at all - it would have to be PCI express nowadays which is fairly complex to bridge. The idea is future daughter boards could add more advanced features.

Actually, I would prefer regular PCI . We have existing drivers, there are cheap PCI cards available for less than $10 and it's fast enough without a faster CPU. You get cheap gfx cards with 3D and more memory, SATA and SCSI cards, sound cards, etc. Can you really add features like USB, ethernet, SATA, memory as cheap as they can be added with a PCI bus? I bought a 100mbit ethernet card for $5 a couple of years ago. The only disadvantage is that it would take more space. I would like to have an expandable expansion board for a small tower and a small expansion board for a laptop. I understand the more advanced features later part though .

SD cards give you significant storage and emulate hard drives as fast as the original Amiga drives pretty much in transfer rate. You can hook USB devices from the daughter board.

My CSMK3 does 30MB/s sustained DMA HD transfers with very low CPU usage. My Voodoo 4 gfx card gives 3D, very fast 2D (compared to AGA) and extra main memory. The fpga Arcade will be slower and a step down in many ways from what I have. I will still buy one with the expansion board as it has some kool features but PCI opens up many interesting possibilities that you are neglecting to see.

[matthey]

1000 is still small numbers, Xilinx etc will not deal with you directly unless you are much bigger than that.

I bet you could do 10000+ with a Kickstarter at a slightly reduced price. The more cores the more interest outside of the Amiga community IMO. More console emulation like NES, SNES, Genesis, Neo Geo, x68000 etc. might be the biggest retro draw.

[matthey]

Plus you have to word things carefully.  And anyway he can't say anything about NES emu on kickstarter.  Its an instant lawsuit from Nintendo.  Even if the core exists and works perfectly he still can't say anything about it on kickstarter.  Do u want him to get assasinated? :crazy:

Amiga Inc and Atari have probably already sent cease and desist orders . Of course he would need to be careful about what he advertises and says publically.

[matthey]

@JimDrew
I'm a bit surprised no one ever sued you. I expect Apple was the most upset about an Amiga emulator with 68060 being faster than any Mac they sold for awhile. Did you feel like they deliberately added 68060 incompatibilities to MacOS 8.x roms to keep the 68060 from running? I have heard this rumor before and MacOS 7.x seems to be more compatible with the 68060.

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

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

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