Accessing Amiga native structures outside Sonnet memory.

[DvdBoon]

Structures returned from Run68K() calls to, for example, OpenWindowTags() from the intuition library cannot be manipulated by the PPC if the are in Amiga Fast memory.

Either we force placement of these structures into sonnet memory by patching the Allocmem() function or we brute-force it by upping the priority of the sonnet memory. The latter slows the Amiga a lot.

Another possibility is to catch all Fast memory access through the PPC MMU. This will slow the PPC a lot.

Any other thoughts?

[rkujawa]

Before we venture on implementing a complicated software solution, let's rethink this carefully. This is more general problem than just being unable to access Amiga Fast memory.

The underlying problem is inability to make any kind of transaction from PCI bus to Amiga. Why? Seems like Mediator can not be a bus master on the Zorro bus, which is a prerequisite for this.

Elbox's marketing material states it is possible. One of the advertised features of Mediator 4000 is: DMA to A4000 motherboard space. Whether it is true or not, I don't know. I have no idea how to reverse engineer this, because last time I checked pci.library only used graphics card memory for DMA purposes.

I wonder what will happen if we open the MASTER jumper and try to access low addresses from PCI side of the bus? Like Chip RAM on Amiga main board? Will that cause a bus mastering transaction initiated by Mediator to appear on Zorro bus? If nothing happens, I guess there's no easy solution. I'd still try that first.

[DvdBoon]

I think if I remember correctly, it states DMA to A4000 motherboard space from PCI space but I hope I am wrong :-)

The most simple solution I am thinking about is to install a patch which looks for warpos programs using a customizable list and patch memory accordingly

[rkujawa]

If we're talking about purely-software solution, I think most compatible way would be installing stubs that could be called from PPC code to access any location via 68k CPU. Such solution would require MMU magic on PPC side. But I think it doesn't have to necessarily slow everything down. I think MMU could be programmed to run this do-things-via-68k procedure in case we're hitting Amiga 68k addresses...

I'm afraid just looking for a customisable lists does not solve the entire problem. I can easily imagine someone writing a WarpOS program that is accessing the memory by simple means of reads and writes, then uses it to exchange data between 68k and PPC task. We won't be able to catch it, just as we won't be able to catch any accesses to Amiga custom chip registers.

Also, I think we can patch PPC hunks during run time (when starting application, for example via some wrapper) to place them in Sonnet memory. Sonnet memory is accessible by both PPC and 68k CPU so no problem here. But this is a separate issue. Actually, I created a separate issue #12 for this.

[DvdBoon]

WarpOS strictly forbids manipulations of Amiga OS structures by the PPC. However, it is allowed to read data from 68K structures and use them as input in PPC subroutines or calls to 68K subroutines.

For now I suggest the following:

1) Put code in place at the 68K side of Run68K() to recognize calls to functions which return a structure. Let this code copy the structure to sonnet space. 2) Set up the PPC MMU to intercept calls to FastMem (it actually is already set up this way). Let the 68K then fetch this data through a special (faster than normal) context switch. This will be potentially very slow as it will switch on a per instruction basis. Although it does not have the normal overhead of a normal context switch.

[rkujawa]

While the specification forbids manipulations of OS structures from PPC code, there is no mechanism to actually stop this. This is something we should remember. If something is not actually blocked at the API level, then we can assume "smart" developers did it anyway.

[DvdBoon]

That's where point 2 comes in.

On the other hand, I know that there is no mechanism to actually stop this, but the reason behind it, is cache coherency. All kinds of nastiness happens if the PPC changes 68K data without user code to address the caches as WarpOS doesn't do it for you (only for the cross CPU messages).

[DvdBoon]

PPC intercepting FastMem load/store calls partly implemented.

[DvdBoon]

Most common load/store calls from PPC to 68K memory intercepted and handled. Some uncommon (indexed, byteswapped etc) commands not yet. PPC FPU access to 68K memory not handled yet. (I'm not commenting on the efficiency of the code :-P)

[rkujawa]

To be honest looks good enough for me when it comes to efficiency :smile: .

[DvdBoon]

Following is now supported with calls to FAST/CHIP mem: stb, stbu, stbx, sth, sthu, sthx, stw, stwu, stwx, lbz, lbzu, lbzx, lhz, lhzu, lhzx, lha, lhax, lhau, lwz, lwzu, lwzx.

Not yet supported: stbux, sthux,, stwux, lbzux, lhzux, lhaux, lwzux. The more exotic stores and loads like conditional stores. All FPU commands.

[DvdBoon]

This has been solved satisfactory. More instructions will be supported when needed/encountered.