Getting back to it

It’s been another long stretch of silence. I’ll try to get back into the swing of making these entries.

Over the past month I’ve been working more and more on some hardware-related stuff. Bouncing around from one thing to the next to get started in earnest on the three hardware projects that I’m aiming to achieve sometime in the near-future. All of them are Dreamcast-related and I don’t know at all if I can achieve them but I’ll give it a good shot. These have been rolling around in the back of my mind for somewhere close to a decade. Pretty sure I’m also not the only one to have thought of them, too.

The hardware projects I have in mind are as follows:

• Fully-loaded controller. No idea if this is even possible from a power-consumption point of view, maybe if I make them wireless it would work. I’ve always wanted to create a controller that takes full advantage of what the Dreamcast can do. Both analogue sticks (with a digital click-in button), directional pad, six face buttons (A, B, C, X, Y, Z), two triggers, two bumpers, and a start and back button. The specification allows for sixteen buttons, two 2D analogue inputs, and two 1D analogue inputs. Alongside the full set of controller inputs, a built-in VMU (this would allow for a way thinner and back-lit unit) with 1MiB storage (the maximum allowed) and the ability to extract the save data for backup purposes. Built-in rumble for both sides of the controller, like modern controllers, and a microphone input jack. Power-wise, I’m very sceptical that this would be feasible, but it is a dream controller (no pun intended). The most difficult part of this project will be the case and button membranes. I plan to prototype it on a breadboard, moving onto a PCB and create a 3D printed topside shell for the official Dreamcast controller until I find a cheap way to get a plastic shell made. There’s resin casting that’s pretty cheap, but I don’t know anything about the durability or suitability. As I have a resin-based 3D printer, it gives me a feeling that it won’t be adequate, then again it is a different kind of resin.
• Maximum capacity VMU. A backlit, rechargable VMU with a directional pad, A and B buttons, Sleep and Mode buttons, and 1MiB storage capacity available and pageable. Similar to the one in the controller, it would be ideal to allow for the save games to be extracted and to easily allow for switching memory banks. Whether that would be via the VMU directly or not is something I haven’t figured out. Given the advances in chip technology over the past 23 years, I’d imagine a fairly large rechargable battery would be able to fit in there. At least more than a few days of Chao Adventure without needing to re-insert the battery disconnect tab. The biggest challenges for this would be both the Potato chip and recharging curcuit as well as the same issues for the controller with the case and button membrane.
• Modem/LAN/Storage expansion unit. Ever since getting up-and-running with a PC<->DC server many moons ago after switching over to a broadband connection and, before that, hearing about the Zip drive. I’ve wanted to make it really easy to not only play games online (both old and new) but also allow for what may be the worst mistake that modern console game development houses make: updates and additional/user-generated content. If the Zip drive came out, I think that, A, it would have been incredibly expensive or sold at a great loss and, B, it could have helped the Dreamcast reach its full potential as a truly online system. A huge problem with this project, and the previous two, is that the edge connector is non-standard and will have to be custom-made. Other than that, the biggest hurdle for this one is implemeting the necessary parts of the OSI and figuring out how the Dreamcast talks to the modem, LAN and broadband adapters. I’m very thankful to jj1odm for his about Dreamcast G2 bus page and Dan Potter’s reverse engineering efforts, otherwise it would be a whole bunch of guesswork and floundering around for months, most likely years. Of course, the game server DNS entries will have to be modified to point to their modern equivalents which I think would be best handled by allowing a zone file to be uploaded to the adapter. I’d like to have the adapter work in either modem, LAN and BBA, or auto-detect mode via a 3 position switch, though I’m not sure if it’s the best approach.

I apologise for the size of those three supposed bullet points, but this is something I’ve been wanting to discuss for a long time. Until recently, I didn’t want to mention anything of it in detail as I don’t know how far I’ll get. In any case, all of them will be open source hardware endeavours, so if I fail miserably at least the next person will be able to pick up the pieces or someone will pity me and help out when I clearly don’t have a clue what I’m doing. It will most likely be much later this year before I have anything worth discussing. All three of them have their sticking points. The expansion port adapter is the one I’m thinking will be the “simplest” in terms of manufacturing but most difficult in terms of reverse engineering. The controller is the simplest as the Maple bus is well documented and easy to handle, but there is the power requirement that I haven’t investigated. The VMU will probably be the most fun as it’s effectively a mini console but the most hassle due to the battery and Potato chip. With any luck, I’ll have a very messy controller on a bunch of breadboards and a modem<->LAN interface done before the year is out.

On Shambler, I’ve started to get back to the networking and building in diagnostic information for the test version. Mainly for verification of how much memory is available to use as well as a call stack printout in case (rather, when) things go awry. I came upon a very nice little bug that took about two days to locate and squash. Stupidly, calling the array’s ARY_IsFull function was checking against the item count rather than the actual size consumed by the array. This was due to the capacity being set to the item size. Very dumb. At first, I thought it was an issue with the memory manager because I do not trust that I’ve written it correctly and the memory looked to be getting corrupted after an allocation. This was a right and wrong assessment. I hadn’t come across the issue before because I’ve never hit the limit of an array. Testing is something that I need to improve on heavily. It was occurring in the test network game state when sending a packet to verify if the master server is available. It does this at a rate of three times a second. The stack can hold 20 packets before it starts to reject them. Or should have if I programmed it right from the start.

Networking-wise, I think I said that I needed to re-write the code last time. There’s no reliable packet sending and the whole infrastructure is just a mess. It’s a classic case of being way too excited to get something working than to get something working well. Also, as I haven’t done much socket programming in recent times, I got ahead of myself and just wanted to make sure the the Dreamcasts could talk to one another. The code is all broken from when I switched over to the new workstation and started focusing on the original milestone of a basic renderer. I still want to return to that as soon as possible. For now I’m going to try and fix up the networking side of things to create a cleaner codebase, attempt to speed things up, and make them more reliable where necessary.