shared xram, individual "ixram"

Assuming that you have all your hardware sorted out, what you need is a software solution to avoid simultaneous attempts to access the shared xdata.

A software solution will slow processing significantly, so it is a good idea for each processor to have some xdata memory of its own.

The simplest method would be to a have a couple of flags, exchanged via couple of spare port pins, allowing each processor to indicate when it wishes to access the shared xdata and to read when the other processor wishes to access the shared xdata. Each processor puts out my_flag and receives your_flag. Things are also simplified if, at any given time, one processor has priority access to the shared xdata

The procedure for each processor to follow when it wishes to access the shared xdata is as follows:

Wait until your_flag is clear.
Set my_flag.
Double-check that your_flag is clear.
Complete shared xdata access.
Clear my_flag.

The double-check is required because it is possible that the two processors set their my_flag at exactly the same time. The double-check is resolved, by having the lower-priority processor back down and return to waiting for you_flag to clear.

This sort of scheme may be integrated into your software by use of macros or function calls to access the common xdata - simply pass the address of the variable to the function or macro.

Building your software presents some interesting problems. Presumably, your processors each want to share the variables placed in shared xdata. The common variables should be indicated as being volatile. You could place them manually using the _at_ keyword.

If you need to do more complicated things such as allowing each processor to have its own unshared variables and even to have local, overlayed variables then you are going to have to read the manuals carefully and do some experimentation, but these things should be possible.

Assuming that you have all your hardware sorted out, what you need is a software solution to avoid simultaneous attempts to access the shared xdata.

A software solution will slow processing significantly, so it is a good idea for each processor to have some xdata memory of its own.

The simplest method would be to a have a couple of flags, exchanged via couple of spare port pins, allowing each processor to indicate when it wishes to access the shared xdata and to read when the other processor wishes to access the shared xdata. Each processor puts out my_flag and receives your_flag. Things are also simplified if, at any given time, one processor has priority access to the shared xdata

The procedure for each processor to follow when it wishes to access the shared xdata is as follows:

Wait until your_flag is clear.
Set my_flag.
Double-check that your_flag is clear.
Complete shared xdata access.
Clear my_flag.

The double-check is required because it is possible that the two processors set their my_flag at exactly the same time. The double-check is resolved, by having the lower-priority processor back down and return to waiting for you_flag to clear.

This sort of scheme may be integrated into your software by use of macros or function calls to access the common xdata - simply pass the address of the variable to the function or macro.

Building your software presents some interesting problems. Presumably, your processors each want to share the variables placed in shared xdata. The common variables should be indicated as being volatile. You could place them manually using the _at_ keyword.

If you need to do more complicated things such as allowing each processor to have its own unshared variables and even to have local, overlayed variables then you are going to have to read the manuals carefully and do some experimentation, but these things should be possible.