The protcol used in VMU to VMU communication:

With this information it is possible to send and receive files from the VMU.
I myself have built a complex hardware using a AT90S8515 microcontroller
connected to a RS-232 port on a PC. The only purpose of the microcontroller
is to translate between the synchronous communication of the VMU to the
asynchronous communication on the PC side providing a reliable timing.

VMU Pinout:

1 Input: 1=activate external IO, 0=all pins are floating
2 Input: +5V Power from DC, turns off display and all keys
3 Output: CLK
4 Input: delayed DATA
5 Output: DATA
6 Input: Handshake, 1="waiting for data"
7 Output: GND
8 Output: GND
9 Output: Handshake always 1 ??
10 Input: DATA
11 Output: delayed DATA
12 Input: CLK
13 ?? ??
14 Output: +3.5V Power

Pin 2:
If feeding pin 2 with 3.5V there is only 2.8V on pin 14, so I think the VMU
needs 5V here, then there are 3.5V on pin 14, just like with batteries only.
If the VMU gets its power from pin 2 the display blanks and the keys don't
show any reaction, so I think the DC takes full control over the VMU, the
normal communication does not work anymore.

Pin 4,11:
The delayed data is produced by the receiving end, perhaps to check if
the data is correctly transmitted. This feature seems to be quite common in
synchronous data communication, the Atmel AVR AT90S8515 does use it, too.
In my experiments the communication works even if pins 4 and 11 are not
connected.

Pin 6:
If the VMU is in file mode and this pin is 1, it switches into "waiting for
data" mode.

All pins are in 3V logic, I don't know if the VMU is 5V tolerant, so better
use voltage converters on the VMU inputs.

The protocol:

The basic protocol is syncronous serial, MSB first, triggered on the 0-1 edge.
Timing is 64us low and 64 us high on the clock line. A delay between bytes
is not necessary.

The protocol is base on communication blocks. The format of the blocks is
start_of_block type_of_block data ... data end_of_block.

Start_of_block is a byte between 0x10 and 0x1f or 0x50. The length of data is
encoded into the start_of_block, if is is 0x10-0x1f the length is
start_of_byte-0x0f, if it is 0x50 the length is 128.

Type_of_block length end_of_block meaning
0x02 2 0xff filetype+size
0x06 12 0xff name in VMU
0x04 128 0x00 filecontents
0x08 1 0xff write into flash
0x03 12 0xff directory data offset 0x10

After receiving start_of_byte the VMU answers with 0xe0. After receiving
the end_of_block marker the VMU answers with 0x0c to continue to communication
or with 0x0a to abort the communication.

The order of blocks is important, wrong blocks are rejected with 0x0a, abort
communication.

Example communication sending a file to VMU

Pin6 -> 1, wait for Pin10 (DATA IN) = 0.

Send 0x11, wait for 0xe0.
Send 0x02.
Send filetype, 0xcc = minigame, 0x33 = saved file, see directory entry 0x00.
Send size in 512 byte blocks.
Send 0xff, wait for 0x0c.

Send 0x1b, wait for 0xe0.
Send 0x06.
Send 12 chars ASCII filename on VMU.
Send 0xff, wait for 0x0c.

While there are still bytes to send:

Send 0x50, wait for 0xe0.
Send 0x04.
Send 128 byte of file contents.
Send 0x00, wait for 0x0c.

Send 0x10, wait for 0xe0.
Send 0x08.
Send 0x00, meaning unknown.
Send 0xff, wait for 0x0c.

End while.

Send 0x1b, wait for 0xe0.
Send 0x03.
Send 12 bytes directory entry at offset 0x10: timestamp, filesize, header offset
Send 0xff, wait for 0x0c.

Send 0x10, wait for 0xe0.
Send 0x08.
Send 0x00, meaning unknown.
Send 0xff, wait for 0x0c.

Pin6 -> 0.

The file is now transferred.

WARNING:
It is very easy possible to produce inconsistencies in the internal VMU
structures. Make sure the filesize and header offset is correctly entered
in the 0x03 block. Only use the filetypes 0x33 and 0xcc in the 0x02 blocks,
using 0x00 results in loss of free blocks, using 0x01 results in unusable
VMU. All these problems should be correctable by reinitialising the VMU
in the DC.

Best regards, Soeren.