So, it's been, what, four months, since I last posted an entry on the 6502 computer? I've been slacking off, doing Blender and Lua stuff in the meantime. Then I got bored and decided to work on the computer a bit.

The progress so far. To oversimplify things, I'd made everything that makes the computer... a computer. The CPU, I/O, RAM, ROM, video chip, and address decoding. I'd only planned on the sound, UART, IDE, and floppy interface, without making much progress due to them being complex and me being lazy. So, what was the problem here? As you may recall, I planned on using a YM3812 (OPL2) chip for sound and a PC8477-BV1 for floppy. Let's begin with the former.

The YM3812 is a rather complex chip. Definitely does not fit in a simple, early 80s style 6502 computer like this one. It has ridiculous FM synthesis stuff that my mind simply lacks the capacity to comprehend. It did not take me long to figure out that I needed something simpler. Something easier to program. That's when I ran into the YM2149 (or, AY-3-8910). This was a sound chip designed in the late 70s and was used in many popular video game consoles and computers of the early 80s, such as the Intellivision, Vectrex, Amstrad CPC, MSX, ZX Spectrum, and later in the Atari ST. The chip had a much simpler, "read some values from memory and spit out a tone" system of sound generation, none of the FM synthesis crap. The thing even had two peripheral interface ports, much like the 6522, so I could connect, well, other things to the computer as I pleased, like a keyboard. It was also extremely cheap and abundant. Perfect for my needs. I scrapped the idea of using the YM3812 and decided to go with this chip.

Now, the floppy controller. The PC8477-BV1 is a chip that was designed in the early-mid 1990s to control various drives in IBM compatible machines. It only came in PLCC or PQFP package, no DIP. That means I couldn't breadboard it. Much like the YM3812, it was simply needlessly complicated for use in this computer. It wasn't much longer until I decided to look for a replacement. That's when I came across the WD2797. The WD2797 is a much older chip, designed to handle 8" or 5 1/4" drives, and supposedly (and hopefully!) 3.5" drives too. A big plus is that it comes in DIP! It handles single or double density diskettes and FM or MFM encoding. It is generally a much simpler chip to deal with than the PC8477-BV1, and therefore is a lot easier to program. That being said, I didn't write a single line of code dealing with this chip yet.

So, that's what's currently planned for audio and floppy interface for the computer. I haven't looked much into IDE yet, although I did do a lot of UART stuff.

I had originally planned to use the 8250 UART, but then decided there was no reason not to use a 16550. I had obviously never programmed a UART before, but thankfully there were some excellent documentation on the chip that pretty much handholded me through what I needed to do to get the chip up and running. The 16C550 accepts a clock signal then divides it by a given divisor (a 16 bit value stored in two of the 8 bit registers within the chip) to set the baud rate. I had it connected to a 1.8432MHz clock and set the divisor to $60 (96 decimal) to default the baud rate to 1200. The funny thing about the divisor latch is that you can enable or disable it, and when it's disabled, the same address is replaced by something else entirely (receiver buffer/transmitter holding register and interrupt enable register). Anyways, then I had to deal with the FIFO. It took me a lot of time to sort of grasp what the FIFO did, and I don't understand it fully right now. All I could figure out is that it's a convenient thing to have and everything would become a lot more complicated if I didn't enable it. So I did. I had the FIFO trigger level to 1 byte (whatever that means) because it seemed more reasonable than 4, 8, or 14 bytes. I shall figure out the meaning of this later. Other than this, I just wrote a simple subroutine that I can call at any time to have the UART spit out its status register into video RAM, so it'll display some ASCII character corresponding to the state of the chip. It probably won't work because the video chip uses 6 bit ASCII, but whatever. I don't feel like having the computer actually decode the value and have it print out ones and zeroes to the screen, at least, not at this moment. That's all I did with the UART for now.

I had planned on making a system for changing address decoding on the fly, using some sort of RAM instead of ROM for the job. At first, stupidly, I wanted to use nonvolatile RAM, but every option I was given had critical flaws that made it impossible to implement into the machine. Then I got the idea of using SRAM and a ROM, where the computer would copy the contents of the ROM to RAM upon initialization. I came up with some brilliant circuitry to do this, through the clever use of some pins on the 65C22, ROM, and RAM, which simplified the copying process significantly. At least, until I found that I would still need 32768 LDA instructions to copy the contents of the ROM into RAM. I could use a hardware counter on the address pins, but at this point I decided this whole thing was getting out of hand. I scrapped the idea, but left some circuitry behind in case I could come up with a more realistic system of doing this in the future. More on that later.

Another thing I did was copy the schematics from my notebook into KiCad. Drawing schematics by hand was incredibly messy, especially because I often used a blunt pencil so I could easily erase stuff if I messed something up. The paper was small and I had difficulty fitting new circuitry into the sheet. A digital copy on a computer would be both cleaner and safer. Due to the "complexity" of the computer at this point and also the fact that a lot of the components used in the computer were not present in KiCad's component library (hence I had to make my own), it took me a good few hours to copy everything. In the process, I took the liberty of getting rid of most wire connections between chips and replaced them with labels. Sure, they might be a tad harder to figure out where stuff is connected to for others who might read the schematics, but it's fine for my needs. I also took extra time to make the more complex bits neater, and used a resistor array instead of a bunch of individual resistors for signals that needed to be pulled up or down. Thanks to all this, my schematic is definitely more pleasing to look at than the mess that I had before. Here's a picture, despite it being of terrible quality because for some reason KiCad's PNG export feature is garbage.

You may (or may not; I won't blame you) notice three expansion slots to the bottom right. It is provided with the ENTIRE system bus of the 65C02, along with a few extra signals. Those signals are two chip select signals, each mapped to one kilobyte of the I/O section of the memory map, and a pin that can entirely disable the on-board address decoding. That lets me make an expansion card to add that programmable address decoding feature if I ever want to. I also added an extra VCC and GND because I had a few remaining free pins. That filled up the whole 44 pins of the expansion port.

The keyboard has seen minimal changes since the first time I designed it. A difference is that it now uses NMI instead of IRQ. That's because the way that the keyboard triggers the interrupts is incredibly primitive, and it goes back low as soon as it is triggered. That isn't an issue per se, but as Ryan Witmer on the AA Discord pointed out, if something else were to request an interrupt while the computer was still dealing with the keyboard, it would lead to shenanigans that I don't want happening in the computer. So I simply mapped the keyboard to NMI instead of IRQ, since nothing uses NMI at the moment. I have not yet changed the code for the computer to reflect this, however. Speaking of which, here it is.

6502bios.txt

Anyways, I think that's everything, for now. I'll post new updates as soon as they come. Thanks for reading this hodgepodge of a blog entry, see ya.