Best way to write native code?

Long time lurker, new member here. Thanks for FS-UAE, it's an amazing piece of software.

Enough kissing up though, I have a question about writing native code libraries.

I've looked at the uni-sdk and that seems good for a lot of tasks, but is there a way to call back into 68k code with it?

Also, does the emulation continue to run while my native code is running or does it pause?

Is the old complicated way of writing native code still the best way? What are the limitations there?

Thanks

[FrodeSolheim]

Originally Posted by arodgers

Long time lurker, new member here. Thanks for FS-UAE, it's an amazing piece of software.

Thanks

Originally Posted by arodgers

Enough kissing up though

Fair enough

Originally Posted by arodgers

I've looked at the uni-sdk and that seems good for a lot of tasks, but is there a way to call back into 68k code with it?

No, at least not currently. There is support for exposing UAE functions to the native libraries, but right now this is limited to getting the UAE and UNI versions. Exposing more functionality is possible in the future.

Originally Posted by arodgers

Also, does the emulation continue to run while my native code is running or does it pause?

Yes, the native code is run in a thread, the Amiga caller task is suspended while waiting for the native code to complete, and UAE continues emulation.

(If you call into uaenative.library more directly, e.g. via assembly, you can also choose to run the native code synchrously, pausing the UAE emulation until the native code returns. You can also pass more parameters via registers this way. The Amiga-side UNI C header presents simplified functionality, because in many cases you are better off using a struct to pass complex arguments).

Originally Posted by arodgers

Is the old complicated way of writing native code still the best way? What are the limitations there?

IF by "old way" you mean the older WinUAE implementation, then the differences are:
* The old way is WinUAE-only.
* It only works with 32-bit code, it isn't 64-bit safe.
* It gives you access to the WinUAE hwnd object (though this can be added to the new native code system if needed).

The uaenative.library hasn't really changed since the initial release, mostly since it hasn't (as far as I know) seen any real usage. The interface will not be extended until there is a known use-case for it

[Toni Wilen]

I am starting to think that native support should use hardware level emulated board to make it much much easier to support in any Amiga compatible OS. No need for annoying UAE traps.

It can be normal Z2 or Z3 autoconfig board, that you find using usual library calls, then allocate it, for example by reading from single IO address, you get back offset to your IO region. (or null if nothing available). Write commands to some IO region, you get back something. Free the board when not needed anymore.

[thellier]

Hello

>native support should use hardware level emulated board
Nice :-) is it planned for a next release ;-) soon ? :-)
BTW @Frode : native.library should be enhanced to be usable with OS4/WinUAE-ppc ...

Keep on the good works

Alain

[Toni Wilen]

OS4 support can become either really tricky or really slow because there is no 1:1 address mapping. Logical address sent to native side is useless under OS4.

Slow would equal "indirect" trap system where "bounce buffer" is needed, instead of directly using some memory address (which is not going to work because logical address won't be same as physical), data is first copied to hardware board address (because it is hardware board, it has logical == physical mapping), then "other side" can read it. And vice versa. Obviously it is much slower than direct access.