Wicher 500i - classic turbo card for A500

[psxphill]

The most annoying thing about a 50MHz 68000 is all the software that require 020+.

Something like cyberpatcher/oxypatcher that trapped and patched code to run on 68000 would be great.

Back in the day I had a supra turbo 28mhz and wrote a couple of patches. One was for unaligned reads that a jpeg datatype used, but otherwise it ran fine on the 68000. It happened infrequently, so using the exception was good enough.

[psxphill]

First, while the 68060 had a separate exception for "instructions it should have implemented, but did not", the 68000 does not. Any advanced instruction just triggers the "invalid isntruction" exception, regardless of whether this instruction is valid on some member of the 68k family or not. Unfortunately, the same exception is used for debugging, and "true" invalid instructions.

As long as the handler looks for the emulated instructions first, then I don't see this as a big deal.

Second, the result would be very slow. Remember, there is no support for extended instructions in the 68K, so it would have to decode these instructions manually, execute them manually, and write the results back manually. While the 68060 has enough horsepower to do that, the 68K does not.

If the instructions were patched on the first use to jump into generated code then the overhead wouldn't be that great & it would run way faster than not being able to run it at all.

Third, tools like MuRedox depend on the fact that the unimplemented instructions are all at least four bytes in size, so it can replace them by a 16-bit JSR instruction. That is not always the case here.

Just move the following instruction as well in that case, using offsets that will trap if jumped to directly. I'll grant you that it's way more complex at that point.

[psxphill]

Too much patching going on already, OS3.x needs a serious cleanup.
Software should very well be able to ask the OS what CPU they are running on, and use optimised functions accordingly.

It can already, it's too much of a pain. What you want is a compiler which can generate mixed binaries and have the OS load the correct code for each.

That doesn't help with software written in the last 30 years though.

[psxphill]

"Nice software" with different versions for FPU type / processor type were seen as using less memory and system resources back then.

Yeah, having a single binary with:

if (68000)
{
}
else if (68020)
{
}

All over the place would be horribly inefficient for memory and cpu usage.

The ideal would be a compiler that can target multiple cpus in one pass and output different hunks that only get loaded if that cpu was available.

So a binary built for 020/030/040/060, may have some routines that have the same code built for the 020 & 030, and separate code built for the 040 & 060. And others might have code shared for the 020/030/040 and separate for the 060. When loading it would make sure that the correct code was loaded and linked & in this case the binary would fail to load on a 68000 and 010.

Actually, the Os is. There is only one dependency I recall where one particular Os function (somewhere in graphics, if I recall) requires a 68020 or up, and this is a conditional assembly which is only used for Kickstarts for machines that came with a 68020 or up. So it's really not that bad. It just means that you cannot plug in a 68K into a machine that was designed to run with a 68020 or up.

Or Kickstart from an 020+ machine in an A500. I'd be interested in where it was. When the A1200 came out, I saved a copy of kickstart from a friends computer and loaded it into the phase 5 68000 14mhz kickstart ram. I probably didn't use it that much, but I don't remember having any problems with the CPU. There were some issues running with ECS, but I think a later SetPatch sorted those.