A container of chips sitting next to my favorite computer.
I ended up making about 40 of these breadboard friendly 512K SRAMs in the end because I don’t like to run out of anything when I start a project! Now it’s time to get back to the task at hand, and start wiring up the most epic 6502 based computer ever conceived. My VIC-20 will be watching in the background with great interest, ready to jump in and lend a hand testing our some 6502 routines if required.
Adding VCC and GND connections to all ICs
Once the ICs are placed in what will hopefully be their final position on the breadboard, I add all of the VCC and GND connections from the ICs to the horizontal dedicated power rails on the breadboard. Power will not be switched on until all connections are triple checked, as it is very easy to let the magic smoke out of IC when it is connected in reverse!
Most 74 logic ICs are easy to check since the standard is to have VCC (+) on the top left pin and GND (-) on the bottom right pin. The large ICs like the SRAMs and 6502 do not follow any kind of standard, so they are checked carefully by reading the datasheet for the pinouts. I have cut hundreds of small Red and Green wires for VCC and GND connections, as I always require many of these when using a breadboard to prototype a circuit.
Starting with the Data Bus wiring.
Once all of the VCC and GND wires have been added and double checked, I like to do an electrical test to ensure that there are no miswired ICs. Knowing that current draw would be only a few milliamps, I place my ammeter between the 5V power supply and then quickly apply power, watching the resulting current draw. If there is a short or reversed IC, current will spike well beyond 100mA right away, and I would quickly withdraw power to make the correction. This time, all went well.
The Data Bus that connects the 6502 to its memory and the ROM Loader will be the next wiring to add to the board. Because the 6502 Data Bus will be shared by many ICs on the board, it is a matter of chaining from one to the other, keeping the wiring as short as possible. For Data Bus wiring, I always use Blue wires so they are easy to identify when debugging the circuit.
In this photo, I started the Data Bus wiring at the five 74HC574 Data Latches that are used to latch the Address Lines of the Program Memory (1 MB), which are divided into 8 Bit segments. It may seem odd to connect the Memory Address Lines to the Data Bus, but since this memory is not directly accessible by the 6502, it has to be done by latching both the Address and Data lines via the 574 Data Latches. The first three latches handle the 20 bit Address Bus of the Program Memory, and the other two latches assist the ROM Loader when the 6502 Memory (64K) is loaded on power up.
74HC574 Data Latch Block Diagram and Pinout.
A 74HC574 Data Latch is basically a single byte SRAM, capable of storing or sending 8 bits of data. I use these ICs a lot in my designs, only second to the 74HC245 buffers. As you can see by the block diagram, data present on the D0-D7 inputs will be latched (stored) into the output buffer when there is a high to low transition of the CP (Clock Pulse) pin. If you consider the CP pin to be the same as a WE (Write Enable) pin on a standard SRAM, then functionality is the same.
Much like any SRAM, the 574 Data Latch also includes an OE (Output Enable) pin, which when low, will output the state of the latch on the Q0-Q7 outputs. When OE is high, the outputs are in the high impedance (invisible) state.
Besides latching data, I find these ICs to be very useful in aligning data to a clock pulse. If you connect a shared master clock to the CP pin, all data passing through the 574 will be registered only on the high transition of the clock pulse, which means that signals that have some propagation delay will be synchronized back to the clock pulse. This synchronization will become very important in the Video Generator circuit, as any propagation errors would show up as glitches in the final video signal.
Wiring the Data Bus to the Memories.
Once the five 74HC574 Data Latches were chained to the Data Bus, I continued the 8 bit bus down to the ROM Loader and then to the three SRAMs that make up the Program Memory and 6502 Memory. The ROM Loader is an AVR microcontroller that is being used to simulate a 64K ROM. Rather than sourcing hard to find ROM ICs and a ROM Burner, I just made an AVR act like a standard 64K ROM, which also allows me to flash it in a few seconds using the AVR in circuit programmer. On power up, the AVR dumps its program memory into the 64K 6502 Memory, and then hides form the circuit.
Now the Data Bus is interconnected to 10 ICs; five 75HC574 Data Latches, three 8 Bit SRAMs, one ROM simulator, and the 6502 Microprocessor. The Data Bus will connect to a lot more later on as well.
512K SRAM Block Diagram and Pinout.
I am using the same 512K SOJ package SRAMs for all SRAM in this project, since they were readily available, and inexpensive in quantities of 10 or more. Even the 64K Memory used exclusively by the 6502 is just another 512K SRAM with its 3 upper address lines tied low, making it into a 64K SRAM.
The block diagram for the 512K Static Memory looks a lot more complex that the diagram for the 74HC574 Data Latch, but operation is virtual the same, but with the addition of addressing of the data. A Static Random Access Memory (SRAM) has an address bus that is as wide as require to address the entire capacity of the RAM, so in this case, 19 address bits are used since 2^19 = 524,288 Bytes.
When the OE (Output Enable) line is low and when the WE (Write Enable) line is high, the memory outputs whatever 8 Bit Data is stored at that address location. To write data to the specified location set by the Address Bus, OE is set high, and WE is set low. The CE line (Chip Enable) completely disables the SRAM when it is high, making it completely transparent to the rest of the circuit.
Connecting the 6502 Data Bus.
The Data Bus finally stops at the 6502 Microprocessor, which is the IC that is in total command of the Bus once the ROM loader has dumped its memory into the 64K memory used by the 6502. On power up, the 64K that is dumped into the 6502 memory will by the Operating System, which will be called (VOS) Vulcan Operating System.
The Data bus will later continue along the board to the IO Decoder section so that the 6502 can read or write control data to all of the subsystems such as the Video Generator, Sprite Generator, and Audio System. For now though, the 6502 will be wired as a closed system just to make sure that it boots and functions correctly at the desired speed. 8 LEDs will be used to verify functionality.
65C02 Microprocessor Pinout.
The 65C02 Microprocessor pinout is almost identical to the 1970’s version, with the exception of a few pins, and the addition of Bus Enable (BE) on the previously unused pin 36. BE is extremely useful as it allows the 6502 to be tri-stated on the bus so that other devices can access the bus. The original 6502 did not have this ability, so systems like the VIC-20 had to resort to adding buffers such as the 74LS244 or 74LS245 to the bus to isolate the 6502 during shared access. Unfortunately, every IC added increases the propagation delay of the bus, resulting in lower performance.
The BE line will be used in this circuit only on power up. When the system is initially powered up, the ROM Loader will hold the 6502 in reset and with its bus disabled while the Operating System program is dumped into the dedicated 64K used by the 6502. This process will take only microseconds, so Vulcan-74 will be displaying the User Prompt almost instantly.
The system clock and divider circuit.
If everything works as planned, the 6502 and NTSC Video Frame Generator will run at 7.159MHz, and the Sprite Generator will run at 14.318 MHz (or possibly higher). The NTSC Video Frame Generator requires this precise 7.159MHz clock because in order to generate color, some multiple of the NTSC Color Burst Reference Signal must be used, which is 3.579545 MHz at its base frequency.
14.318 MHz was chosen because it is an easy to find oscillator value of four times the Color Burst frequency, and most likely the topmost speed of the 6502. The base frequency will be fed into a 74HC163 counter in order to extract the 7.159 MHz, which is divided by two. At this frequency, the Video Generator will be capable of generating a video resolution of 360×240, which to the monitor will be about 320×200 of usable video with the rest being in the overscan area.
Being capable of overscan means that Vulcan-74 will not be constrained by the typical borders of the 1980’s era computers and game systems, which were there to make sure that the viewable screen did not extend past the bezel that was placed in front of the picture tube. The Amiga was one of the first home computers to deliver overscan, which is why it found its way into video production uses as a title and graphics generator. Modern LCD monitors do not require overscan as they deliver a known resolution within the dimensions of the active video panel.
Block diagram and pinout for a 74HC163 Counter.
The 74HC163 counter is a very popular 4 bit binary counter that can be used for many different functions other than just counting. The counter is loadable, so it can be preset to a known value, and it has a carry output so it can be cascaded to other counters to make a much larger bit counter. I will utilize these counters for many other functions in the project, especially the Sprite Generator, which will require the 2D counting to move blocks of memory from one X/Y location to another.
Operation of the counter is extremely simple, just feed in a clock to the CP pin, place CEP,CET,PE,MR high, and out comes a 4 bit count from the Q0-Q3 outputs. In this instance, I am using it as a clock divider, so the output pins offer these divisions of any clock feeding onto the CP pin; Q0(/2), Q1(/4), Q2(/8), and Q3(/16). Also not that Pin 14 is incorrectly labelled as D0 when it should be Q0. I always laugh at this error in the data sheet because it has been in print since I started electronics decades ago, and lasted through hundreds of revisions. This datasheet is from this year! They must have considered it a “heritage mistake”, and decided to keep it after all these years!