Bender's brain. A 6502 prototype

• Motivation / history

  Why to design a 1 MHz 6502 computer during 2010? Some nostalgia is involved, sure. It is also something that I got posponed since long time ago. Back, in the old days, I had a little consideration for the 6502. I always regarded it as inferior to its main competitors, mainly the Z80. Therefore, I built several computer prototypes around the Z80 and never paid attention to the 6502. Then, it came the time for more powerful computers and I turned towards the 68000. Later, the microcontrollers offered a complete computer in a single chip. No more routing of address and data buses! Just an IC and a quartz crystal and that's all (and, today, not even the crystal is needed). As a consequence, I got a handful of old ICs rusting in drawers for 20 years.

  I changed my point of view about the 6502 after I tried to design a CPU core by myself. At that time I also knew the ARM architecture, and I started to recognize the value of hardware efficiency: do more with less transistors and less watts. Squeeze it into a small chip area, and sell it really cheap, and this was what Chuck Peddle, the designed of the 6502, indeed did. The amazing aspect of the 6502 was its price. It was so cheap that engineers first though it was a joke. Soon after the 6502 found its way into a lot of personal computers, arcade games and so on.

  So, I made up my mind to design and build a computer prototype around this CPU. First, I started with an ambitious design. It included up to 4Mb of dynamic RAM, a crude MMU with 16kB pages, and even a protection mechanism against the bad behavior of user tasks: If a IRQ was left unserviced for too long an NMI was triggered. The MMU will restrict the I/O accesses to user tasks anyway. I also started to write a multitasking system using a self made emulator for the prototype to come... But, then I learned about the KIL op-codes.

  These op-codes can stop the processor completely, and there is no protection against them. I guest the 6502 never went into space because of this. So, the whole design was more or less pointless. Also, the layout of the prototype turned out to require a lot of space, more than the usual boards I was using.

  At the end I settled for a simpler design. A little more than the usual 6502 + VIA SBC. Later, I added a peripheral card with some interfaces to the VIA.

• Features

There are 2 boards. The CPU board includes:

• 1 MHz 6502 NMOS CPU

• 64 kB of static RAM

• 8 kB of EPROM. The last 8 kB of the address space is shared between RAM and EPROM. Reads are directed to EPROM or RAM depending on a VIA pin. Writes are always directed to RAM.

• Address decoding is done in a PALCE22V10. This really reduces the IC count.

• One 6522 VIA for general purpose I/O

• Connector for an alphanumeric LCD

• Serial input through the Set Overflow pin. This input goes directly to the CPU and can be used for code download without any VIA use. As a side effect, you must keep this signal inactive while running your programs because it can set the overflov flag.

The second board is connected to the VIA pins only. It provides the following interfaces:

• A fast SPI interface. The VIA's shift register is used for output and a 74HC164 for input. This latter IC is connected to the full port B of the VIA.

• A SD card interface. It uses the SPI bus. The current ROM code can boot from a SD card with FAT-16 format.

• Connector for an Olimex ENC28J60 Ethernet module. It also uses the SPI bus, but it can also trigger an interrupt. This interface still has to be tested.

• A socket for I2C EEPROM memories. A bitbanging I2C emulator is provided in ROM. The system can boot from the I2C memory too

• A speaker. Sound is generated by toggling a VIA pin.

• A level converter for a RS232 interface. The UART function is emulated in the ROM code. The incoming data can trigger an interrupt in the VIA and this can be used to synchronize the reading. There are obvious disadvantages to this approach, but hardware UARTs weren't available, and the emulation is good enough as long as the incoming data comes from a keyboard.

• Schematics

• CPU board

• Memory map

The memory map of the prototype is shown in the figure. The placement of the memory-mapped peripherals is a bit unusual ($200 for VIA and $220 for LCD). These low addresses were chosen in order to get the biggest possible, non-fragmented free memory block when the ROM is disabled. The peripheral area is restricted to a single page that would be enough for 8 devices (32 addresses per device). Currently only the VIA and LCD are connected, but there is a signal (/XIO) in a expansion connector that is active for any access at the I/O page and it can be used for further decoding.

• Peripheral board

The most remarkable circuit in this board is the SPI interface. In order to get a clock signal compatible with SPI mode 0 devices (most of them), the clock signal from the VIA (pin CB1) is inverted and delayed half a cycle. The delay is implemented via 4 RC networks (R1-C1, R3-C2, R4-C3 and R5-C4) and its value is around 1us. In the following figure the related timing is detailed:



The input from the SPI bus is handled with a 74HC164 8-bit serial-in parallel-out shift register. After each SPI data exchange the received data is available on the PB pins of the VIA.

The SD cards and the Olimex Ethernet module are 3.3 Volt devices. A regulated 3.3 Volt supply is obtained from the 5V through a low-drop volage regulator (U3). The voltage of the SPI signals is also lowered from 5V to 3.3V using resistive voltage dividers (R2-R15, R9-R10, R11-R12 and R13-R14). In the design of these dividers the output resistance of the VIA pins was taken into account (about 5 kohm for PA6 and PA7 and 2 kohm for CB2)

An I2C EEPROM is included with a direct connection to PA1 and PA2 pins. The VIA provides the required pull-ups.

The RS232 level converter circuit relies on the negative voltage from the PC side. C10 gets charged to this voltage when there is a MARK condition on the serial port (at least during STOP bits). The voltage inversion and level conversion is done with transistors Q4 and Q5. All the timing of the serial port is done by program in the ROM code (bitbanging UART)

Finally, a speaker is connected to PA5, so, audio signals can be generated by toggling this pin. An amplifier for audio is built with Q1 and Q2 because the speaker impedance is too low to allow a direct connection to the via PIN. The volume of the audio signal can be controlled with a variable resistor (RV1) in series with the base terminals of the transistors.

• Board construction

• Photographs

  top view	front view	back view
  With ENC28J60

• Firmware / applications
  

• Sources

• Session logs / screenshoots...

• Miscelanea