Console design mutterings and feedback-seeking maybe.
I feel like it's been forever since I've given an update on this over here, but some time ago now, I rebranded to Wire Witch Violet around here and set these schematics as banners and profile pictures and whatnot, because my big background project I work on where I can for the past couple years, and probably for the next several as well is designing a game console, as some semi-open build it yourself as an electronics kit sorta deal, eventually. I've been starting with the controllers, which are... still facing some sticking points, but I'm at the point of actually prototyping board and case designs and stuff, so that's neat?
As you can see, a couple things are too close for comfort. That membrane is crossing into the space where a chip needs soldering on and into the well for the scroll wheel. There's also some... let's say typos on this particular PCB where holes got punched in some real bad places thanks to accidentally leaning on the spacebar in KiCAD before sending it off. But I just need to do a couple more revisions, work out just what the hell is up with the signals from the scroll wheel guts (documentation for these is... a bit lacking), get a spool of cable and crimpers and work out a way to hook this to an actual compatible console and/or an adapter so I can hook it to an emulator, and this step of things will be done.
The next step of course is... teaching myself to program in freaking machine code to make a test ROM for one of said compatible consoles and make some proof of concept demos for this, which will also probably take me some time, but after that I need to bite the bullet and finalize some design choices for the console itself. There's a lot involved in that, obviously, so let me start off with a quick overview of memory mapping. Incidentally I went way more in depth with this in my big series of posts on how a computer works. Basically though, the way a computer works is we've got a particular bundle of wires running through it that are connected to EVERYTHING, called the Data Bus, which is where all the information goes, and another bundle of wires, also connected to everything, called the Address Bus for managing where that information is actually going. Here's a really really simplified diagram. Feel free to skip sections here telling you stuff you already know.
Begin the technical explainer!
Here's a 2-bit address bus and an 8-bit data bus. Pretend there's 2 of the red lines and 8 of the green. We've got 4 addresses here. Let's say that's all actual physical switches in the top right, and we have a little 8-bit adder module with an address for each of the two numbers you want to add together, and one for the sum of those. All of these are just directly wired together. If we didn't have these address gates, if you flipped just the switch on the far right, the rightmost data line has a signal, so the whole thing goes to 00000001 + 00000001 = 00000001... except you know the adder is trying to actually add that 1 and 1 together and stick that into result (and really we'd probably have that read-only). And if we cut our little series of switches out, every time the clock let the adder do its thing, it'd be sending the total here back out onto the bus, where it goes right back and now it's 2+2 then 4+4 etc. If this is all hooked up to a string of LEDs, and the clock's real slow, that'd make a neat little light pulse zoom to the left, but we probably don't want that, so we have these little gates to say "hey, let the information out on the databus overwrite what's in you or vice versa only when the address line has the password to your specific padlock in it, and you have a whole setup to open and close those in the right order to get the stuff you want into the right places at the right times.
Usually by the way, when we talk about something being like, an 8 bit console or whatever, we're talking about how many wires we have in the data bus. In my example here, we've got 8, so any given thing you want to move around or do stuff in has to fit in that. So like in the original Zelda you can have between 0 and 255 rupies, because if we're counting in binary and have 8 digits to work with, that's all we have to work with. 1+2+4+8+16+32+64+128 we can do as 11111111 in binary, or, wires having a charge vs. not, but for 256 we'd need a 9th digit/wire.
There's no particular limit on how many wires we can use for these buses, beyond how much it gets to be a pain when you physically need to run them through a space and cross over each other and such, but in practice you end up with a lot of the same powers of 2 showing up. I'm showing an adder up there, but another very common little thing you might have in a computer is, say... open up the gate to some memory value we're storing and pop what's in it that onto the data bus next... so we need to pass the address along, as data, so OK how many addresses we have are functionally limited to whatever the biggest number our data bus can hold then isn't it (there actually are ways around this, trying to keep things simple though).
So what I'm getting at here is there's a finite number of places our computer can point to/look at/send stuff to.
Everything needs an address, and a lot of these are already going to be spoken for. The main computer part of a computer is the processor, which has a bunch of built in commands and some internal storage, and generally a lot of in-built functions like adding and subtracting and bla bla bla.
If all we have is the processor, we can slap memory chips in and point all the other addresses at those, and when we're making games, that's good, because games tend to have a whole lot of information to jot down in places and check later. But we of course don't have just the processor to worry about. We're gonna have some special sound chip in here, that's going to need a certain number of addresses pointed to it, we need to read the program in off the cart, maybe send stuff back that way, gotta handle the graphics etc. etc. etc. So consoles tend to have memory maps like these:
(Those are labeled in hexidecimal for those keeping score, where we count 0 1 2 3 4 5 6 7 8 9 A B C D E F, if we were going binary it'd be 4 times the digits.)
And of course I also need to account for how many controller ports are going to be on this thing, maybe need a little memory reserved for solving my scroll wheel woes, and I kinda want to throw some extra addresses back to the carts, and I'm on the fence about dedicated a big block to a rom full of default text characters/a fancy start-up animation. ALL of this is to say, I don't want to go wasting a bunch of address space if I can help it.
So the point of this whole post, storage media!
This whole thing started with me wanting to make a new 16-bit system, natively outputting to modern TVs in 16:9 resolution, with whatever nifty features I can squeeze out thanks to improvements in off the shelf chips... which apparently includes a free 32-bit upgrade because people just aren't making 16-bit processors anymore apparently. One of the big big changes since the '90s when all my jumping off point consoles were in vogue is storage. Wow dang, we've got super cheap little flash memory cards these days that'll hold terabytes. You can easily fit every game ever made up until what, 10 or 15 years ago maybe crammed onto one of these things, and it's probably a much more reasonable solution than insisting everything go onto EEPROMs inside the carts.
So one very reasonable option would be to design a little SD card slot or whatever into this thing and just assume everyone is going to have all their games stored on one of those, just popping it out, popping it into a PC or a phone or something, grabbing new games off itch.io or something, popping it back in, and then picking what you want to play through some little in-build game browser.
I am absolute not doing that.
Partly, this is because I don't want to waste my precious addressing space on a bunch of BIOS/firmware/UI stuff. Partly, this is an aesthetic thing. This is an old school console, you palm slam big solid carts into the slot on top of it. It's physically satisfying. I'm planning an official emulator for people who can't be bothered, but with the physical thing, we are using carts. And as an addendum to that, part of the reason we're using carts is a cartridge is not just a data storage medium. I actively want to encourage people throwing all sorts of weird things into these carts. Fancy custom chips, built in secondary monitors, pass-through nonsense (& Knuckles style), cram in extra accessories, sky's the limit.
Also, I honestly just kinda want to avoid onboard storage on the console itself as a matter of principle. I'm making a new-old console to encourage new-old game design. You let people know there is dedicated storage space on a console, they are going to start throwing stuff in there. Patches and DLC and installed files cluttering up the whole place, and nah, I'm not for that. Keep everything for your game in the cart for your game.
That said, it's rare for anyone to want to make a game without any long-term saving. So taking internal storage off the table, that means either A- Every individual game needs to sort that out on their own and either do some kind of internal battery-backed storage or include entirely too much flash memory. OR B- Maybe I do an official pass-through cart that has some storage and a general UI for playing with it, and maybe some other fun little bonuses. Wifi maybe? Some extra RAM? So if you want to do, say, an RPG, we plug you into the pass-through cart, you can save there like it's a memory card. Meanwhile if you're doing something more arcadey, you don't bother and have the extra addressing space to work with elsewhere in the cart.
Also to be clear, I do plan to provide standard PCB/shell designs both for having simple socketed swappable ROM chips and like an on-cart SD card or whatever, because there's obvious use cases there both for testing/prototyping and wanting some kind of Everdrive style option for games that aren't doing anything fancy.
And while it's less pressing than this long-term data storage issue, I'm not planning to support any sort of optical drive with this. The storage on a disc is kinda irrelevant next to flash memory, and there's enough of a DIY factor with this I'd rather spare people the pain of buying and connecting some pricey motor and laser assembly.
But yeah... any thoughts?
