Actually Elbox has said that the Shark (or was that the Shark + only?) was an all computer in itself, with access to classic hardware.
Ok, so far so good. SharkPPC is a standalone system on PCI card.
Now here's the tricky part: It's said to have full access to Amiga custom chipset. But that will never work.
Lets imagine as simple thing as a game/demo reading a trackfull of data from a floppy. It will write custom registers to set up DMA for read operation. The address is chip memory. How if the game would be running on SharkPPC system, the address would be local memory there (but lets assume both systems have chip memory mapped 1:1, so addresses remain the same).
Now lets assume that magically the custom registers reads & writes are relayed between the two machines (including new state of custom read-once registers). The final register write initializes DMA transfers from floppy to memory (this happens on the A1200). Once the floppy DMA is finished, the data has been transferred. Next the read routine will use blitter to decode the MFM encoded data read off the floppy. Track has been loaded.
But, here comes the problem. The custom DMA and blitter DMA work on the A1200 memory space, not SharkPPC's. There is no way the system knows the data resulting from the blit should somehow be magically transferred back to SharkPPC!
This applies to other DMA, too. For example writing to a floppy would require the data to somehow be transferred to A1200 first, before the DMA begins.
I ignored several other problems to get this far (actual DMA):
- How can SharkPPC know the value of Custom registers that can be read only once? Reading once loses the status forever.
- How can interrupts be relayed?
- How can SharkPPC ensure the emulation and Amiga 1200 status remain synced?
Conclusion: SharkPPC cannot have access to Amiga custom registers.
