Since one of my VMUs died, I've been interested in the possibility of using alternatives to VMUs as memory card for the Dreamcast, as a challenge and also thinking about the availability of new ones as the system grow old. I did some research on the subject and, while it may be of knowledge of some here, I think it can be useful to others and to make a registry of my findings.
I started to look for information about how the Maple protocol works and there is some classic sites (http://mc.pp.se/dc/ and http://www.maushammer.com) that talk about it, or explaining the Maple bus specifications or commenting on VMU->VMU connection. What i found odd is that there is very little information about how VMU and the controller comunicate with each other.
I've talked to Xerxes3rd on the Keep Dreaming Project discord and he sugested to look at the Maple patents. There i found very interesting information. At first in our conversation, Xerxes told me that it seems that the controller just manages the bus and when the VMU is aknowledge or transfer data to the Dreamcast, it just let the communication pass through and don't really interfere much. Later, looking at the patent, we found that this is true, but there is a key diference in how this is done compared to the normal maple comunication.
First, the patent calls the controller->VMU/acessory bus as LM Bus, i think some members may know this already, but searching this term in the internet give almost no results. In second and most important, the comunication is handled in a 4 wire basis instead of 2 as seen in the diagram below:
The controller seems to separate the usual SDCKA and SDCKB signals into a US and DS variants, later Xerxer pointed this must mean upstream and downstream. In other words, There are 2 wires just for receiving data and 2 just for transmitting, each respectively using normal Maple protocol. In the controller circuitry the incomming signal from the Dreamcast is separated in SDCKA_DS and SDCKB_DS and the VMU SDCKA_US and SDCKB_US transmission is later joined to the respective SDCKA and SDCKB wires again in the same circuitry to go to the Dreamcast, as seen in the diagram below:
There is also the SDCKA and SDCKB EN (enable) and the ID wires. ID2 seems to signal the controller that a periferal has been connected to that port (one of the two behind the DC controller) as it is pulled down on the controller circuitry diagram and is connected to VCC inside the VMU. ID0 and 1 I'm not really sure, may be a way to the controller to the the VMU to which port it is connected or for the controller to asign a device identifier to the VMU.
The enable signals were also kind of a mistery, they obviously control the bus someway, but I was not really sure how, then i read something very interesting in the end of http://www.maushammer.com VMU-VMU protocol page, which has some investigation on how the Dreamcast-VMU connection works:
"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)."
When this information was written I supose that the community really didn't knew exactly how the Maple bus worked (the last page update was in 2000), what he says in this paragraphs is exactly what the patent describes: pin 4 and 10 comunicates when Dreamcast transmits data (SDCKA_DS and SDCKB_DS), pin 5 and 11 comunicates when the VMU transmits (SDCKA_US and SDCKB_US) and most important, pin 3 and 12 go high when the VMU transmits data (SDCKA_EN and SDCKB_EN presumably, if this is correct HIGH activates transmission and LOW reception); There is in conjunction to this text a logic analyser image showing a Dreamcast->VMU transmission on the LM-BUS, and it is exactly what we now expect to be a Maple protocol tracing!
Last but not least, I opened one of my controllers just to see if the circuitry is implemented inside the controller MCU or in a discrete way, but as I suspected, all seem to be implemented inside the 315-6211 as the LM Bus pins are directly connected to some of its pins (tomorrow I may try to map some of them). Not the point of this post, but the 315-6211 could also be a target for research as there is absolutely no information about it on the internet from what I searched.
With this information should be possible to run some tests and maybe, if what i understood and wrote is correct, build periferals for the LM Bus. I'll try to do some more research and tests, but while I work with MCUs professinally, this doesn't mean that I have the needed knowledge or talent for creating time sensitive code the emulate the Maple protocol. So, if anyone wants to try from here, be my guest.
I hope this information is useful for somebody and helps the community someway, I hope that my post is not superfluous with already known information, but I think, from searching for this info again and again in the last month, that this is not the case.
Soniccd123
Sources and resources:
Maushammer VMU-VMU page: https://web.archive.org/web/20070620132 ... u2vmu.html
Marcus Comstedt Dreamcast Programing page: http://mc.pp.se/dc/
Maple Patent: https://ia600601.us.archive.org/34/item ... Patent.pdf
Arcade projects page about Naomi controller adapters: https://www.arcade-projects.com/threads ... .13/page-3
315-6183 pinout, A Naomi Chip that contains LM-Bus implementation: https://www.arcade-projects.com/attachm ... peg.10621/
