update 3/7: I haven't done much with this for about 2 months now. Sören Gust has built a PC-VMU interface using an Atmel microprocessor. He also gives a better interpretation of the meaning of the bytes. Check it out at Sören Gust's website. I have been working through the BIOS code and haven't found any cool things to do outside of the basic protocol.

This is the latest portion that I've been working on.  I took a soldering iron to one of my VMUs and instrumented up the connector. I've finally gotten around to renting a dreamcast [Sidebar: Ok, call me a hardcore VMU fan. I don't have enough time to own a TV and I get my fill of games on my laptop, so I don't own a dreamcast. Unfortunately, the rental did not include the modem; I guess the people at the video store weren't quite prepared to walk people though dial-up connections, which is unfortunate because the modem is really neat] and have hooked it up to my company's logic analyzer (It's capable of 32 channels at 1 GHz and 96 more at 250 MHz, but somehow I don't think we'll need all that capability).

I have a lot of effort to go yet, but here's what I've learned so far:

There are 14 pins on the VMU. They are actually labeled on its internal PC board, so I'll keep the same convention. Looking from the back of the unit with the connector at the top, the pins are numbered (from left to right) 1 through 14. Pins 1 through 7 are on one half of the connector and pins 8 through 14 are on the other half. The connector is designed so that some of the pins engage before the others; these are marked with an asterisk below. The signal levels seem TTL-compatible (don't know of they are 5-volt tolerant), but I haven't measured them carefully.
 
 

pin	mates to	play default (w/ dc)	direction *=connects first	software port	vmu-vmu usage	DC-VMU usage
1	14	1	*		power in?  I think this is used by the dreamcast to power a VMU with a dead battery. I haven't looked at the schematic yet, so something else might be needed to build a battery eliminator (like a current regulating resistor perhaps?). I measured 3.28 volts.
2	13	1	*	P7.0	low=dreamcast not connected	high=dreamcast connected
3	12	0	out	P1.2	sync clock (rising edge active)	goes high during mem xfers
4	11	1	in	P1.1	sync data (must be delayed by 8 bits)	used for periodic data (async?)
5	10	1	out	P1.0	sync data	mem xfer data (idles high)
6	9	0		P7.3	handshaking?	?
7	8	-	*-		ground
8	7	-	*-		ground
9	6	1			handshaking? power out? -- Resets VMU if grounded	?
10	5	1	in	P1.4	sync data	used for periodic data (async?)
11	4	1	out	P1.3	sync data (must be delayed by 8 bits)	mem xfer data (idles low)
12	3	0	in	P1.5	sync clock (rising edge active)	goes high during mem xfers
13	2	0	*	P7.2	?	?
14	1	1	*out		power out of VMU (on all the time), measured 3.52 volts

The delayed data pins are inputs. When the first VMU sends out data, the second VMU will echo back the last character (using the clock that the first VMU provides). This is only checked by the VMU when it is sending data -- i.e. it will issue an error if it doesn't get back the data it sent.  Data is transferred most-signifcant-bit first.  It changes state on a falling clock and is latched on a rising clock. The two clocks (one for each pair of data lines) are about 7812.5 Hz -- 64uS low and 64 uS high -- and don't run continuously. The VMU seems to be tolerant of faster clocks -- I got away with 8 uS but not 2.3 -- but probably isn't tolerant of faster thoroughput (the VMU must still process an interupt for each character and this must complete before another one can be received).

Here's a VMU-VMU transfer sequence I've analyzed: (The file being sent is named "SONICADV_INT", the description is "MAIN_SAVE_FILE", the size is 10 blocks, and the date is 11/27/98)
 

out	in	purpose
$11		hello
	$e0	hi there
$02		i want to send you something
$33		file type=saved game ($CC=game program)
$0A		size 10 blocks (of 512 bytes each)
$ff		end-of-transmission
	$0c	yeah, go ahead
$1b		ok, I'll go ahead
	$e0	I said go ahead
$06		ok. Here's the file name:
12 chars		‘SONICADV_INT’
$ff		that's it
	$0e <or> $0a	I don't have that file. you can continue. <or> I already have filename (abort)
$04		here's the first data chunk
128 bytes		file data (note: different size chunk than listed above)
$00
	$c0	ok I got it
$10
	$e0
$08		flash it!
$00
$ff
	$0c	ok, I flashed it.
$50
	$e0	continue
$04		here's another data chunk
128 bytes		file data
<unfinished>		see soren's page...

I also have a more detailed, but ugly version of the above chart.
 
 

When connected, the dreamcast continuously talks with each vmu even if it isn't displaying graphics. This periodic communication is weird- it doesn't look clocked (as in vmu-vmu comms) and it doesn't look to asynchronous. It is hard to believe it is asynchronous because typically asynchronous data is sampled with an 8x or 16x clock, and I'm not sure if there is a clock this fast in the VMU. The data bits are at about 200kHz; the VMU has one 32kHz and one 600 kHz crystal. Alexander said that the VMU could run at 5 MHz when connected to the dreamcast (which is fast enough to sample the data), but I don't see how this clock is generated (originally I had assumed the clock came over the connector, but I didn't see it).  This data may be a modulation scheme that includes the clock in the data, like manchester encoding or the dot-dash of morse code. This data may also be a part of the Maple bus which isn't destined for the VMU, but for the controller instead.

When the dreamcast reads or writes to the VMU another format is used(!) Pins 3 and 12 go high and data is transfer on pins 5 and 11 (as opposed to pins 4 and 10 for the periodic communications).
 

back to my vmu page

last update: 5/7/00 - fixed a couple of missing/messed up bytes (sorry for misleading you Sören). Also added most of my original document, which didn't have the error and I should have posted in the first place.