Apollo Team announces the Vampire V4

[Niding]

Hairsplitting, Amigans favourite hobby since the 90s

[jj]

So the standalone will basically be an Amiga with non of the expansion slots.  What is the benefit of this hardware emulation over much cheaper faster software emulation ?
 
 Just trying to work out the point of the standalone

[psxphill]

So the standalone will basically be an Amiga with non of the expansion slots.  What is the benefit of this hardware emulation over much cheaper faster software emulation ?
 
 Just trying to work out the point of the standalone

latency and timing, it's the only point of using an fpga for emulation rather than a program running on a general purpose computer.

The gates in an fpga are dedicated to a particular job, so they can monitor your joystick inputs and run code and display video simultaneously. An emulator on a general purpose computer multiplexes all it's gates, so it will be doing different tasks at different times.

Some LCD TV upscalers have terrible latency too, so you should compare it to an Amiga on a CRT. If you can't tell the difference (and some people cannot) then you don't need to spend the extra money.

There is also the cool factor, but agai
n if you don't feel that then it's not for you.

Some people hate emulators running on a general purpose computer for not being authentic, for other reasons than timing and latency, which is more of a religious thing. Using FPGA for emulation is no real different, if the original hardware had analogue quirks (like undocumented behaviour changed based on temperature) then an FPGA is going to be just as bad at emulating that as software on a general purpose computer.

[jj]

latency and timing, it's the only point of using an fpga for emulation rather than a program running on a general purpose computer.

The gates in an fpga are dedicated to a particular job, so they can monitor your joystick inputs and run code and display video simultaneously. An emulator on a general purpose computer multiplexes all it's gates, so it will be doing different tasks at different times.

Some LCD TV upscalers have terrible latency too, so you should compare it to an Amiga on a CRT. If you can't tell the difference (and some people cannot) then you don't need to spend the extra money.

There is also the cool factor, but agai
n if you don't feel that then it's not for you.

Some people hate emulators running on a general purpose computer for not being authentic, for other reasons than timing and latency, which is more of a religious thing. Using FPGA for emulation is no real different, if the original hardware had analogue quirks (like undocumented behaviour changed based on temperature) then an FPGA is going to be just as bad at emulating that as software on a general purpose computer.

Thanks for a reasoned response.  So go for an accelerator if you want the geninue-ish amiga feel.  As I guess these are quite far off in compatibility ?

[psxphill]

Thanks for a reasoned response.  So go for an accelerator if you want the geninue-ish amiga feel.  As I guess these are quite far off in compatibility ?

It depends on your priority. For games then the apollo people will argue that it's better for compatibility with 68000 games than a real cpu is.

However if you want to run bsd or shapeshifter, then you want an mmu and vampire/apollo doesn't support those at all.

It's less clear for software that needs an fpu, supposedly that exists but either doesn't work or hasn't been tested enough so it's disabled. Whether it will ever be enabled or not is another matter, they'll probably say that you don't really need to run that stupid software anyway.

I'm still in two minds. If they supported an 060 CPU, MMU & FPU with no extras with an additional core that had all their custom extras then I'd be in. Even if running the authentic 060 meant I couldn't run software that wouldn't run on a real 060.

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

[Niding]

psxphill makes some good comments regarding FPU.

At the moment there is a FEMU program, that software emulates FPU, which can be tested both in WinUAE and on real hardware missing the FPU.

It allows you to run software that requires FPU, but during FPU intensive operation, expect rather punishing performance issues when running it on Vampire hardware.
But the program/demos/games runs atleast (more and more I should say).

BUT, FEMU is work in progress, and Jari is improving the emulation. Its still just that tho, emulation.
What comes of a possible hardware FPU with the introduction of V4 is a open question.
Its been said that the Apollo Core contains FPU, but its more advanced/added features.
Some might say its compatible, but my comment/question then becomes;

Cant the Apollo FPU be used in the future to fix the performance issues we get from FEMU, and then take care of the compability issues FPU wise thru library/FEMU adaption?

Im just throwing my comment out there for more knowledgable people to elaborate on the possibilities

[psxphill]

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.

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 for 68k until FEMU came along.

[guest11527]

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 for 68k until FEMU came along.

SoftFPU was a product available for MacOs which did the same, i.e. it emulated FPU instructions for the "Economy Class" version of the 68040, namely the 68EC040. The EC040 had a special trap for all FPU instructions software would take. Unfortuately, due to a bug in some EC040 masks, SoftFPU would not run reliably, in particular if a FPU instruction crossed a page boundary. Hence, the product caused a series of problems at users, and there is no known workaround for this problem at hand. (Yes, the 68040 has a long list of errata, too.)

For Amiga, this is not exactly the right way of handling it. The AmigaOs math model is based on the math/mathieee libraries which implement all the necessary math operations, and which uses the FPU whenever one is available. Software that really requires high-speed math (i.e. raytracing etc) should better check the avaialbility of a FPU and branch into a distinct set of worker functions rather than requiring users to know which hardware they actually have available. Just crashing (as we see it here) is not an acceptable practise, and a software emulator is neither a very good solution for improperly written software.

[guest11527]

FEMU should have been part of Amiga OS in 1985.

No, software should have been written properly. As often on the Amiga, it was not. If no FPU is available, mathieeedoubbas (or even singbas) performs much better than having to go through an emulator trap.

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

[guest11527]

I think the '060 is missing some INTEGER instructions that the 040 had and those again are handled by a library call...

What is missing are 64bit multiply and divide instructions. That's taken care of by the 68060.library. But again, the better option is (again) not to depend on this but rather use the utility.library to handle 64bit math. Popular C compilers provide options for this.

as some addressing modes.

That only goes for FPU instructions, and the addressing mode missing is packed decimal. But it is also missing on the 68040. It's a lesser used encoding of floating point using a decimal (rather than binary) encoding.

The 68K family has lots of quirks and it's interesting that the Apollo manages them well.

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

[psxphill]

They are not emulators.  Just code to handle trapped cpu missing instruction exceptions.

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

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

[guest11527]

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

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.

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?

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.

Yet people will whine about the *custom* one they are developing... /facepalm.

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

Again, OS-level support is missing in 3.1 for an MMU.

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

How is that a must-have feature?

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

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.

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.