Subversion Repositories cpu8080

Intel 8080 CPU Verilog core

2006/9/12

PROJECT:  8080 CPU

LANGUAGE: VERILOG

TARGET:   Xilinx xc3s1000-4

This core was implemented as a first project in Verilog by an old schematic

design engineer. There were a few reasons for implementing an 8080 processor.

First, it was the first true general purpose processor available. Second, it

was, by nature, designed to be compact in instruction set and implementation.

Third, it has a rich set of software applications, including assemblers,

compilers and operating systems.

More often, A Z80 target is used in Verilog or VHDL, with the idea that the

Z80 is the superset of the 8080. However, the Z80 is significantly more

complex than the 8080. The 8080 can make a useful maintainence processor for

SOC systems, since it consumes a small amount of resources. The 8080 has a

significant body of support, since it was a primary 8 bit processor before

the Z80, and coding for the 8080 instruction set often continued even after

general Z80 use, because that was the universal subset of both processors.

My own experience with 8080 coding lasted perhaps a year, then I switched

to the Z80. Although he Z80 was a significantly more usable processor to

code for than a 8080, it made a mildly non-orthogonal instruction set much

more so. I have worked on several processors through the series, including

working on the design for the Z280, a Z80 16 bit replacement at Zilog

Corporation, so hopefully nobody can accuse me of bias against the Z80 :-)

The core presented is completely compatible with the original 8080 instruction

set, although the exact handling of the two undefined bits in the status (flags)

register have not been verified to be identical to the original. This only

matters for "trick" code that expects a value which is pop'ed into the PSW

to be preserved when subsequently pushed. This core preserves all bits,

including the undefined bits, which means such code would function correctly.

Also needing verification to the original are the illegal opcodes, which on

this core are treated as nops.

The pinout is decidedly not compatible with the original pinout. The original

8080 pinout was a multiplexed nightmare that was never really designed to be

directly used. Intel was attempting to save on pins, and much of the CPU status

was sent out on every cycle via the data pins. Intel subsequently came out with

"demultiplexor" chips to result in simple signals.

The cpu8080 signals are a simple unmultiplexed 16 bit address, and a

bidirectional, separate 8 bit data bus. The read and write for each of memory

and I/O spaces are all separately decoded. An interrupt request and acknowledge

is implemented sufficient to allow an external interrupt controller to be

connected. A readint signal is implemented that is true for the entire time that

an interrupt fetch is occuring. This allows simple implementation of full

vectoring mode.

There were two vectoring modes on the 8080. The most famous one was the use of

a single instruction byte that was forced onto the data lines during an

interrupt acknowledge cycle. This instruction could be any valid instruction,

but was most likely a restart, which gave 8 possible vector locations for the

interrupt.

It was not as well known, but the original 8080 could accept a full 2 or 3 byte

instruction via the interrupt acknowledge cycle. This was used by advanced

Intel interrupt controllers to place a full CALL instruction on the data lines,

and thus achieve full arbitrary address vectoring. I have included such an

advanced interrupt controller as an accessory to the cpu8080 core, also in

verilog.

cpu8080 was implemented in Xilinx ISE, simulated, and then carried out to an

XESS XSA-3S1000 board with a Spartan-3 XC3S1000 FPGA. This board can download

the test design and run it with a standard PC keyboard and VGA monitor. To drive

the onboard pheriperhals, the total package includes a VGA/Keyboard driver that

emulates the original Altair serial port card, addressing for the flash, and

addressing for 64kb of the SDRAM.

The software provided includes a BIOS image sufficient to run CP/M 3.1 from the

onboard flash. The flash contains a short bootstrap, then the BIOS treats the

flash as partitioned disk drive. Also included are utilities to get the flash

images and programs on and off the board. The resulting software/hardware

combination emulates a minimal video terminal connected to a Altair or similar

Home Computer running CP/M. Several simulators can be found for the PC that

run this same combination.

Scott Moore