Apollo Team announces the Vampire V4

[Louis Dias]

Only Amiga OS has lacked a 'software' FPU.  These were all part of Apple and even Atari IIRC.  Motorola has libraries written to handle FPU instructions when an FPU wasn't present.

Here's what happens:
CPU receives an FPU instruction.
If A FPU exists, the instruction is handled.
If not a exception is thrown.
If the exception handler contains a jump to a software routine to handle the instruction, then the instruction is handle by a library call.
If not: epic fail.

Amiga OS has been epic fail for a long time.
FEMU should have been part of Amiga OS in 1985.

[Louis Dias]

Motorola has FPU packages to emulate the instructions missing in the 040 & 060 FPU so that 68881/68882 software would still run. The 040 package was shipped with AmigaOS in the 68040.library and in MacOS. I've never heard of a full FPU emulator.

They are not emulators.  Just code to handle trapped cpu missing instruction exceptions.
I think the '060 is missing some INTEGER instructions that the 040 had and those again are handled by a library call...as some addressing modes.

http://www.nxp.com/products/microcontrollers-and-processors/more-processors/coldfire-plus-coldfire-32-bit-mcus/68k-processors-legacy/m680x0/superscalar-68k-microprocessorbr-including-the-lc060-and-ec060:MC68060

If you're wondering why compilers are being tweaked, read this:
http://www.nxp.com/docs/en/supporting-information/MC680X0OPTAPP.txt

The 68K family has lots of quirks and it's interesting that the Apollo manages them well.
But let's all whine about why feature X is not implemented yet instead...

[Louis Dias]

Quirks? Not really, it is a very orthogonal instruction set, compared to what intel produced.

The quirks I'm referring to are about the differences in the cpu's themselves (68000, 68010, 68020, 68030, 68040, 68060)...compilers "hide" those things...sometimes...

Another laughable point is the demand for an MMU.  Yet another quirky feature.
https://en.wikipedia.org/wiki/Motorola_68851
https://en.wikipedia.org/wiki/Motorola_68451
Which MMU do you implement in the Apollo?
Yet people will whine about the *custom* one they are developing... /facepalm.
Again, OS-level support is missing in 3.1 for an MMU.  How is that a must-have feature?
When the OS has been elevated to a modern standard, then it will be *must-have* but the Apollo's MMU will set that standard going forward, not looking backwards.

[Louis Dias]

That is an emulator, it pretends to do the same job as something else.

I don't consider patching in a jump-address to a subroutine/function an "emulation".

[Louis Dias]

Actually, the user space programming model is exactly identical *except* a single instruction, which is MOVE from SR which is priviledged in the 68010 and all above. Except that, user space is all the same.

The supervisor space programming model is, however, different, but that should be taken care of by the operating system. That is, however, not a quirk, but not much different from other CPU architectures.



That is not quite the problem. It is not "which MMU", but rather "are the provided MMU features sufficient to provide the same features Motorola offered". Again, the MMU as a supervisor feature changed from generation to generation. That is not a problem. The problem is that the Apollo approach is much less powerful and much less flexible than *any* of the existing Motorola MMUs. A "page size" of 256K is certainly not sufficient.

To give you some idea, the PPC MMU is a completely different design, yet it is sufficiently complex to do anything a 68K MMU can do. The same does not hold for Apollo.


No, and if you reduce it to this, you don't understand the problem.


No, it's not. It has been there since a long time, in various tools.


Because it allows many desirable functionalities for software development, as well as for end-user features.


Look, the "Os" cannot be "elevated" to a modern standard. That's simply because some of its core design decisions are inheritely broken, and in contradiction to what a "modern standard" would have to say.

I think our perspectives are different.  If you look at the link for building compilers to handle the various cpus I linked to earlier, you'd see much more differences.
"user space" is nice.  Things need to happen a couple of levels below that to keep it nice.

My comment about elevating the OS was of course about creating a new modern 68K version.  But that proves the point of why an MMU will never be a must-have feature of OS3.X...  Virtual memory becomes a moot point when you can run on a couple of megs and suddenly now your hardware suddenly come equipped with .5GB to 4GB on-board...

[Louis Dias]

I don't think Gunnar hates FPU's. He has stated that purchase a Vampire only if you feel it has the features you need today. Keep in mind UNLIKE other product ranges the features can be upgraded and improved via flashing the core of your choice.

V4 has enough space for an FPU. I wouldn't be a stretch to envision the work done on FEMU put into an FPGA.

The I supposed folks will  then complain the V4 doesn't have a floppy drive controller for floppy compatibility...and that's fine... SO Alright then... it has I/O ports, perhaps someone can fab a floppy port. I dunno beats the hell out of recapping Amigas every 15 years.

They will always find something to complain about.
In fact I want to go on record now complaining because the kitchen sink is missing!

[Louis Dias]

Hoe is your Wii AOS4 port going ?

Don't call me a hoe!