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
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.
There are 2 boards. The CPU board includes:
1 MHz 6502 NMOS CPU
kB of static RAM
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.
decoding is done in a PALCE22V10. This really reduces the IC count.
6522 VIA for general purpose I/O
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
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.
SD card interface. It uses the SPI bus. The current ROM code can
boot from a SD card with FAT-16 format.
for an Olimex ENC28J60 Ethernet module. It also uses the SPI bus,
but it can also trigger an interrupt. This interface still has to
socket for I2C EEPROM memories. A bitbanging I2C emulator is
provided in ROM. The system can boot from the I2C memory too
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
is a simple 6502 + 6522 system. The only things worth to mention are
the address decoding, using a PALCE22V10 and the S. O. input. The
decoding logic, inside the PALCE chip, uses the ROMEN signal from the
VIA (pin PA0) as a selectrion between high RAM or EPROM. After reset
PA0 is programmed as input and it includes an internal pull-up, so, its
level is high and the EPROM is selected.
The S.O. input can be driven high and low with an audio square-wave
through the transistor Q1. The V flag is set on every failing edge of
the wave, and the time between edges can be measured to decide if the
incoming bit is zero or one. Te ROM bootloader expects a frequency
modulated audio signal that is generated in the PC.
Also, the reset circuit includes a gate with hysteresis made up with four CMOS inverters.
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
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
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.
boards were made using a CNC milling machine. Only single side PCBs
were used, and, therefore, several lines have wire bridges on the
component side. In the layout editor (Proteus Ares) these wires were
placed as straight tracks on the component side (red color).
The current ROM code allows booting from the S.O. pin interface, I2C EEPROM
and the SD card. In addition to this it includes a full featured
dissasembler/debugger that can be invoked by executing a BRK op-code or by typing <ctrl-C> in the serial terminal.
Several utility routines can be called through a jump table at the
begin of the EPROM (address $E000). These routines include UART
emulation, I2C emulation, hexadecimal printing, SPI transfers and
MMC/SD card management (an ethernet driver is also being tested).
A new version of the ROM code also includes a simple FAT-16
command-line interface (read-only FS) allowing directory listing,
directory change, file read to terminal (type) and file execution. The
last code addition is related to the ENC28J60 ethernet interface. The
internet application currently can receive ethernet packets and
sucessfully replies to ARP and ICMP_ECHO packets. A separate code
version replies to these packets from an interrupt routine. This last
code is still buggy mainly due to the fact that the CA2 pin in the VIA
is sensitive to edges, but the ENC28J60 INT pin is level sensitive.
As for applications, there are only a few. I ported the EhBASIC
interpreter and it runs fine. EHBASIC replaces the ROM code by
disabling the EEPROM and gets an amazing 51 kB of free memory. Other
applications can be developed using the cc65 C language compiler.
- Session logs / screenshoots...
6502 assembler syntax highlighting for gedit: asm6502.lang to be placed on /usr/share/gtksourceview-2.0/language-specs/