It has occured that the Q2000 (QZar) network protocol could be usefully employed here. It is designed to send broadcast and addressed data on a multidrop RS232-ish network, with polling to pick up data from clients.
I think it would be better to run multidrop than to require every peripheral to have two independent ports.

I have no idea how that might work. Do you have any references where I could find more about that protocol? Also, I have no problem understanding how one unit might send to multiple units, but the other way (many possible senders, one recipient) is not that easy to do, I guess. Furthermore, though multiple ports are not that easy to handle, my idea would allow different external units to communicate with each other, which I can´t see a RS232-like multidrop link being able to do. Hmmm, it would require each unit to listen to its own output (as it is on the same line as anybody else´s output). Another problem is collision detection, a problem one does not have with multiport, store and forward protocols. Each approach would have its specific advantages and disadvantages. We just have to decide what to do. My approach would mean however, that we do not need any converter box on the outside of the empeg unit, which is likely to be a requirement for the Q2000 (QZAR) approach (along with the software upgrade). On the other hand, the Q2000 approach is likely to be easier to implement on the (external box´s) hardware side.
Anyway, electronics is not my primary business, so I don´t have much knowledge which approach is cheaper and/or easier to implement (regards to hardware). I´m pretty sure that my primary application (attaching a GPS as well as some car monitoring) is hard to implement using my approach, because the GPS itself sends data with 4800bps, which is exactly the default speed of the empeg, leaving no room for other applications. Second problem: the link box to connect the GPS with the empeg would have to have 3 RS232 ports: empeg side, other extensions, GPS. Not too much of a problem using a 16C554 or something like that, except for the cost and size of it.
I guess this thread is going to be long and going in depth on both hard- and software. To get something going, I think we should try to split it up into two major parts:

1. Link level communication (hard- and software)


2. application level communication (software only)

Skipping most of the link level communication for now (I don´t have enough background on that), here are my thoughts:
The link level communication should simply deliver a packet from one unit (empeg or not) to another, specified unit (empeg or not), regardless of the packet´s contents. So we would basically have something like this:
<LL sender><LL recipient><application level packet>
I currently have no idea how one can find out where to send it (the application has to know where to send the packet), especially on a multidrop bus. But for the moment, let´s assume the app has a way to know. Now the application level packet would be something like this:
<sender id><receipient id><packetnr><command><length><data><CRC>
where "answer" (resp. its numerical representation) is a special command to reply to other commands. This whole protocol is pretty generic so far, and not really thought about that much, I just wrote down what came to mind. Hopefully at least someone else is able to make sense of it, and develop something working from it. I´m going to bed now (1:10am here).


cu,
sven