On the CD system the Z80 can write to ram (it can even self modily its own code if it wanted, so you have 64kb) The 68k can see that ram when it is opened for writing (like when z80 M ROM is loaded from CD). The issue is I don't think its possible to have the z80 running and the 68k being able to see the RAM at the same time. The z80 would have to do slices of work and then stop with the 68k then looking at the results and then updating graphics as needed. Sound might be a problem but you could have a situation with the z80 doing slices of work while the 68k is converting the results of the previous slices work (because it copied the z80 workram into the 68k workspace).
Raz
Really interesting,
Phoenix ROM is about 16Kb (only game with no gfx) so we can fit in Z80 64Kb ram + reserved area for Phoenix PCB stats:
0000-3fff 16Kb Program ROM
4000-43ff 1Kb Video RAM Charset A (4340-43ff variables)
4400-47ff 1Kb Work RAM
4800-4bff 1Kb Video RAM Charset B (4840-4bff variables)
4c00-4fff 1Kb Work RAM
5000-53ff 1Kb Video Control write-only (mirrored)
5400-47ff 1Kb Work RAM
5800-5bff 1Kb Video Scroll Register (mirrored)
5c00-5fff 1Kb Work RAM
6000-63ff 1Kb Sound Control A (mirrored)
6400-67ff 1Kb Work RAM
6800-6bff 1Kb Sound Control B (mirrored)
6c00-6fff 1Kb Work RAM
7000-73ff 1Kb 8bit Game Control read-only (mirrored)
7400-77ff 1Kb Work RAM
7800-7bff 1Kb 8bit Dip Switch read-only (mirrored)
7c00-7fff 1Kb Work RAM
Now the 68K SW interface can handle this area:
void Z80_WRMEM(dword A,byte V)
{
// $0000-$3800($3FFF) ROM
if (A < 0x4000)
return;
else
// $4000-$4FFF RAM/VRAM
if (A < 0x5000)
{
*0x3c0000 = Phoenix_Tile_addr;
*0x3c0002 = Palette;
.....code...code.....a lot of code.....
}
..and substitute real Phoenix PCB location Ex. 0x4000 in Z80 68K RAM area equivalent.
As you say I don't know if it can work (z80 slices work and sound managment), your analysis it's good, surely not easy to do.
Ciao
BEY