Brainstorming a Modern Retro Console, Part 4

In which the author channels his inner mad scientist and lays out ideas for a modern, retro-built video game console, concluding with part 4: the rest of the system build.

By: TheHans255

4/20/2024

A few weeks ago, the work I've been doing with the MOS 6502 gave me some inspiration for a modern retro console design that uses the processor, much like the NES and other consoles of the 1980s. I thought: if I wanted to build something that would carry the same design ethos as those consoles, with retro processors and bespoke graphics and audio hardware, yet had the benefit of modern technology and wanted to build something that made more unique and capable games than those original consoles could, what would I build?

This post is the last of a four-part series. Part 1, Part 2, and Part 3 were about the CPU, GPU, and media respectively. This part will cover miscellaneous ideas for the rest of the system.

(And again, a disclaimer: I have not built or tested any of this. All of this comes from my knowledge of the 6502 and other electrical engineering that I have picked up passively over the years, and while I believe that these designs would work to the best of my knowledge, I provide no warranty on any of these designs' effectiveness or their safety in mission critical systems. If I ever get around to physically building these designs, I will update this article with my results.)

The Case

Now, we have to ask first: what would this thing look like sitting in your living room? Obviously that would depend on all the elements of the final build, but from what we've developed so far, we can probably draw some concept designs.

We can already start from the idea of using cartridges, which could range anywhere from the big bulky things the Nintendo and Sega consoles used to small, efficient designs. We do know that, since we'll be having multiple chips running at dozens of megahertz, we probably need at least a little bit of active cooling and thus room for a fan and air vents.

The Controller

Every good console needs a controller, so what would our controller be? Many years of iteration on controller design has given us a very standard layout: two analog sticks, a D-pad, four face buttons, two triggers on each side, two option buttons, a Home button, and maybe a few other beels and whistles. Most modern controllers also operate over USB. Since both of these factors are going to be too much for a 6502 processor to control, we will need a simpler, bespoke controller design.

Since our triangle rasterizer will give our console 3D support, however, we will still need one analog stick at minimum. An interesting "mad scientist" idea might be to allow either an analog stick or D-Pad to be slotted into the left side of the controller, with the right side containing the rest of the buttons.

However, we could also get away with just having a stick and a smaller number of face and trigger buttons, maybe even going as far as the one-stick, one-D-Pad, and several-button controller layout of the Sega Dreamcast.

Audio

The console is also going to need to output sound. Since we have our processors running at 14 MHz, it seems vaguely plausible that we have one processor simply output to a PCM sample stream - at a sample rate of 44,100 Hz, which is the same sample rate of an audio CD, a single processor in charge of audio would have approximately 317 cycles to output each sample. Of course, bringing that up to stereo sound means that two samples need to be produced in that time frame, leaving an average of only 158 cycles per sample for stereo compositions.

This is likely not enough for adequate calculations, and these retro consoles also usually carried a certain charm with their built-in, bespoke sound chips. Therefore, as much as is necessary to take load off the processor, in addition to a PCM stream, I would also add a few square wave and noise channels to serve as foundational instruments.

We do, however, have another resource, this time in the form of multiple processors. Multiple audio streams can easily be mixed simply by summing the samples together, so if each processor had access to audio output in its private memory, either through PCM or the wave generator channels, the audio output could simply mix all the audio streams into a final output - hence, allowing different processors to be in charge of different parts of the audio stream. It would probably be too much to expect each processor to be in charge of all the audio all the time, but you could, say, have one processor be in charge of the background music while other processors play game and UI sounds on top of it.

Networking

Finally, we may want to add some level of networking, in order to either allow multiple consoles to communicate with each other, or to allow the console to communicate with a computer or other device.

The standard option for a system like this is to include an interface for UART, a widely-used interface that allows devices to send two-way communications. We would likely have a dedicated RS-232 serial port for this, which can easily be connected to another console or adapted via USB to another device.

UART, however, only supports two-way communications, and needs to utilize a modem or other intermediary device for anything more complex. Fortunately, however, we do have another option: utilizing the Wiznet W5100, a chip that implements Ethernet and TCP/IP in hardware, we can also simply connect the console to other consoles, or to wider area networks, via Ethernet. This chip is already used in the Uthernet II card for the Apple II line, and could be used to enable a wide variety of networking situations, including cross-play with players on PC. (There are, of course, way more security implications to consider here, but since each game takes full control of the system, it can be much more careful about accepting and negotiating external connections. There is also the introduction of network lag to be aware of.)

That's it for now on my modern retro console design! Again, a lot of this is only theoretical, and things may end up working out differently in reality if I actually get around to building the design. However, a lot of these parts are interchangeable and can be used in different ways - for instance, the processor design can be used with a simple 16 KiB frame buffer, and the triangle rasterizer can be used with more conventional processor designs, or even implemented in software. The processor itself, as long as it follows the same clock and memory access rules as the 65C02, could also be changed out - for instance, a more practical console could easily be built out of the 65816, which supports a re-mappable zero page and stack. Hopefully this brought you inspiration for some of your own projects, or even just served as a nice trip down the ins and outs of hardware design.