Vampire emulation in WinUAE
 

Any thoughts about this?

No?

Question is... why ?

Why? Why not?

I'm just curious from a technical point of view. Is it doable at all? Not worth the hassle? Or is it like ppc emulation.. never gonna happen?

If vampire becomes some sort of standard it would make as much sense emulating it as emulating ppc. There are over 800 people on the waiting list just for the a600 version.

Because it is just fast Amiga that is never going to be "finished" due to being reprogrammable, it is not interesting old piece of retro hardware.

Also all the extra instructions etc are in my opinion pointless that no one is going to use seriously anyway (except for demonstration purposes) and if someone does, it only causes fragmentation.

I take that at least this point of your reasons may be subject to change.

I could be wrong here (wouldn't be the first time, wouldn't be the last), but if you want to 'emulate' a Vampire II, isn't almost everything needed already in WinUAE, asides from a few CPU instructions that, as Toni said, are unlikely to be used, particularly for most of the software you're likely to use anyway.

I mean, just set CPU to 68020/24 bit addressing off, JIT on, CPU emulation speed fast as possible, RAM to 128mb Z3 Fast, and in RTG Graphics card set it to maybe UAE Zorro III. Sure it wouldn't be 100% the same as a Vampire, but it would be close enough I'm sure.

I don't think so. This is not the only problem with Vampire (and other modern non-basic CPU expansions). Also I don't have any interest or use for it whatsoever.

(I am not sure if I should say anything more, this may end in chaos and closed thread.. But here goes..)

It looks like Vampire has same problem that many (nearly all!) modern Amiga expansion have (that needs custom drivers): hardware is brilliant but then the design is force-fed to users and especially to developers without enough knowledge of AmigaOS internals and how hardware interface should work to be Amiga-like, result is weird address space, alien non-Amiga interface and not really compatible if custom drivers don't find the hardware and requiring to "upgrade" existing low level software to stay compatible. And still expect interest from developers when most of low level debugging utilities won't work and there is no way to do any quick testing with emulator first. (because hardware simply is too different than anything else).

Then there is non-technical side: it is sold (It may have been said by clueless fanboys only but no one corrected them. I don't mean EAB only, it is everywhere) to be replacement for EVERYTHING, BEING THE BEST AND ONLY EXPANSION YOU EVER NEED, even for users that only want to have A500 compatible hardware or only want to program for unexpanded A500 or A1200 or if you only use emulator. You still apparently need to buy it!

I don't think I need to remind that any non-constructive reply -> instant end of discussion.

My $0.02. Apollo Core instruction set might be really useful if (when?) the instruction set gets stable and we have applications (datatypes, etc.) utilizing AMMX and (possibly) SSE. But...

If I'm not mistaken, they are adding more registers to their m68k implementation. More registers = OS kernel has to handle them while task switching, or bad things will happen if more than one task tries to use them. Which means we would have to use their exec update - we have no guarantee it will work well without the rest of the Vampire emulated.

People with the vampire want speed.
But if you use winuae then you can just setup jit + max speed and you'll get a magnitude more speed than the vampire will ever give.

Anyway this is building castles in the air. How can someone possibly implement something that's not stable and not properly documented ? Docs don't even agree !
(check http://apollo-core.com/index.htm?page=instructions and http://apollo-core.com/knowledge.php?b=4&note=2352 : they tell two very different stories)

Yes, the .ods sheet is up to date, the webpage is not.

This is still work in progress and i don't think any team member asked Tony to do that. However, a real neat documentation will be provided to public when it's ready.

AFAIK, the exec.library patch only does one thing, which is to recognise the Vampire's FastRAM.

I understand and agree with your reasoning Toni, and am just replying to the thread in general as I had some thoughts on this after mulling it over for the night.

It really depends. What we are seeing in the Android space, is builds where the java bytecode and any C or whatever, are built for all architectures. From Arm to x64. Then the complete package is deployed. Google's taken care of it, and you just install Eclipse, include your code, write some Android wrapper for your application and then hit generate builds. Then drag the multi-platform apk to their play store.

If Amiga is to move with the times, then the future of Vampire might be to expand the existing development environments to do something similar. Of course, this would require that whatever is developed be in a high level language like C, where a modern Amiga C development SDK can take the high level code and output any and all possible target platforms that haven't strayed too far. And MMX instructions are irrelevant in this case.

I am sure a lot of us follow modern web technologies, you develop in the latest javascript or the typescript dialect and then you can run translators to downgrade your javascript to whatever will run on old Apple devices, old Internet Explorer browsers, however downgraded you want to go. Surely vasm/vlink can generate non-MMX builds by translating the instructions - at some level the developer is targeting accelerated machines over the stock Commodore models, but there are a variety of accelerators out there which might still be able to run the code potentially, other than Vampire.

Anyway, just some thoughts on why Vampire specialisation isn't necessarily a deadend for non-Vampire users. It remains to be seen if it is actually practical, and if it is, whether anyone picks up the ball.

FastRAM patch alone already means that you cannot run "SetPatch QUIET" with AmigaOS 3.9 BB2 ROM Updates. You need to patch or skip BB2 exec update.

I think that pretty much nails it. This is the best way to get speed in an emulator. I would say this removes any need for emulating a Vampire.

Are there any advantages of emulating a Vampire over using jit + max speed?

I don't think so. Compatibility-wise, WinUAE would probably be better, too.

Compatibility-wise UAE can be better, but... somehow I have an impression, that games on real Amiga (or even MIST FPGA board) run smoother. I expect Vampire will beat the UAE with this regard.

That's a wrong impression, really. If you are talking about display issues, those have to do with what kind of display you have and how you are configuring everything, and not WinUAE.

Topic is starting to drift..

-

If you are going to make Amiga compatible hardware, you need to work with AmigaOS, even if it it causes annoying restrictions. You shouldn't just bypass them with hacks because it is easy and AmigaOS limits annoy you.

If you have custom hardware, you should have also boot ROM that does the initialization. Thats how all other accelerators work, if they need HD controller drivers, add extra RAM etc.

And so on. Lack of proper firmware is IMHO the biggest problem with many "modern" expansions.

But there is not enough developers, there is no compiler support, there is no debugging support. Everything needs to be done before actual support happens. It won't.

The whole point of emulating it would be to get access to the Apollo instructionset. Not rtg or speed.
Let's not call it "vampire emulation", but add Apollo-core as a cpu option in addition to the 68k's and ppc.

I just like the idea.