Yet another Maple Bus emulator

[Tails86]

Hi all! I decided to make an account here since it seems some of my work may help others here.

I started diving into the Maple Bus protocol early 2022 after making a genesis emulation system for a friend with working controller ports (https://github.com/OrangeFox86/GenesisControllerUsbPico). As I was building that, I thought what would really be neat is if I interface with Dreamcast controller and all of its peripherals.

My wife had bought me a Salea as a gift just a few months prior, and this seemed like the perfect opportunity to start playing with this new tool. I first started with making a Maple Bus analyzer library for the Salea:
https://github.com/OrangeFox86/Maple-Bu ... e-Analyzer
(Sources I used to develop this are at the bottom of the README in that project)

I had also been getting into working with the RP2040 (Raspberry Pi Pico) at the time which has hardware suited for interfacing with any protocol you can think of. That ended up being serendipitous because I had no idea of what the PIO modules were when I started. The Pico is very accessible at only $4 USD which is perfect for open-source projects like this. That spawned this project:
https://github.com/OrangeFox86/Dreamcas ... lerUsbPico

The main goal of this project is to be able to emulate 4 controller interfaces with all VMU and jump pack capabilities. A secondary goal is to document the Maple Bus protocol in the README. The project is still under development, but I'm satisfied with the Maple Bus stack and scheduler as they are currently implemented. It's written in C++ since I feel object-oriented programming keeps me the most organized, and there is a lot of memory and processing power to work with on the Pico anyway. I do some things that would concern some embedded developers like use std::vectors without limiting their capacity and use std::shared_ptr to allocate memory on the heap (Yes, that feels forbidden to me too as I am an embedded software engineer for safety-critical systems by trade, but damn the torpedoes!) I've done my best to make it as loosely coupled as possible. It's organized in a way so you can strip out USB and main then do other things with it on an RP2040. It's licensed under MIT which has very loose requirements. The only thing that is "private" is the use of VID/PID values in the USB descriptor which I was granted permission to use from https://pid.codes. There is really nothing I can do to stop someone else from reusing those values though.

What's mainly left to work on is src/hal/Usb. I have 4 HID gamepads which interface with controller peripherals and a read-only mass storage device which can interface with memory units. I will implement write access to the memory units at some point, but that part is a lower priority item at the moment. I have little idea of how I'd like to interface the VMU screen to USB yet. That will most likely require a driver, and then I'd have to go nag the folks at Redream to give me something to hook into. I'm not even sure who I can talk to for that - any help would be appreciated if anyone knows.

Some demo videos:
https://youtu.be/tD_OHZ76U-I
https://youtu.be/V_kegrv6tz0

[Falco Girgis]

Fantastic! I have seriously wanted something like this for a very long time!

If/when you do get a VMU serial->USB connection, please talk to me about integrating at very least save-file functionality with the ElysianVMU emulator.

I could also pretty easily forward any screen display, filesystem access, and VMU sound effect playback to the actual device for testing.

[Tails86]

Oh yeah, definitely! Being able to point to a tool that would properly parse/modify portions of the VMU files was in the back of my mind.

Do you have information on what kind of packet to send the VMU to play sounds? I hadn't even thought about that.

EDIT:
Come to think of it, it may not be a bad idea to just expose raw communication to the bus through a USB CDC (serial) device, at least as an optional feature

[Tails86]

Ooooh! Is the buzzer the "timer" functionality of the VMU? I have a stub for that, and I didn't really know what to do with it.

[Falco Girgis]

Ooooh! Is the buzzer the "timer" functionality of the VMU? I have a stub for that, and I didn't really know what to do with it.

Yep, exactly! Funnily enough it also includes date/time PLUS buttons. Yeah, the VMU buttons are actually made available via Maple when plugged into the controller. That's why I bought this controller. https://pbs.twimg.com/media/Fee7BqNXgAI ... name=large

Never tested, but should work.

EDIT:
Come to think of it, it may not be a bad idea to just expose raw communication to the bus through a USB CDC (serial) device, at least as an optional feature

Man, if you think you could do that, that would be amazing. All I've ever wanted was for something like that. It would open a lot of possibilities for interfacing with emulators or for games.

it would allow you to pass-through everything to an emulator. Then it would allow you to interface with VMU file managers like ElysianVMU. Finally homebrew like Elysian Shadows could allow the PC versions to still support Dreamcast controls and peripherals natively, and even loading from the VMU.

I do some things that would concern some embedded developers like use std::vectors without limiting their capacity and use std::shared_ptr to allocate memory on the heap (Yes, that feels forbidden to me too as I am an embedded software engineer for safety-critical systems by trade, but damn the torpedoes!) I've done my best to make it as loosely coupled as possible.

LOL! I missed that the first time I read through your post. That's hilarious. I actually just got done writing my own containers and core library for my software stack in C (the higher portions of the stack are very OO C++), and I've done evil things like invent a whole OO type system in C, because I wanted that kind of architecture without even being in C++... and this is running on Dreamcast... so I know that feeling. It's not even just embedded people who frown on it, it seems like the entire world has suddenly lost their minds and decided that the OO paradigm is fundamentally evil... despite it being so prevalent and successful in large-scale commercial software. Oh well, I'm not one of the cool kids.

[Tails86]

Ooooh! Is the buzzer the "timer" functionality of the VMU? I have a stub for that, and I didn't really know what to do with it.

Yep, exactly! Funnily enough it also includes date/time PLUS buttons. Yeah, the VMU buttons are actually made available via Maple when plugged into the controller. That's why I bought this controller. https://pbs.twimg.com/media/Fee7BqNXgAI ... name=large

Never tested, but should work.

That is one weird controller. I feel like I need one too now. I see that Amazon sells them hmmmmm...

Man, if you think you could do that, that would be amazing. All I've ever wanted was for something like that. It would open a lot of possibilities for interfacing with emulators or for games.

it would allow you to pass-through everything to an emulator. Then it would allow you to interface with VMU file managers like ElysianVMU. Finally homebrew like Elysian Shadows could allow the PC versions to still support Dreamcast controls and peripherals natively, and even loading from the VMU.

That would be pretty easy to slap in there if you'd like something to play around with quickly. Doing so elegantly for a release will take a bit of time to think through though. I'll probably want to start it up with a menu of items to choose from. Serial devices feel so antiquated, but there is nothing as accessible as that.

I do some things that would concern some embedded developers like use std::vectors without limiting their capacity and use std::shared_ptr to allocate memory on the heap (Yes, that feels forbidden to me too as I am an embedded software engineer for safety-critical systems by trade, but damn the torpedoes!) I've done my best to make it as loosely coupled as possible.

LOL! I missed that the first time I read through your post. That's hilarious. I actually just got done writing my own containers and core library for my software stack in C (the higher portions of the stack are very OO C++), and I've done evil things like invent a whole OO type system in C, because I wanted that kind of architecture without even being in C++... and this is running on Dreamcast... so I know that feeling. It's not even just embedded people who frown on it, it seems like the entire world has suddenly lost their minds and decided that the OO paradigm is fundamentally evil... despite it being so prevalent and successful in large-scale commercial software. Oh well, I'm not one of the cool kids.

The point I was trying to make in that particular quote was that I have always been taught in embedded that we should never throw anything on the heap after initialization so that RAM usage never changes/fragments once things start running. I don't expect to use even half of the available RAM though, so I didn't see the point of spending time being that structured.

But I know exactly the type of engineer you're talking about! I've worked with them. Most of them are in their early 20's. I remember having the same sort of chip on my shoulder when I started out though, so I bite my tongue as best I can and give them the room they need to learn. Man, I've made so much messy code in my past and thought it was amazing until I needed things to scale. The main thing I want from any of my peers, apart from actually meeting requirements, is for diagrams that describe the architecture... and I don't mean a flowchart!

[Tails86]

Quick update: I've been updating the project so it may also emulate peripherals on a real Dreamcast. My latest release (V0.9) has some client mode implementations which emulate a controller and 128 KB of memory. I created volatile and non-volatile variants since the non-volatile variant requires that the program be copied to RAM before executing which limits how large the program can get. There is also a use-case I have been thinking of where a host PC could feed data into storage on the fly, so having non-volatile memory is unnecessary for that.

The controller emulation will currently just repeatedly send back all controls at their resting positions, but I plan on looking into supporting xinput controllers (xbox controllers) through the USB interface sometime in the future.

https://github.com/OrangeFox86/Dreamcas ... s/tag/v0.9

[CrazyIcecap]

any news so far?

[Tails86]

Not many real updates in the past year. I did demo it working with a PS4 controller to a real Dreamcast (much easier to implement than xinput). The host mode still works, but I never got the jump pack connected through USB.