Bit banging the Dreamcast Controller

The Sega Dreamcast uses a proprietary digital protocol called the “Maple Bus”. It is a unique two-wire bi-directional signal where each data line alternates between taking the task of data and clock every other bit — woah.

When using common protocols like UART, I2C, SPI, etc these protocols are handled in hardware circuitry built inside the microcontrollers usually. Then the C code simply refers to the transmit / receive buffers along with the flags. This is ideal since the code does not have to be stalled during transmission and can focus on more pressing tasks.

However, the Maple bus is proprietary so you won’t find any microcontroller with a hardware Maple peripheral. You could use an FPGA, but I chose to use a microcontroller instead. Thus bit banging is required, where the protocol is implemented in software.

A Maple transmission is begun by a starting sequence to initiate the transmission. Both data lines start at the high position, data 1 is pulled low and remains low. Then data 2 is pulsed 4 times and holds high. Then data 1 goes high and data 2 is pulled low again. Data 1 is high and data 2 is low, this is how each 2-bit phase begins.

maple1.png

Here is the starting sequence captured by a logic analyzer.

A byte is transmitted in 4 2-bit phases. Phase 1: Data 1 is high, data 2 is low. Data 2 transitions to the level of the bit to be transmitted. Data 1 then pulls low and the bit is clocked in. Then data 1 transitions to the next bit and data 2 is pulled low, clocking in the bit. The phase is complete and it starts over again. Since data is always clocked in on the opposite data line of a falling edge, we really don’t need to keep track of the phases after the starting sequence, we just need to look for the falling edges.

maple2.png

Example: “0b00011100”.

Since data is transmitted at 1MB/S, I will need to choose a fast microcontroller that will be able to accurately sample the bits. I went with the PIC32MZ as I had some prior experience with that microcontroller for another project. The PIC32 can have a maximum CPU clock of 200MHz, estimating that an instruction can be executed on each clock (which isn’t always true), then I will be left with 200 instructions to sample each bit — even with my poor amateur code, it should be do-able!

dc.jpg

The custom controller PCB I designed with the PIC32 and some additional hardware to be used later for the VMU emulation like the FRAM chip and OLED screen.

First I implement the transmitting code.

maple3.png

The maple_delay() function will be used for timing throughout the rest of the code. This is pretty easy so far, setting the data lines high and low to match the original controller.

maple4.png

Sending one byte of data meticulously through the phases.

maple5

Finally the basic bit functions can be sorted together to send an entire word (4 bytes)!

With the transmitting done and out of the way, time to figure out how the heck I will handle receiving bits. I can’t just sample the data lines forever in a loop because the microcontroller needs to handle other tasks like sampling the controller buttons, joystick ADC, and formulating the response packet.

After trying several methods out, the way it worked reliably enough was to capture the starting sequence using an interrupt flagged from the falling edges of the data lines. When the starting sequence is matched to be true, it disables the interrupt and samples the bits in a loop until the entire word is received. I’m not too happy about this method because it is limiting and the CPU is stalled during the entire receiving transmission. It is also very memory hungry, needing to sample each falling edge and then package the data into the bytes they belong afterwards. But I digress, it works reliably enough for a playable controller. There’s nothing ideal or perfect about bit banging a protocol in software anyway.

maple6

With the protocol implemented, the controller commands can be sampled and responded with the correct packet response. I only have two commands implemented for basic functionality controller. The other commands are for VMU which is currently not implemented at all, I will need a more robust receiving protocol before I tackle that since many more words will need to be accurately sampled one after another.

The software has a ways to go, but I’m pleased that I was able to get it working this far. I certainly learned a lot through this project.

https://github.com/Gmanmodz/Dreamcast-Controller-Emulator

The Dreamcast controller emulator can be seen in action on my latest portable, the 2DC!

 

 

WiiBoy rev3 – it’s finished

The WiiBoy rev3 has reached a very stable point where I’m happy to call it finished. Casting the case turned out to be difficult and I’m not ready for it so the case was professionally printed by Shapeways with their nylon powder services. The finish has some printed artifacts (much less than standard PLA FDM) but it is incredibly soft and smooth.

20190502_183621.jpg

The internals are my best. The use of 7 custom pcbs greatly eliminates a lot of wiring. Although I spent months designing the case and pcbs, the assembly is very quick now.

20190501_071300

Some may criticize the standard Wii trim and how I could’ve fit more batteries, but I love the neatness and cleanliness of the wiring. Also using 2 battery cells allowed me to design better shoulder buttons which is a challenge to pull off on a portrait style handheld.

20190527_144601.jpg

The USB-C features are still my favorite part. The pcb turned out to be pretty universal and I’m reusing the USB-C assets in other projects now.

Maybe later this year after GC+ 2.0 is released, I’ll certainly be redesigning the controller pcb for a WiiBoy rev4. I can try to push the custom pcbs to be even more integrated by reducing the number of pcbs and using some FFC cables for the inter-connections. But for now I’ll focus on other projects like the summer portablizing competition.

 

Wii PMS for sale!

20190417_091005.jpg

After making my Wii PMS project open source on github, I was humbled by all the emails from people asking to buy it even though they had the resources to build it themselves, you guys rock. It is now for sale on the BitBuilt store. https://store.bitbuilt.net/wii-power-management-system-pre-order/

The first batch is of 15 units, we will be gauging the demand and make more if the interest is there. Buy them while stock lasts! Each one is fully assembled, programmed, and tested for all 5 regulators (1v, 1.15v, 1.8v, 3.3v, and 5v) and includes the thermistor for thermal protection.

 

The WiiVision

The WiiVision is a tribute to one of my favorite Gamecube portables, the Envision, made by Jonathon Shine in 2011.

envision

Just so happens that the Envision was a tribute to one of his favorite N64 portables, The Sixty Free Lite-R made in 2009 by Sifuf.

sixtyfreemain

The WiiVision was a collaboration with one of my buddies Shank. We started the project in 2017 but abandoned it for a while as we moved on to other projects. In January this year, I went down to Texas for a week to visit Shank and we planned to finish 2 WiiVisions. We didn’t finish either of them but we got close and finished it soon after I got back.

20190108_081007

The build uses mostly off the shelf components so it’s simple to put together.

20190104_233622

It uses my new Wii PMS pcb which I recently made open source.

The WiiVision is a solid portable. The use of original analog triggers is not something we often see in projects anymore but it is so worth it. I’m now working on a second WiiVision on commission. It’ll be almost the same but with some small improvements like using Joycon joysticks and a WiiHUD audio amplifier. It should be complete in a few weeks.

 

Wii Power Management System is now Open Source!

20190102_154619.jpg

https://github.com/Gmanmodz/Wii-Power-Management-System

My Wii PMS pcb files, code, and bill of materials is now available to download for free on my github! This is an all-in-one system for battery charging, battery protection, Wii custom regulators, and more. The parts can be ordered from digikey for just under $30 and the 4layer pcb can be acquired cheaply from JLCpcb, OSHpark, and others.

Portablizing has been plagued for years from inefficient buck regulators, expensive smart lithium-ion chargers, and poor quality Chinese battery charging pcbs. This pcb will solve many problems we faced previously while also having a more integrated user-interface.

Features:

4 buck regulators – 1v, 1.15v, 1.8v, and 3.3v
1 boost regulator – 5v
Battery management IC – seamless play and charge and battery protection
PIC microcontroller for enabling the regulators, programming the battery IC registers, reading battery statuses, thermal protection, and other tasks

Interface:
hold down button for around 1 second to turn on and off. Tap button shortly to cycle through the led modes:
1. leds off
2. RGB fade
3. Battery monitor
4. Shipping mode (when it is turned off in this mode, it cannot be turned on until you plug in a charger)

It’s not perfect by any means but it is stable and has already been installed working in 3 portables. I would like to thank Aurelio for the answers to many questions I had over the past 2 years I’ve worked on this and also for the inspiration from his Powermii. I’d also like to thank Shank for helping me test it further on the Wiivision project.

USB-C PD DEEP DIVE

USB-C charging in portables is just awesome, though it is a bit more involved than traditional charging methods. I’ll walk you through how you too can enjoy this awesome feature.

The STUSB4500 is a nice little IC for power-delivery negotiation. It requires few additional components to get working and it runs autonomously with little software intervention on our part. This chip is ideal for a battery powered, space limited, portable application.

Note: USB-C PD only negotiates a higher VBUS voltage, it can not be used to directly charge the batteries, you will also need a lithium-ion smart charging circuit.

stusb4500

This application schematic provides everything you need to get the chip started. If we want an internal usb drive accessible over the USB-C port, we’ll need to do some more work.

  1. USB-C PD can source up to 20V on VBUS, we’ll need a VBUS to 5V step-down regulator for powering the USB drive. Make sure the buck regulator can do 100% PWM in case the VBUS is only negotiated to 5V.
  2. A USB 2.0 data multiplexer for switching the USB drive data lines between the Wii and the USB cable. You might need a small linear regulator for powering this IC so the data lines can still be switched when the portable is turned off.
  3. A power multiplexer for switching power to the USB drive between the VBUS step-down, and the 5V regulator already in the Wii portable. This is required because the USB drive needs to be powered when the portable is off and when the USB cable is plugged in.

usb

Note: I chose to power the 3.3V LDO from the 5V power multiplexer so it will be powered when the portable is off (cable plugged in). If you’re confident that the multiplexer can be put into a low power mode, then it might be possible to power it from our battery system voltage and skip the LDO entirely.

The VBUS step down converter I chose might have been a little overkill (it has a maximum input voltage of 36V!). If I redesign this schematic, I’d probably go with one that has a smaller PCB footprint. Though it proves to work fine.

pd

The layout can be condensed pretty small! I did make one minor mistake in this, the silkscreen for C10 is backwards, oops. I just have to remember that when I assemble it. Also the labels for the input pads aren’t exactly correct, the pad labeled 3v3 actually needs to go to the battery system voltage. The IO core of the STUSB4500 needs to share the same I2C voltage as our microcontroller. Lastly “S”, the multiplexer select is chosen to be wired to any of our system voltage regulators so that way the USB drive is always connected to the Wii when the portable is turned on.

This PCB will work as is, that is if you are fine with negotiating to the maximum power the charger you plug in can provide. My battery charger can only accept an input voltage max of 14V, if we use a 20V USB charger, this will not do. We will need a microcontroller to program the Power Delivery Objects (PDO) through the I2C registers.

regstusb

Here are the necessary register addresses of the STUSB4500 taken from the datasheet. The values to set them are not so clear, but it is possible to figure it out by piecing it together from the example code they provide. I had some help from my buddy Aurelio, who guided me through setting the registers.

The key is that the PDO voltage and current are 10-bit parameters stored in 8-bit registers in little endian format.

stusbcode1

STUSB_Write(), is a function I wrote to condense the basic I2C commands for setting the STUSB4500 to output either 12V, 9V, or 5V.

20190122_145437.jpg

It even works with the Nintendo Switch charger, Nice!

WiiBoy rev3 Progress

20190210_145143

To prepare for getting the casing casted, I thought it would be a good idea to build up a functional prototype for testing. I’m starting to feel the WiiBoy magic.

20190210_113543

Even though this model only uses 2 battery cells, there is not too much empty space. I even had to sand the USB drive down to fit.

20190210_121015

Using only 2 battery cells also has its advantage that the Wii doesn’t have to be trimmed so small, improving the reliability.

Notice the small bead and blue wire on the Wii? It’s a temp sensor probe. I added thermal protection in the firmware which shuts the console down if the temperature rises above 75C. It shouldn’t ever get close to that in normal conditions but in the situation where the console accidentally turns on in a bag (or during shipping), it’ll prevent it from melting down.

20190211_111224

But perhaps the greatest improvement from a small sacrifice of the battery size are the improved shoulder buttons. They are in the perfect spot when you hold it.

Well it looks like the WiiBoy is mostly done? Nope, this is just a thorough prototype. The real fun will begin soon..