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:

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.