English Amiga Board

English Amiga Board (http://eab.abime.net/index.php)
-   request.UAE Wishlist (http://eab.abime.net/forumdisplay.php?f=56)
-   -   Vampire emulation in WinUAE (http://eab.abime.net/showthread.php?t=84264)

roomeo 27 September 2016 22:40

Vampire emulation in WinUAE
 
Any thoughts about this?

Toni Wilen 28 September 2016 09:24

No?

TuKo 28 September 2016 09:36

Question is... why ?

roomeo 28 September 2016 09:46

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.

Toni Wilen 28 September 2016 10:14

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.

grond 28 September 2016 10:39

Quote:

Originally Posted by Toni Wilen (Post 1113617)
Also all the extra instructions etc are in my opinion pointless that no one is going to use seriously anyway (except for demonstration purposes)

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

TroyWilkins 28 September 2016 10:42

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.

Toni Wilen 28 September 2016 11:16

Quote:

Originally Posted by grond (Post 1113620)
I take that at least this point of your reasons may be subject to change.

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.

Romanujan 28 September 2016 18:57

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.

meynaf 28 September 2016 20:36

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)

flype 28 September 2016 21:14

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.

cmsj 28 September 2016 21:17

Quote:

Originally Posted by Romanujan (Post 1113720)
Which means we would have to use their exec update

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

copse 28 September 2016 23:42

Quote:

Originally Posted by Toni Wilen (Post 1113617)
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 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.

ShK 29 September 2016 05:28

Quote:

Originally Posted by cmsj (Post 1113745)
AFAIK, the exec.library patch only does one thing, which is to recognise the Vampire's FastRAM.

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.

StarQuake 29 September 2016 16:24

Quote:

Originally Posted by meynaf (Post 1113738)
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.

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?

Akira 29 September 2016 16:29

Quote:

Originally Posted by StarQuake (Post 1113890)
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.

Romanujan 29 September 2016 17:36

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.

Akira 29 September 2016 17:46

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.

Toni Wilen 29 September 2016 18:13

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.

Quote:

Originally Posted by Romanujan (Post 1113720)
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...

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.

roomeo 29 September 2016 18:26

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.


All times are GMT +2. The time now is 00:40.

Powered by vBulletin® Version 3.8.11
Copyright ©2000 - 2018, vBulletin Solutions Inc.

Page generated in 0.04445 seconds with 11 queries