This just sounds like straightforward multitap code to me.
Entirely possible that it is. But it appears to count the attached controllers, and elsewhere that controller count gets checked. For a 2.....But, I could be wrong.
And remember a link cable is not just a multitap (one-way pad communication)
That's the same mistake I made at first.
To read a pad, you write the port number and button set you want to the controller. IF there's only 1 pad connected, the pad will ignore the port information. The multitap, however, selects the port and passes the request on to the correct pad; hence it must have 2-way communication capabilities.
(I'm not 100% sure of that, though. I can think of a few ways to do the same thing that don't require that capability. But, as was pointed out to me earlier, the Devlo box does 2-way communication over the controller port. So I think it's safe to assume controllers and the multitap are 2-way, not 1-way)
One TE sends its player's position/movements to the second TE along the cable
Are you sure?
It seems equally likely to me that the link cable could just be acting as a convenient bridge between the two machines, just electrically connecting the multitap chips. So, when you want to read player 2's pad (on the other machine), the link cable just transfers the signals. And the multitap chip in the second machine responds (like a regular controller) with the status of port 1. (Since port 2 isn't active on the second machine).
No, I'm not positive about this, or any of the other link stuff. But it seems to me that that -is- a viable way to do the connection; it's also a cheap way of doing it. Nothing extra required: just add in the multitap chip, swap a few signals, and it works. At least in theory......
Though I do still think the signals have to be converted to and from a serial format somewhere along the line. There doesn't appear to be any other way to send 4 (or possibly 8 ) bits of information across 3 lines without it. But a simple shift-register would work, as one possibility....