Native (UAE) DataTypes

Hello,

I recently installed WinUAE with an old version of Amiga in a Box and started updating my datatypes because most of the stuff was from 2005 (or older) in Aiab. I owned a Poweredup A500 with a 20 MB HD and a 68030 ( I believe GVP) on the side and a KCS PC board. And Amiga has always been my favorite, regardless of what the commercial owners did with it.

Then I asked myself: great, now I am emulating a 68040 and task it with decoding a JPEG file (or any other format) while decoding that JPEG file on my host platform takes much less time.
My idea, enable capabilities from the native platform inside the Amiga, giving the amiga the performance boost of the lower platform.

I know something about coding, but not in C or C++, however the idea can be ' simple'
The Emulator has a switch that enables use of 'Native' datatype capabilities. In Windows JPG decompression can be done by GDI (or whatever library) and the raw decoded data (In windows a BMP) can be transfered to the Amiga (with conversion I suppose AMiga doesn't do native BMP). When I programmed VB6 there was a picture object that did the job. The WinUAE could have such a hidden object.

The UAEJPG datatype would have to hand the JPG data to the emulator. The emulator would have to give the correct form of data back where the Amiga takes over again. I think we would need to define a real hardware device for the Amiga (The UAEBridge) where the UAE datatype could dump and get its bits.

Of course this can work for BMP, MP3 and whatever and it would be fast while you could still use native 680X0 datatypes if it has to be 100% native.

I am willing to put work in this, but the C/C++ part is beyond me. My questions are
- How does the community think of this (good/mediocre/bad/worse..)?
- Are there people willing to help

Thanks
Roland

[Toni Wilen]

It is possible but it needs new and much more complex interface.

Currently you can call x86 code but emulation is stopped until call returns which is unacceptable if call takes long time.

Originally Posted by Toni Wilen

It is possible but it needs new and much more complex interface.

Currently you can call x86 code but emulation is stopped until call returns which is unacceptable if call takes long time.

Imagine Datatype calling a device in the Amiga.
That datatype could give a number too that device and hand it either the link to the actual file or a memory pointer. WinUAE could recognize that number and call the platforms library. In VB6 you could put an Img activeX object in a window. You could load that image and then blit that image back to any memory addres. As I said: willing to specify the interfaces, even write some skeleton code for that.

The advantage is that your emulator can continue to run because the amiga is control. Besides that, this interface ofcourse can go beyond datatypes. How about math libraries etc.

Cheers

[Toni Wilen]

First requirement: Interface needs to be portable (non-Windows). No point in doing OS specific interface for operations that are portable. Interface itself of course can't be fully portable. (Needs to load libraries or something)

Second requirement: I most likely won't accept other designs unless they are exactly like I want them to be

It probably will be something like this:

Amiga-side code calls interface function with required parameters (via "UAE boot rom" traps), interface starts a thread that executes native code and returns back to emulation. Thread sends signal to interface when operation has finished (or it failed), interface signals Amiga-side code (that was Wait()ing normally). Finished.

Math libraries won't help, FPU instructions are already translated to native FPU instructions in JIT mode. (Amiga-side to host side context switch would be slower than executing the FPU instruction normally!)

Looks like we agree on almost every part. The Amiga side, should be a standard interface so other platforms should be able to use the same datatype. Whats on the otherside, indeed, is platform specific. Linux uses libraries for most operations, Windows has DLL's or stuff integrated in DirectX. Aros might pass it to it's own native datatype etc

WinUAE might have internal libraries (embedded at compile time) that do the job, so it can internally spawn a thread and be lightening fast. Imagine an integrated DivX datatype or something. FFPlay isn't really the best player.

Cheers

[fishyfish]

Something akin to powerup/warpup, but for x86 could be interesting, although the context switching could chew more time than it might theoretically save. Regardless of how thigs are done this is an issue. Saving time for things that happen pretty much instantly (as is the case with an emulated 68k cpu) seems a lot of work for something thats pretty much redundant anyway.
The only exceptions I can think of are for video, but the entre amiga os side datatypes system would need updating to even work with current video formats (unless you only want to run video files from ram disk).

Id imagine byte ordering could also be a thorn.