Mizapf threw up some good numbers in another thread about this, and I have been noodling on it ever since. Your numbers just add fuel my fire. Here is the thing about the synchronous requirements: it does not have to be real-time on both sides. The man-in-the-middle, so to speak, can do a lot of interpolating on what is happening on the other side. If the translator knows what is happening at a given time, it can reduce the data being transmitted down to a subset of signals related only to that particular transaction, then a good bit of information can be synthesized on the other end with potentially little to no lost time.
As a pseudo-example, we know that certain control lines have to be in certain states in order for data to be valid for a write. Those lines do not have to be sent, just a control code telling the PEB end that this is a valid write cycle with data. Other unrelated lines do not have to be sent at the same time. I do not expect timing to be much of an issue, but only experimentation will show.
As for audio, I would try a simple AMR codec to handle incoming audio from the PEB. A mid-quality setting (7.4kbps) should be sufficient to reproduce speech, and even a high quality setting is fairly low bandwidth (12.2kbps.)* Other sound sources, like from a SID card if it uses AUDIOIN, will probably need a better codec to be satisfactory; how many PEB cards send audio to the console, anyway?
Another nice thing about having smart translators at both ends is the ability to cache information. For instance, it is unnecessary and horribly redundant for a disk DSR to be shuttled across the connection every time the CPU executes it. Instead, why not load the entire DSR into the console side and feed it back locally when requested? Then the only information which needs to be sent down the pipe is drive commands and read/write data. Even if I/O timing to the disk controller is sensitive, I believe the ad-hoc compression of the interconnect by eliminating and synthesizing control lines could overcome timing differences.
Using a proprietary media layer to accomplish this has advantages and disadvantages over Ethernet. A big advantage is that we have full control in the communications method, including speed and protocol and packet overhead, as well as the small payload dilemma. An advantage of using Ethernet and IP is we have an established standard to build upon and doing so would make it possible to have multiple devices in a given network, easily operating in a one-to-one, one-to-many configuration. With a little work it might be possible to devise an arbitration system to allow a many-to-one or many-to-many configuration. A disadvantage to the proprietary media layer is the work required to implement such an animal. Some disadvantages to Ethernet and IP is packet and protocol overhead and cheap consumer equipment.
I have given some though to whether the protocol of choice should be UDP or TCP. Initially I thought UDP because of its simple nature and that in a local environment we should not experience packet loss, and it would address the small payload dilemma to some degree. But I have given more thought to TCP as it has built-in integrity checking and a connection can be made once and left open essentially forever, and re-establishing a lost connection should be fairly transparent to both ends. I also like the option of making them UPnP compliant.
* Audio could be sent down the pipe as out-of-band UDP. Though a quick read on AMR indicates that encoding is heavily licensed. Might need more research as I have on-hand at least three different free encoders capable of AMR output.
And perhaps one day if home Internet access reaches a reasonable reliability and speed, we can use a PEB across a VPN
AND! I just though of a couple more crazy ideas. There is nothing to stop us from using a proprietary protocol over Ethernet and IP: I used Scapy to put together a TCP-like protocol which might be perfect for sending words at a-time with integrity checking (more for ensuring sequencing and re-transmission.) And, say for a moment that Ethernet simply will not work: there are numerous other media layers we could use which would have hardware drivers available, already. Fiber, for instance, is not all that expensive. We could also find some esoteric media for embedded implementation.