To make things a bit more interesting, there are two different versions of the TSerialChip class (to be more precise, it is actually a protocol - I might explain the term protocol later, but it is also described in the DDK). The newer one (version 2.0) seems to override the older one completely, but it is also more complex. My original plan was to simply use the older one but that caused just some fancy crashes here and there.
Using the new verion of the TSerialChip protocol is unfortunately not so straightforward for various reasons. The most important one is that any implementation of the V2.0 protocol has to be provided with a so called capability. It tells that it does indeed support the new protocol via a static data field added by the ProtocolGen tool at compile time. The data to be set is declared in a macro in the C++ class declaration, but to figure out the actual syntax of that macro, a fun little exercise of reverse engineering the ProtocolGen tool on the Macintosh is needed. HexEdit is your friend in these situations and fortunately, the Apple engineers have used a string represenation of the grammar for ProtocolGen. So the capabilities macro goes into the class declaration without a trailing semicolon. Good to know.
The current hacked dummy TSerialChip implementation now already gets pretty far. On the way, we lost our friend the TLog class (a simple utility class by Paul Guyot that uses the NameServer for logging), probably due to some concurrency problems. But Hammer works nicely and it looks like the usual Instantate/Bind/Connect sequence works for this dummy implementation. A bit later, it crashes but that is not too scary. As opposed to the stuff I saw that was going on between the different layers of the comms system. Let’s hope that this is reentrant!