Hardware Emulation of a 6502 in an FPGA

[gmcastil]

Greetings,

I am planning to clone a 6502 processor entirely in hardware using a Xilinx
Artix-7 FPGA. I've recently started working as an FPGA designer and am
gradually working my way up the steep learning curve that digital design has.
My ultimate project is to clone an 8-bit Nintendo, hence the choice of
processor.

My plan was to start by understanding the following materials:

http://archive.6502.org/books/mcs6500_f ... manual.pdf

http://wilsonminesco.com/6502primer/index.html

And for eventually implementing opcodes and such:

http://archive.6502.org/datasheets/syne ... manual.pdf

I have two major questions at this point regarding implementation.

1) Eventually, I will want to run something like Klaus' test suite against it.
How would something like that actually get loaded into the processor (soft
core)? The actual mechanics of loading a program are unclear to me. This might
be something to worry about later once I have a better handle on how things
work.

2) At some level, I know that I'm going to eventually be designing an FSM that
performs the fetch-decode-execute cycle against the opcodes and operands that
are clocked into the processor. I'm unclear as to how that entire cycle begins
- are the resources I've linked above the place to answer these kinds of questions?

Are there additional things that I should be reading as well before I start the
design? Is there a better place to be starting? Thanks for the help - this forum looks great.

[GaBuZoMeu]

Well first of all welcome to 6502.org!

Allthough I haven´t play with FPGAs so far, I am sure you will get the answers you are looking for. Just spend some time and digging through various topics especially within "Programmable Logic". There are a couple of people who have allready designed a 65xx core and dealing with various implemantation details, optimizations, enhancements, etc.

Studying one of these implementations will probably answer your questions.

In my opinion you have to implement the fetch-decode-execute FSM before trying Klaus´ test suite. And as you need to implement some sort of external (external relative to the core) memory (simple static RAM and/or ROM) you have to figure out a way to preset that memory with (useful) information (i.e. valid instruction sequences), to verify your work.

Good luck!

[GARTHWILSON]

GaBuZoMeu wrote:

Well first of all welcome to 6502.org!

Absolutely.

Quote:

There are a couple of people who have allready designed a 65xx core

Actually quite a lot of people. See http://6502.org/homebuilt#HDL for a partial list.

[gmcastil]

GaBuZoMeu wrote:

In my opinion you have to implement the fetch-decode-execute FSM before trying Klaus´ test suite. And as you need to implement some sort of external (external relative to the core) memory (simple static RAM and/or ROM) you have to figure out a way to preset that memory with (useful) information (i.e. valid instruction sequences), to verify your work.

Thanks for the responses.

Implementing the fetch-decode-execute part of the FSM is pretty natural I think - the part I'm ignorant of is what the 6502 does upon power up, prior to executing any of those opcodes. Hopefully this will get shaken out when I go through the hardware manual.

In general, how would I eventually go about using the test suite? I'm used to wrapping the HDL code in a testbench, which does all of that stuff. Klaus' suite looks like its more like executable code that runs on the processor.

[GARTHWILSON]

gmcastil wrote:

the part I'm ignorant of is what the 6502 does upon power up, prior to executing any of those opcodes.

What it does upon power-up is not defined. Things will be random. What you do upon power-up is bring the RST\ line down and hold it low for at least a few clock cycles after the clock is putting out a valid stream of pulses, for the processor to get its innards in order and then it can begin the reset sequence when the RST\ line is brought high again. Then it takes some more cycles before finally reading address $FFFD-FFFD to get the address of the reset routine to start execution in. The reset routine is your program that's normally in ROM, where you have your program material for setting up your I/O and doing various things to get useful operation launched.

[Arlet]

gmcastil wrote:

1) Eventually, I will want to run something like Klaus' test suite against it.
How would something like that actually get loaded into the processor (soft
core)? The actual mechanics of loading a program are unclear to me. This might
be something to worry about later once I have a better handle on how things
work.

The FPGA has enough memory (block RAMs) to run the test suite internally. These block RAMs can be preloaded with data during FPGA initialization. There are various ways to define this data in the HDL, either through parameter definitions, initial statements, or loading the data from file, just like you would preload testbench memories. The modern synthesis tools are smart enough to synthesise these initial statement into a memory image and include that in the bitstream.

In addition, there are tools to update the memory in the bitstream file, so you can modify the program later, without having to resynthesize all your HDL.

[Arlet]

I would recommend starting with a very simple state machine, just capable of running LDA #imm. Have the PC initialized at 0, and map that location to a test memory filled with LDA #imm opcodes. Make sure the PC increments, and the accumulator takes on the immediate values. When you see a RESET signal, reset the PC back to 0.

That is a relatively simple project, but in solving these first steps, you'll get an idea of how to make the design. Once you have that running, you can expand, and implement LDX #imm, LDY #imm, and then move on the LDA zp, and so on.

[gmcastil]

GARTHWILSON wrote:

What it does upon power-up is not defined. Things will be random.

Yeah, this is actually what I meant - reset, rather than power-up.

GARTHWILSON wrote:

What you do upon power-up is bring the RST\ line down and hold it low for at least a few clock cycles after the clock is putting out a valid stream of pulses, for the processor to get its innards in order and then it can begin the reset sequence when the RST\ line is brought high again.

This is the part I was looking for clarification on - what do you mean by 'get its innards in order'? Isn't that the sort of behavior I need to actually emulate?

GARTHWILSON wrote:

Then it takes some more cycles before finally reading address $FFFD-FFFD to get the address of the reset routine to start execution in. The reset routine is your program that's normally in ROM

So coming out of reset the processor looks to address $FFFD to get the address to begin program execution? This is the kind of information I think I'm looking for - where is this sort of thing documented?

[Arlet]

gmcastil wrote:

So coming out of reset the processor looks to address $FFFD to get the address to begin program execution? This is the kind of information I think I'm looking for - where is this sort of thing documented?

It's documented in the programming manual that you linked in your first post on this topic. Example 9.1 shows all the cycles of a RESET.

What the CPU actually does is execute a BRK instruction, with a different vector. Hence my suggestion to first start with a model that just initializes the PC at 0000, and implement a few simple instructions. When you get to the BRK instruction (which is one of the more complicated ones, so save it for later), that's a good time to implement the RESET procedure.

[jac_goudsmit]

gmcastil wrote:

the part I'm ignorant of is what the 6502 does upon power up, prior to executing any of those opcodes.

In addition to what others have already said, I can say from my own experience that the WDC 65C02S doesn't do anything really, it just sits there until you reset it. I don't remember what it puts on the address bus and if it ever starts up with R/~W low, but I have some code that tries to let the Propeller inject a BRK instruction by feeding 0 to the data bus, and inserting the reset vector as IRQ vector when the 65C02 retrieves it, and it consistently doesn't work just after power-up, until the reset pin is activated for at least 2 cycles.

This behavior is not described in the datasheet but it makes sense: as long as the hardware is in an unknown state, you don't want the CPU to execute random instructions, so I suspect that this was done on purpose by WDC. Whether this matches earlier 6502 designs, I don't know, but it shouldn't be too hard to emulate in an FPGA.

===Jac