Soeren Gust <sgust@...> took my results and did a better
interpretation. I haven't worked on it in a while, so here's what he
wrote:



Hello John!

After finding your page about VMU development I decided to have a try
myself.
I got a VMU and started to play with the protocol using your page on the
01/21/00. I agree with the basic hardware protocol, synchronous serial,
MSB
first, triggered on the 0-1 edge. To translate this protocol into
something
more useful I used a AT90S8515 microcontroller from Atmel. This
microcontroller has a builtin UART which I use to communicate with the
PC.
There is also one synchronous serial port which I use to receive data
from
the VMU. Sending data to the VMU is done by hand, timed for 64us high
and
64 us low just like your page says. One of the things I want to know is
how
much time do I have to wait between bytes? Since I currently don't use
any
handshaking I lose bytes if I send them too fast. I think I lose them on
the UART receiver in the Atmel.
There is also currently no way to switch the VMU into receive mode by
the PC,
so as an interface it is not yet usable. I prefer the microcontroller
solution
to the direct PC connection because of problems with reliable timing, I
mainly
use Linux on my PC.
I think I have figured out more about the protocol than you put on your
page,
but I could be completely wrong. How the communication ends is a
complete
mistery to me, could you please send me more info on that? I can send a
complete file, but then there are still 2 pixel on the progress bar,
look at
the end of this mail for an example.
I disagree with the meaning on some of the pins especially with the
direction
of the delayed data pins. The levels look like 3V logic, I don't know
if they
are 5V tolerant, I have put buffers in between them and the Atmel which
I use
which 5V because I don't know how much power I can get at 3.5V out of
the
VMU and I get already battery low warnings.

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: 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.

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

Communication:
The communication between VMUs seem to be block oriented. Legal start
block
markers seem to be 0x10-0x1f. They just seem to tell how many real data
bytes
are in the block, one more than the lower nibble. After sending the
start
marker the receiver answers with 0xe0. The next byte contains the type
of the
data, 02=filetype+size, 06=name, 04=data, 08=???. Following are the
data
bytes. The last byte of every block can contain a new start marker, or
0x00/0xff which means that the sender expects an answer. Legal answers I
know are 0x0c meaning continue and 0x0a which means abort and start
again.
0x0a happens if the file is too big or there does already exist a file
with
the same name or the wrong type of block was received. A special start
marker
is 0x50, this means a blocksize of 128 bytes. 0x51-0x5f seem to have a
meaning,
too, but I don't know which. The order of blocks is important, the VMU
answers
0x0a if the block was received correctly, but was not the right type.

Example of communication how I understand it: A->B
A: 0x11 blocksize=2
B: 0xe0 recognized blockstart
A: 0x02 type:fileinfo
A: 0x03 filetype, 0x03=data, 0xcc=vmu game
A: 0x01 size in 512 byte blocks
A: 0xff End of block, waiting for answer
B: 0x0c OK, continue or 0x0a out of memory

A: 0x1b blocksize=12
B: 0xe0 recognized blockstart
A: 0x06 type:filename
A: 12 bytes filename
A: 0xff End of block, waiting for answer
B: 0x0c OK, continue or 0x0a file already there

start repeat 4 times

A: 0x50 blocksize=128
B: 0xe0 recognized blockstart
A: 0x04 type:data
A: 128 bytes data
A: 0x00 End of block, waiting for answer
B: 0x0c OK, continue

A: 0x10 blocksize=1
B: 0xe0 recognized blockstart
A: 0x08 type:?
A: 0x00 ?
A: 0xff End of block, waiting for answer
B: 0x0c OK, continue

end repeat 4 times

And now I am stuck, there are still 2 pixel displayed on the progress
bar,
perhaps the VMU is waiting for the timestamp? Sending any more blocks
leads
to 0x0a and back to "waiting for data". Just sending any bytes without
legal
block structure can even turn the VMU into sleep mode, or it can hang
completely ignoring any more commands. I only have one VMU and no DC
so I
don't have any files on VMU to send. I think I have to rent a DC and
save a
game on my VMU for future tests.

Best regards, Soeren.