Hey,

One slight mystery that I had never really taken the time to look into was the sync pins (pins 5 and 6) on the link port. Many years ago, I had noticed strange behavior when crossing them, so I (naively) decided to connect 6 to 6 and leave 5 alone (which worked fine). It always kinda bothered me though, because I didn’t think that was right (I didn’t think pin 6 was bi-directional).

Does anyone know where the diagram on the wiki came from: http://www.planetvb.com/modules/dokuwiki/doku.php?id=link_port ? If anyone has tried that connection, they’ve probably noticed that both VBs stop working and the mirrors never seem to sync.

When I had put some thought into it, my theory was that the correct way was probably to connect pin 6 on one side to pin 5 on the other side, but not crossing 5 to 6 the other way.

The reason for this is that pin 6 is the 50Hz output driven by the mirror oscillation (technically FCLK, I think), and pin 5 goes to the servo board, which controls the mirrors. So without an external reference on pin 5, the VB mirrors free run… but if you feed it a 50Hz signal, it locks the onto that. But if they’re both trying to lock to each other, of course that’s gonna create bad feedback… causing the wonky mirror action. By only syncing one way, there becomes a mirror “master” and “slave”, though obviously it doesn’t matter which is which, since the point is that they both become the same. And this is completely independent of the master/slave for serial link communication.

And you don’t need the mirrors synced for the link to work, but with the mirrors synced between the two systems, the frame clocks will be synced… which will let you sync the game clocks, etc.

So, anyway… I finally got around to verifying this with the scope, and it seems like that’s the correct way. Does anyone disagree with this?

All these pics are of the FCLK signal from 2 systems running continuously (connecting/disconnecting pins 5 and 6 while running).

System 1 and System 2 free running:

System 1 pin 6 connected to System 2 pin 5:

Pins 5 and 6 crossed between both systems (this is just one of the strange artifacts of it going in and out of sync)

System 1 pin 5 connected to System 2 pin 6:

System 1 and System 2 free running again (note that they became unsynced):

Thoughts?

DogP

Attachments:

1. 

   dsc01891.jpg
   

2. 

   dsc01892.jpg
   

3. 

   dsc01893.jpg
   

4. 

   dsc01894.jpg
   

5. 

   dsc01895.jpg
   

EDIT: Dodgamnit, PVB, do you HAVE to shrink images? Fother mucking shiece of pit… *Grumbles*

DogP wrote:

Does anyone disagree with this?

I think your oscilloscope output pretty much precludes anyone’s suppositions. (-:

Yes, it makes sense that the systems be synchronized. With one machine being clocked by the other, it guarantees that frames are the same length and that frames begin and end at the same time. This is important when two systems are interacting with each other.

Here’s the diagram mentioned in the previous post:

The goof here is that pins 5 and 6 can’t both be connected, because then both systems would try to synchronize against each other, and you’ll end up with exactly what DogP’s graph indicates: you get a constant high signal that feeds back into the machine that first generated it and then nobody gets a clock signal.

Here’s what the other pins mean:

Pin 1 Control – I believe this is the “COMCNT” line, which is a 1-bit line that can be set or cleared by either device. Help me out here DogP, because I was never clear on its purpose: isn’t communication controlled automatically when the master system sets C-Start in CCR?

Pin 2 +5V – Just as it says: a five-volt DC line. This is not connected between systems (as both systems generate voltage on this line), but can be useful if any non-Virtual Boy device were to be connected. The Game Boy Printer comes to mind.

Pin 3 Clock – This is depicted traveling in only one direction. This pin corresponds with the “COMCLK” signal and is only sent on the master system. The slave system receives this clock signal and uses it to synchronize communication transfers. Programs have to decide for themselves whether the device should be transmitting the clock signal or listening for it. Perhaps that’s where pin 1 comes in handy, but I’m still foggy on that. The only alternative I can think of is a UI menu along the lines of “Host a new game” versus “Connect to a host”

Pins 4/8 Data In/Out – What it says on the tin

Pins 5/6 Synch In/Out – Also what it says on the tin. As per DogP’s experiments, one of these pairs should be left open.

Pin 7 GND – Ground

A revised diagram is as follows:

So what do you think, DogP, is this consistent with what you know about the COM port?

Attachments:

1. 

   linkport_bad_zps324c8ff4.png
   

2. 

   linkport_better_zps90e6ea39.png
   

Yep… that pretty much sums it up.

The COMCNT pin is open drain, which basically means either side can drive it low, but neither can drive it high (it’s internally pulled up, so if nobody is driving it low, it’s read as high). This gives a simple 1-bit bi-directional communication channel for anyone to use.

There are a lot of uses for it, but essentially it’s for any sort of “out of band” signaling. This could be used to determine who’s master/slave, tell the system that another VB has been plugged in, signal that someone is starting a game, acknowledge receipt of a message, etc. Since the regular link communication is synchronous, with a master/slave… things like that are a little bit tougher, especially before the master/slave relationship has been established (unlike an asynchronous system like RS232, where either side can independently talk at any time).

But yes… the pin isn’t needed for the standard link connection… it’s just an extra general purpose pin. They called it COMCNT, probably because they expected it to be used for controlling communications between the systems. But I’ve used it as a simple on/off to control a rumble pack (though there are much better ways to do that). It’s also convenient to use as a slave select, since the serial protocol is essentially SPI… so you could (slowly) talk to SD cards, or any of the MANY other SPI devices out there.

DogP

Oh, and not that anyone would actually want to do this… but connecting pins 5 and 6 on the same VB also causes the same effect as connecting 5 and 6 between both systems.

Something that’d be interesting would be to drive this with an external clock at higher/lower speeds, and essentially speed up/slow down the games (and make it narrow/wide screen :P). I dunno how far away from 50Hz this will lock, but it’d be interesting to find out (if my function generator wasn’t broken, I’d try it right now). The games might freak out if they’re constantly hitting overtime, but that’s part of the fun. 😉

DogP

since the serial protocol is essentially SPI…

SEEPROM memory card for game saves ?

MineStorm wrote:

since the serial protocol is essentially SPI…

SEEPROM memory card for game saves ?

Good one! I had the similar idea of using old PS1 memory cards on the port, since they (as well as PS1/2 controllers) use a similar “SPI-like” protocol.