Native Interface as Fake Hardware ?

[thellier]

Hello

This is a question inspirated from this great thread
http://eab.abime.net/showthread.php?t=70744

Context: The native interface is broken in WinUAE-ppc because the PPC emulation cant fall back to 68 emulation so cant call native interface

So why not just having the "native interface" implemented as "fake hardware" with hardware registers mapped in the RAM

- This will allow to call x86 code from 68k and PPC emul
- This will stay simple
- Something like having:
16 x 32 bits registers for data (like the old a0-a7 a0-a7 from old interface)
1 X 32 bits register START_NATIVE_CALL
Writing a value in this register will start the native call
Open library: 199
Get function address: 198
Call function: 197
Close library: 196
Like Frode wrote in the mentionned thread

- Upside this the uaenative.library from Frode can be build easily
- So the apps will use uaenative.library everywhere

- Also real Amigas may have real expansion that will works this way : just imagine an FPGA board with natives .library inside


Alain Thellier - Wazp3D

[Toni Wilen]

IMHO that is not good enough for me.

I'd make full autoconfig board support with all read and write accesses routed to dll function, even autoconfig data (nybbles) should come from DLL.

DLL only needs to get addrbank ?get and ?put functions and callback function to generate interrupt (level 2 or 6). Plus whatever extra information is wanted, perhaps also linear RAM "bank" for better performance, if someone wants to create some sort of display board..

-> Full external implementation of single autoconfig board. Can support more than one board at the same time. Emulation does not need to care about manufacturer ids or anything at all, all the logic is in the DLL, very flexible, even autoboot capable storage device is possible without any changes to emulator.

[thellier]

Hello
>IMHO that is not good enough for me.I'd make full autoconfig board support
Perhaps this solution is "conceptually" better buuuut I dont see how it will make it simpler for other 3rd party people to make 68k/x86 library/dll :-/
Even if you build yourself the uaenative.library for this beast : All will still become very complicated : for example reading/writing data structures in Amiga RAM from the DLL will need lots of get/put

Alain Thellier

[Toni Wilen]

Assuming you wanted to be PPC (=OS4) compatible: You are not able to directly read or write from host-side Amiga RAM anyway because you can't be sure about physical address of any memory location.

You need to have Amiga-side helper program and pass all data using expansion board's IO addresses (logical == physical is guaranteed).

[thellier]

OK I see the problem now :-) : virtual mem in os4

Then it will need some kind of "linear RAM "bank" for better performance"
For example if War/zp3D wants to draw 3000 vertices in a single call

Do you hope to implement this "board" soon ?

Alain Thellier

[Toni Wilen]

Not until 3.2 is out (1-2 months, I guess). Properly supporting it will need too many expansion handling updates, too easy to break everything. It is also going to be part of OS4-friendly expansion update which needs similar expansion hardware emulation update.

[thellier]

This is really a good news
So I hope 3.2 will be released soon :-)

One more time : Great thanks for all your Great Work

Alain Thellier

[thellier]

Hello Toni

Anything new on this topic ??? Is it planned for a near future ?

Thanks

[Toni Wilen]

Basic board already exists, it can be used to read some emulation information from Amiga side (works under OS4 too), it is still work in progress.

There is no boot rom and it is not possible to access Amiga side state from host side. This most likely won't happen until some OS4 developer explains what is possible and what is not not possible with autoconfig board that has m68k boot rom. (I am not going to waste time to code something that only works in real m68k systems because something is dropped or not implemented in OS4)

What did you mean by "linear ram bank"?

[thellier]

Hi thanks for answer

I mean the way to get a whole array of data from host side

something like
Amiga side:
float vert[30000]; /* x y z */

draw_those_vertices_as_triangles_the_x86_side(context,vert,30000);

x86 side:
===> so not having to read each vertices one by one
vertx86=get_block_of_mem_from_amiga_side(vert,30000*sizeof(float));
(but of course byte-ordering not included)
loop(10000)
drawatriangle(context,vertx86);

>you can't be sure about physical address of any memory location
BTW wasnt OS4 supposed to have a special "flag" for memory used for DMA devices ?
http://wiki.amigaos.net/wiki/Exec_Memory_Allocation
Perhaps using only this kind of mem may help for creating ppc-x86 drivers like Wazp3D ?

If I am saying something stupid just let me know as I dont know much about MMU,mem,etc...


Alain Thellier

[Toni Wilen]

I don't think that is possible without some OS4-side OS4-specific code. (=not my problem).

[Toni Wilen]

I was not so nicely reminded about native stuff yesterday but I still thought about it a bit more..

Because I 100% hate writing any non-UAE software, what about this: generic "programmable" Z2/Z3 board that does something like this:

- autoconfig programmable. (can even come from DLL automatically)
- most of the board is "RAM". Both Amiga and native side can read and write it. This is the only way to transfer data between sides. Protocol is 100% software writer's problem. Driver/software can put all its data in RAM to allow 1:1 address mapping (only way to guarantee it under OS4), big Z3 board should be more than enough for everything.
- few reserved addresses for interrupt support: level 2 and 6 enable and request bits somewhere. (again, usage is completely under software control)
- some other helper IO addresses (semaphores, wait until address changes, call dll function x when address y was modified by Amiga side and so on)

This would allow to make any kind of "native" board without changes to UAE. Does not require 68k (=also fully PPC compatible) and most importantly I don't need to write any other software than UAE

And finally: I need useful feedback, I am not going to wait days or even weeks for reply.. Remember to think out of the box, don't limit yourself to old native ways

[Toni Wilen]

Some more thoughts..

Board needs to be divided in two banks for optimal performance.

First bank is used for "IO"-like accesses and uses indirect JIT mode so that emulator can detect when Amiga side does read or write accesses. Any write access is is "forwarded" to native DLL function with address, size and value parameters (maybe more?).

Second bank (larger bank) is plain "do anything you want with it" RAM with JIT direct capability.

All the data should be stored in second bank, IO bank is used to tell native side that data is now ready, do something with it.

Example: Amiga side software copies graphics data to "fast" bank, then writes to "IO" bank that data is ready. Native side gets called, does whatever it wants to copied data and can also write some data back if needed. Or even trigger Amiga level 2 and 6 interrupt, so there is no need for polling in Amiga side when it waits for native side. (If native side started thread(s) and runs async)

Binding the board with dll: Amiga side FindConfigDev()'s the board, pokes name of dll to IO side of board. Your dll init gets called syncronously (if found), status gets returned to IO bank address.

"Early" binding is also possible so that custom autoconfig data (including possible boot rom) is available at boot. This is not priority feature.

[thellier]

Hello Toni

>I was not so nicely reminded about native stuff yesterday
Sorry I wasnt wanted to be impolite if so excuse me
Again thanks for all you works for WinUAE

If I understand well your "card"
1st bank is somehow the "registers" for starting call & how to call
2nd bank is parameters data
Other features you describe may be nice but are not needed for a first simple usage

>Amiga side software copies graphics data to "fast" bank, then writes to "IO" bank that data is ready. Native side gets called, does whatever it wants to copied data

Note: Wazp3D can draw as "soft to bitmap" "soft to image" "hard" "hard overlay"

That would not be enough in the Wazp3D case as it access to random pixels on the bitmap when only x86 for soft rendering
(soft to bitmap)
or
in (hard) mode opengl32.dll is used and need somehow to copy the x86 gl context backbuffer to uae display (write a rectangular x86 memory block to amiga bitmap memory)
Now in Wazp3D this is done (by x86's OpenGL) reading GL backbuffer to amiga-bitmap pointer
An other method called "overlay" in wazp3D is to have an other borderless window (from windows x86) upside winuae one where Wazp3D draw ==> but this method cant mix amiga drawings and Warp3d in a single display (like texts and graphics)

So a write to bitmap is needed for a good emulation
But is it a problem ? I mean MMU dont map video ram, no ? So x86 writing to amigabitmap mem is possible,no?


Alain Thellier - Wazp3D

[Toni Wilen]

Originally Posted by thellier

So a write to bitmap is needed for a good emulation
But is it a problem ? I mean MMU dont map video ram, no ? So x86 writing to amigabitmap mem is possible,no?

Yes. Any autoconfig board is 1:1 mapped so you can FindConfigDev() VRAM address (or whatever method you use to find the Amiga-side bitmap vram address) and then share the address via "native board" to native side. Then call some function that does Amiga side<>native side address translation, after that direct access from native side should work fine.

Important part is that Amiga side only uses 32-bit Amiga addresses, Amiga side should never see native addresses!. Only native side should do the translation when needed (to and from). This also guarantees transparent 32-bit/64-bit compatibility.