Category: Project

Let us start off with the rant mentioned in the title. Whenever I think about making a retro computer or device of some sort, I immediately jump to 16-bit because that era is the most interesting one to me. Sadly, the 16-bit processors available on the market (or at least Mouser) are extremely annoying to design around.

Let’s start with the W65C816S, which was originally planned to be used in the Neutron. Annoying thing number #1: multiplexed pins. The 65816 has a 24-bit address bus and an 8-bit data bus, with a 16-bit internal architecture. However, the physical package only has 16 address pins. Where do the other 8 pins go? Why, they’re the data bits! Because for some god dang reason, Western Design Center decided that making the data bus sometimes be part of the address bus was a good idea (IT ISN’T). And that’s not taking into account annoying thing number #2: the interrupt vectors and handlers HAVE to be located in bank $00 (specifically, the vectors must be in the $00FF00 area). The stack is also restricted to bank $00. And this causes a dilemma: unless you’re willing to add a chip (or a feature to an existing chip) that copies the interrupt vectors and handlers from ROM into RAM on reset, you’re going to end up with a crazy memory map like the one in the Super Nintendo if you want to have a stack. So, TL;DR: The 65816 is annoying due to multiplexed address/data pins and the location the interrupt vectors and handlers have to be in.

Up next on the chopping block: The Z8000, or specifically the Z16C02 (being the only version that’s still on the market). For some reason, instead of just having SOME of the data pins act as address pins, THE ENTIRE ADDRESS BUS AND DATA BUS USE THE SAME GOD DANG PINS, WHAT WERE YOU THINKING ZILOG????? WHY DID YOU THINK THAT WAS A GOOD IDEA? AND WHY IS THE ONLY VERSION THAT’S STILL AVAILABLE THE ONE THAT CAN ONLY ACCESS 64K????

Finally we have the Motorola 68000. While Motorola isn’t producing it anymore, the semiconductor company that they spun off during the split, Freescale, does. Or should I say, DID, because NXP ate them. Luckily, NXP does make the chips available. Sadly, they’ve got too many variations. It is seriously confusing. I’d give you an image to demonstrate this, but WordPress is an unstable mess and I fear that trying to add an image will brick the site for another 5 minutes…

Okay… finally got that out of my system. Since there aren’t any easy-to-implement 16-bit processors on the market, I’m just going to start out with an 8-bit processor. The 6502 should do nicely. I do plan on returning to 16-bits once I can get my hands on an easy to implement processor, but for now the 6502 will be good enough.

I’ve also revised what exactly I’m making. I still want to make a retro console, but that doesn’t mean I can’t also make a retro computer. Or multiple of both of those. So, here’s my plan:

• I’ll make 2 8-bit computers:
  • A Desktop running at 8 MHz, called the Neutron Station (Model N8D)
  • A Handheld running at 2 MHz, called the Neutron Pad (Model N8P)
• I’ll make 2 8-bit consoles:
  • A stationary console running at 8 MHz, called the Neutron Box (Model N8C)
  • A handheld console running at 2 MHz, called the Neutron Mate (Model N8H)

Yep, 4 models. And 2 of those will need built-in screens. How fun :D. The computers will share one memory map (which will be similar to but not compatible with the Commander X16), while the consoles will use a different memory map (because they have to account for the cartridge). All of them will have the same audio and video chip, which is still called the AVC, or Audio/Video Controller. There will be 64K of Video RAM.

The desktop will have 4 expansion card slots. The handheld computer will have 1 expansion card slot.

As for the consoles, they will need cartridge slots. As for the memory map, it is halved, then halved, then halved again. It starts out with a 16 KiB internal RAM area, followed by 8 KiB MMIO, then a banked 8 KiB area for cartridge RAM (this is the same as High RAM in the computers). This is then followed by the cartridge 16 KiB Low ROM/Flash, which is banked similarly to the cartridge RAM (meaning you can have up to 4 MiB in here!). Finally, at the end of the memory map, is the 16 KiB of cartridge High ROM/Flash.

Okay, I said a lot in this post. And it’s the middle of the night, so I’m tired. I’ll see y’all later, I guess. Have an awesome day!

So. Remember that old project I made like one or two posts about? The Neutron retro microcomputer? Yeah, it’s not exactly a microcomputer anymore. I have changed my end goal. Now I want to make a 16-bit game console, something similar to a Super Nintendo or a Sega Genesis, but not compatible with either. What does this mean?

• The Neutron will still be using a W65C816S microprocessor, now with a target clock frequency of 8 MHz instead of the full 14 MHz.
• There will be one FPGA to handle both audio and video output.
• There will be one chip, either an FPGA or CPLD, to handle de-multiplexing the processor’s address and data lines (because Western Design Center thought making the data bus act as the most significant byte of the address bus sometimes was a good idea, even though it really isn’t and just complicates things).
• System RAM and Video RAM will be separated. Amounts are currently unknown.
• There will be at least one slot for an SD card, so you don’t have to deal with battery-backed Save RAM in the cartridges.
• There will be 4 controller ports. It is currently unknown what the controller ports will be, or what inputs the controllers will have.
• There will need to be a cartridge slot mapped to one half of the memory map (8 MB).
• Half of cartridge space (4 MB) will be banked using the same method (or a similar method) as used in the 8-Bit Guy’s Commander X16 project, for a total of 4 MB * 256 Banks = 1 GB in that one area. The other 4 MB area is static.
• There will be a parallel expansion port, because who knows what people will want to make.
• Audio/Video output is indeterminate at this stage. I’m hoping for something capable of both digital and analog output. Perhaps something based on DVI-I Single Link, which would be capable of both VGA and HDMI compatible video out, as well as some pins for analog audio out and (maybe) composite out.

If you decoded the title (and if you really did that instead of reading the permalink, you’re awesome), you’ll know what this post is about, at least generally. (Also, I was going to do binary, but I figured that would be too long).

Throughout computer history, we always needed a way to connect peripherals and stuff to our computers so we can do more stuff. Want to store your data? Connect up a cassette player, floppy drive, optical drive, (floptical drive??), or memory card reader. Want to print out that essay you just wrote? Connect a printer. You get the point, right? The thing is, there are many ways to connect things together.

Generally, there are two approaches towards connecting things to your computer: parallel (sending multiple bits at a time) and serial (sending one bit at a time). Then there are many different capabilities you can add onto that, such as daisy-chaining (think FireWire, or IEC/CBM bus; you connect one thing to your computer, then you connect something else to that thing and both can talk to the computer), multi-master (multiple computers on one bus), multi-slave (multiple peripherals on one bus), plug and play (you can rip the cable out of your computer and it won’t explode), etc.

For the Neutron, I think a daisy-chaining, multi-master, multi-slave serial connection would be useful, as such a connection could be used for multiplayer games and for sharing multiple peripherals between computers. The IEC bus almost fits our needs, with the only problem being that it does not support multiple computers on the same bus. I2C is also close, but still no cigar as it does not support daisy-chaining. So, we’ll have to modify one of them and/or combine them in some way. How to do that is beyond me at the moment.

I was watching Retro Game Mechanics Explained. It was a video about the Game Genie and how it’s codes worked. It was interesting.

I have a project I’ve been working on, at least in concept. It’s a computer based around the 65816 processor (I’m calling the computer the Neutron), and one of the things it will have is a cartridge port. These cartridges can be up to half a megabyte large without the need for banking hardware. So, I was thinking about how a Game Genie-like device could work for that project.

The 8-letter code entered (yes it had to be 8) would encode 1) a 24-bit address and 2) an 8 bit value. For the 24-bit address, the first 8 bits would tell which 64K bank was going to be accessed. Cartridge space runs from bank F4 to bank FB, so the first two letters would have to encode the hex digits F and 4-B.

As for the letters? It’s kind of simple. Here’s what I came up with:

• A = 0000
• Z = 0001
• B = 0010
• Y = 0011
• C = 0100
• X = 0101
• D = 0110
• W = 0111
• E = 1000
• V = 1001
• F = 1010
• U = 1011
• G = 1100
• T = 1101
• H = 1110
• S = 1111

Basically, the even numbers are assigned to A through H, while the odd numbers are assigned to Z through S. Simple!

Now for how those letters (and their assigned bits) are mapped to the address and value. For each set of 4 bits, we’ll say the first two will be represented by uppercase letters and the last two will be represented by lowercase letters. The 8 letters will be labeled A through H.

To map each letter’s bits to the address and value, take each pair of letters, say A and B, with bits AAaa and BBbb. The upper case bits (AA and BB) are unchanged. If the mapped address and value are below the bits for the letters, we’ll say that AA and BB go straight down. For the lower case bits, swap the pairs. You’ll end up with AAbb and BBaa. Do this for all other pairs of letters, with the addition that with every other pair of letters, invert the lowercase bits. (I.e CCcc and DDdd become CCdd and DDcc, with italics indicating an inverse bit). Then, take the pairs of sets of four bits (called nibbles), and going from the outside in, swap the first nibbles. So, if you start out with the bits AAaa BBbb CCcc DDdd EEee FFff GGgg HHhh, you will end with the bits GGhh BBaa EEff DDcc CCdd FFee AAbb HHgg. Using those bits, the first six nibbles make up the 24-bit memory address and the final two nibbles make up the 8-bit value that should be returned when that address is accessed.