in case you are interested to test new fpga accelerators for a600/a500

[psxphill]

Some 68020 ISA instructions which are illegal on the Amiga but necessary in MacOS like CAS and CAS2 are not implemented and even the encoding may be partially gone (reused).

It's pretty pointless trying to consider any other platforms as it's obvious that the focus is on a solution that relies on AmigaOS with new software that makes use of any potential new mmu.

If you want to be able to run anything interesting like Next Step then you need to change mind set and create something that is compatible with the real chips rather than trying to make small percentage increases by discarding compatibility.

There are platforms that use illegal instructions etc. If the code was open source with multiple build options then it would be workable, but as a closed source solution it's like being taken on a mystery tour that the destination isn't quite where anybody but the driver wants to go. The people on the bus were sold at the beginning of the journey but then make excuses that hindsight is a wonderful thing.

[psxphill]

In a sense, you cannot have everything. P96 support requires 68020 support. Some games break on a 68020. Fast execution requires higher clock rates. Some games break on faster processors. At some point, you probably just have to say, ok, I'll boot this game with the plain old 68000 in the system.

An FPGA allows you to load a 68000, 68010, 68020, 68030, 68040 or 68060 core depending on what you need at the time. AGA Amigas don't have a 68000 to fall back to, some Amigas don't have any CPU to fall back to.

At some point somebody that doesn't want to redefine the ISA will come along and do it right and we can all buy that one with confidence.

[psxphill]

This means all cards for all AMIGA systems e.g. A600/A500/A1200/... will support the same instruction set and the same features and have the same capabilities.

 So you've managed to get everyone to agree to buy into your ISA extensions? How depressing. It is truly a sad day.
 
 Hopefully you will open source it so we can remove them.

[psxphill]

With old ISA the FPU is only as fast as 68060 @ 66 Mhz.
With NEW-enhanced-ISA the FPU can offer 68060@400 Mhz speed.

 It seems like a bait and switch. Yeah you can have 400mhz 68060 speed, except you need to port your code to it and the new code won't run on a real 68060.
 
If you can only make it faster by changing the instruction encoding and therefore having to rewrite all the apps, then putting an x86 or arm in there would make more sense as they could then run at ghz speeds.

[psxphill]

So in reality we now have endless discussions about a small minority of programs who might be incompatible because using special commands. You can say it is a waste of resources to implement them (in your view) but it is Gunnar wasting his time and as long as it not harms compatiblity to existing code and compilers it is not a problem to me. Or do I understand something wrong? Can you explain me what are your problems with it and where it hurts?

I think you've summed up the problem quite well except I'm not bothered about gunnar wasting his own resources.

The hurt comes from another fpga project that is taken over by someone pushing their own agenda.

Once someone makes an fpga board that can be configured to run 100% compatible to original Motorola chips then people can buy them with confidence that it won't turn into a mess further down the road. I'm not against optimisations, as long as they don't impact compatibility (which means you can't add registers or instructions to the cpu core).

[psxphill]

As i said it is only for a minority of software. This project is the only realistic option to get 68k development again. Good luck with finding a FPGA development team. Are you able to do it? Then do it. If not stop moaning.

That is exactly the reason to moan. Because unless you speak up then he'll go ahead with his plan rather than creating a fractured development for a minority of software.

It's similar to the land grab that Russia did on Ukraine.
 
 He knows that nobody can compete and so he can force whatever he wants, like Putin.

[psxphill]

We are here talking about "bread and butter" instructions that can be easily replaced by instruction sequences of the 68K core, thus there is no advantage.

Yes, I'd have thought the fpga space would have been better used analysing existing instruction sequences at run time and folding them down to faster operations than forcing the apps to be rewritten to make them faster. Essentially what Intel do.

Sure if that has been done and we have an absolutely optimal and 100% compatible FPU and MMU then experiments could be done on moving forward with a new optional next generation ISA. But my guess is that not all options have been exhausted yet. The thrill of being able to say he's added more instructions seems to be too great, but it's actually a failure.
 
 

* sigh * Anything new, anything that takes it a little far away from the 1980's must be destroyed or use the logic then use x86 instead. Sometimes I wonder why not?

A x86 or Arm on an accelerator with an open source boot rom that can emulate any type of 68000 and PPC would avoid the problem. Essentially a hardware version of Amithlon, but using real Amiga hardware instead of VGA etc
 
 I won't be buying any hardware that isn't 100% open source. Reverse engineering an fpga in 20 years time won't be fun.

[psxphill]

Personally, if you are going to mess around with the architecture sufficiently to force a compiler modification, you might as well recompile to something else entirely. ARM or MIPs spring to mind.

I agree. The only reason for adding extra instructions is so you can put something on your CV and to have something to talk about over a beer.

In the case of the FPU, the only way it's faster is to make it less accurate. If accuracy is not important then it's possible to make all FPU operations take no time at all, just make them all return 0. It would be just as useful for running all your old FPU apps.

I don't have any doubts over technical prowess but in terms of direction he needs to know that diverging from the original specifications is not what anyone really wants. You can probably find some people that say they are happy with it, but they are probably making assumptions over what they will receive that nobody is even attempting to achieve.

100% 68060 compatible CPU+FPU+MMU is the only "compromise" that I'm happy with, Motorola took things out and people have spent decades making sure the software runs. We shouldn't have to start that process again just yet.
 
 Even if you attempt to make something 100% compatible you will fail, if you start out aiming lower than 100% then when you fail it gets real ugly.

[psxphill]

All my games have use for additional instructions.

I am assuming you haven't written self aware games that rewrite themselves and you mean that YOU have use for additional instructions(*) in further updates.

Assume you're dead and nobody is going to bother updating your games, do you still think they have use for additional instructions(*)?

(*) additional instructions refers to ones that gunnar is going to add that will hurt compatibility, not ones that Motorola already added and we've dealt with those compatibility issues already.

[psxphill]

Adding new instructions will not hurt compatibility of existing software.

Any opcode that would cause an exception on a real 680x0 cpu can be used by software as a virtual opcode. LINEA & LINEF were officially available for that, but it's certainly possible that a piece of software could rely on any exception. The MMU & FPU that is proposed is certainly incompatible.

I don't believe compatibility with existing software is high up on his priority list. If there is any choice of performance vs compatibility, then I expect old software to stop working to allow the handful of new apps to run quicker. I don't expect that he's running every single piece of software ever written to check that his changes aren't causing any problems either.

[psxphill]

A-line is documented as user reserved. IMO, gated or switched on A-line instructions would be under user control so acceptable.

 
 Reserved for the user, meaning the application and not the CPU.
 

Where did you get your information for F-line? Some operating systems did use F-line for traps but I have not seen documentation designating F-line as user reserved. Motorola's own MMU and FPU were incompatible with some software.
 

 
 Documentation is irrelevant, only how the chips behave is relevant if you want to be compatible. Past incompatibilities can't be helped, only future ones. I'd pick whatever the 68060 + FPU + MMU does as anything that needs to run fast will have been written for it & a lot of the work to make sure everything else can run on 68060 has been pretty much done.

[psxphill]

Actually, given the small number of programs that really depend on the hardware interface, it is less a problem to create a new interface here.

As long as you don't care about running old software, but as soon as you open up that for debate then why worry about any old software. Just stick a fast x86 in there and run an emulator.

[psxphill]

Compatibility is very important given the current state of the 68k Amiga but we need to increase performance and plan for the future also.

 The only reason to rush through suggestions for new instructions is to stamp your name on it for kudos. I'd rather buy something that can run all software at 68060 66mhz speeds than something that may run at 0mhz or 300mhz depending on the software (if it isn't compatible then it's 0mhz).
 
 We can go out and buy 030 cards relatively cheap, it's the top end 060 cards that are in demand and that is where the biggest market is.
 
 But compatibility doesn't appear to be very important to this project.

[psxphill]

Sorry, I don't get your argument. There are already two incompatible(!) MMU models, the 68030/68851 and the 68040/68060. Even within the same family, subtile differences exist, so a single program cannot depend on a single set of instructions already. Note again that the instructions and the programming logic is already different from MMU to MMU.

The argument is, don't create another incompatible MMU model and let us run all of the 68060 software that exists already. Anything worth running already works on a 68060.

Essentially I want to be able to run all 68060 software at the fastest speed possible (but no faster that it causes incompatibilities). Like I want my car to go as fast as possible but I'm not going to take out the seat belts, brakes, roll cage etc to save weight.

If after it's possible to run all 68060 software there is a future mode that can be enabled that is faster but only works with new age software then I don't have a problem with that (I probably won't use it but I won't care).

[psxphill]

May I ask which software you currently use that goes down to the MMU directly?

I don't have a 68060 currently, assume that when I do then I want to be able to run all software that runs on a 68060 and don't want to have to run new versions. I hoped that this would meet my needs, but it appears it won't.

I want the confidence that if I submit a bug report that it won't get closed as a won't fix because the software isn't popular enough & right now I don't have that confidence because the stated goal isn't to run all software.