Ruud's Commodore Site: The Mini6502 Home Email

The Big6502






What is it?

This document describes the ins and outs of how to build your own 6502 processor using TTL ICs and FlashRAMs on one single board: Big6502. The main idea is that it should be 100% 6502/65C02 compatible.
Two other ideas what can be done with it:
- replace another processor, like the Z80, and run 6502 code on it
- replace another processor, like the 6800, and run 6800 code on it

I'm busy building three different TTL-CPUs and this is the biggest one. The others:
- My TTL CPU, the smallest one and using only TTL ICs, thus no RAM or EPROMs
- Mini6502, the middle one, TTL ICs and FlashRAMs, 6502 code compatible, but slower.


Is it possible?

Building your own processor, is that possible? Yes, it is. First of all, forget that processors are just one single IC like the 6502, Z80 or 80486. Computers have been constructed already long before the IC was invented. Intel's 4004 is considered to be the first one-chip CPU in the world and its production started in 1971.
In the very early days computers were built using simple components like relays, tubes, transistors and small ICs. And if you don't believe me, please have a look at this site, a ring of self built processors. Very interesting indeed! It will show you, for example, processors using relays as logic gates.


A bit of history

Once I wanted to build a 6502 TTL CPU:My Own 6502. Nice goal but with eight cards on the end, a steep one. So I decided to design a CPU that could run 6502 code but with as less ICs as possible: Mini6502.
Then I deciced to have another go at a TTL CPU that would be able to replace a real 6502. I also wanted to include some extras: I wanted to implement eight extra address lines and some extra control lines that would enable me to replace for example the 6800, 6809, Z80 and maybe the 8088, and then run 6502 code on the host system.


What processor can it emulate?

As you could read above, the whole idea started with the goal to emulate a 6502 for 100%: Big6502 should be able to replace a real 6502 and the host system shouldn't notice it. Two factors determine how this self built CPU will behave:
- The hardware. The design should be thoroughly thought through because once turned into real hardware, only minor fixes are possible.
- The micro code. Micro code can be seen as software. Thus in case of an error it is just a matter of fixing it and reprogramming the FlashRAM(s).

Another wish is to emulate the 65816 but, to be honest, I have some doubts about implementing the block instructions. Although not knowing the 6800 well enogh, I'm quite sure I can emulate it. I think that I can simulate the 6809. Simulate because it never won't be cycle exact.
But whatever wish I have, just programming the FlashRAMs for the 6502 mode is a lot of work so I fear it will be just wishes for a long time.

My idea is to start with the 6502 as base. But the 6502 has about hundred unused opcodes and one of my goals to implement my own opcode here and/or code to emulate the 65816 or 65C02. I already mentioned replacing the Z80 and 8088 with Big6502 above and that means that I need at least the hardware equivalent of the I/O lines plus the instructions to be able to address these lines. But for replacing the 8088 and the 65816 means I also must be able to handle at least 1 MB of ROM and RAM. Therefore the decission to install 8 extra address lines.


General description

The hardware is kept as simple as possible. The whole can be divided in the following parts:
- the interface to the outside world
- the Instruction Decoder
- Static Addresses
- Stack Pointer
- Program Counter
- Read the momentary address
- Temporary address
- Address lines 16..23
- the A, X and Y registers, plus more
- the ALU
- Flag register


First: a remark about the schematic

If you look, for example, at the in and outputs of the Instruction Decoder FlashRAMs at the top-left of the schematic, you will notice there seems to be no order in the lines. I assure there was. But when creating the board I noticed I had too many Instruction Decoder outputs going from left to right and vica versa. So when going from left to right, I connected the lines I encounterd also from left to right to the FlashRAMs.
The clock generator, IC78B, and the Instruction Register, IC98, can be found left of the FlashRAM at the bottom of the board and they provide 13 of the 18 needed signals. Trying to connect them to the FlashRAMs in a neat order would have lead to another chaos of crossing lines. So I simply connected them from bottom up: not one crossing line there and more important, saving space!


The processor port: the interface to the outside world

A female AC DIN 64-pins connector is the interface to the outside world. As said before, the idea is that you connect a board to it with a corresponding male connector. This board should contain all the needed hardware to connect the Big6502 to the target system. This enables you to use the Big6502 in a 6502, 680x or Z80 system and maybe even in a 8088 system (see later). The hardware can be as minimal as a single connector to connect it to a 6502 system or a connector and some extra gates to connect it to a 8088 system.

An explanation of the various pins:
- A0..A23: 24 address lines enable the Big6502 to address up to 16 MB of RAM, ROM or I/O. If the Big6502 is going to replace a real 6502 one day, the extra eight address lines won't be in the way, just leave them unconnected.
- D0..D7: the eight data lines
- RDY, NMI, IRQ, RESET, SO, AEC and SYNC are the well known 6502/6510 pins.
- PHI0, PHI1 and PHI2: the well known 6502 clock signals.
- HALT, M1: the well known Z80 signals.
- FIRQ: a signal needed for connecting to a 680x system.
- IORD, IOWR, MEMR, MEMW: those who are familiar with 80x86 systems will recognise these line; they are used to control memory and I/O operations. The 6502 doesn't need these four signals, so why? One of my intentions is to use the Big6502 on an IBM PC-XT board. These lines are free programmable so the micro code can be adopted to attach Big6502 to a Z80 system as well.

The data bus buffers Two 573s, IC101 and IC28, take care of the data bus by latching and buffering the data coming from and going to the processor port.
- IC101 takes care of reading and latching the data coming from the processor port. Why is latching needed? This is to make sure that the data is also available to the Big6502 after PHI0 has become (L), for example, for storing it in a register at the next step. The clocking is done by PHI0'.
- IC28, takes care of reading and latching the internal data and presenting it to the processor port. Both the latching and enabling is done by the ID. An OR gate, IC204B, makes sure that IC28 is disabled as well when the AEC input of the processor port is activated.


Instruction Decoder

The Instruction Decoder (ID) is the heart of the processor because it is the ID that decides how the processor behaves. The heart of the ID in my design is a number of FlashRAMs and that will contain the so called micro code.

Like the outputs of the 573s of My TTL CPU, each output of a flashRAM will control various inputs like clock, latch, choosing a function and enable. All these bits together for a given address of the FlashRAMs is the micro code. And we will need a lot of these bits.
Is there a way to reduce this number? Yes, there is. Various outputs of registers have been connected to the internal data bus, for example the output of the ALU and register A. But only one can be read at the time. When using a 154 demultiplexer, IC44, we can select up to 16 outputs to be read and we only need four FlashRAM bits. The used lines are marked as Rx where "x" is a number.
When clearing or presetting fliflops, some of these actions have to be done parallel. A good example is clocking data into the 74 flipflops of the Flag Register: this has to be done for all eight bits at the same time. OTOH, when an address has to be clocked into the LB latch of the Program Counter, most likely there is no need to clock this value into another latch. So we can use a demultiplexer for these registers as well: IC8, a 154, and IC9, a 138 3-to-8 demultiplexer. Because the 573s need a positive clock signal to latch the data, most outputs of these ICs are inverted.

What inputs do the FlashRAMs need?
- the opcode read from the system plus two extra opcode bits, O8 and O9, ten bits in total
- a 5-bits counter, good for 32 steps
- a signal that tells there is a reset, interrupt or other important signal present (RIND)
- the branch signal (BRAD)
- running in 8 or 16 bits mode (8_16)
For this number of inputs we need 29F020 FlashRAMs.


Handling extra opcodes or multi-byte opcodes

The Z80 and 6809 have multi-byte opcodes. And with the ideas I have, I will probably need multi-byte opcodes as well. My idea of handling them was adding two 74 flipflops to the design: IC27A and IC27B. To make sure that after the reset routine the micro code of the first level of the opcodes is chosen, RST2, the output of the Reset fliflop activates both Clear inputs which will clear the opcode bits O8 and O9.
When running a multi-byte opcode, the first byte of the opcode will set/reset one or both Data inputs using ID lines I19 and I45 at the last step before resetting the counter. At step 0 the data is clocked into the flipflops. Just to be sure: resetting the counter does NOT reset any of the flipflops and therefore a complete different micro code set is available at step 2. FYI: step 1 is the same for all micro code sets.
In this way a third and even a fourth set can be loaded, if needed. What is a real must is that the last byte of the multi-byte opcode negates both I19 and I45 at the last step before resetting the counter. At step 1 Big6502 can handle the next instruction.


The counter circuit

Executing the opcode is executing a collection of micro codes. The counter tells the ID what step in the set of micro codes has to be executed.
The base signal for the counter is the clock signal provided by the processor port, in this case PHI0. Because PHI0 must serve as input for many other gates in my design and not being sure if this will stress the original system, I decided to buffer it first with IC81C, an AND gate. Its output is called PHI0'.
The 6502 outputs PHI1, nothing more than an inverted PHI0, is created by inverting PHI0' using IC23B. PHI2 is generated by inverter IC23C.

The actual counter is IC78B, a 393 4 bits binary counter with clear. Together with PHI2 we now have a five bits counter where PHI0' is the (Lowest Significant Bit (LSB), now called CLK0. These five bits, good for 15 clock cycles/31 steps, are directly fed to the FlashRAMs.
The outputs of the 393 are also fed to a 4 input NOR gate, a gate created out of an OR gate (IC204C) and a 3 input NOR gate (IC77C). At the end of an instruction the 393 is cleared and all its output become (L) again. The output of this 4 input NOR gate becomes (H). This signal is ANDed with PHI0' using AND gate IC81A. The output of IC81A is used as trigger to latch data into two 573s, IC98 and IC86 (see later).

Resetting the counter
Resettting the counter is done by setting ID output R1 (H). But this is not the only signal that should be able to reset it. The Reset signal must be able to reset the counter as well. So before the signal reaches the 393, it has to be ANDed (IC81B) with the Reset signal and the result has to be inverted (IC23F). The effect is that an active Reset keeps the 393 in reset mode, it will output 0000 as long as the reset signal is active.
Once the counter has been resetted by R1, the clear signal must be disabled again and that is a piece of cake. Whatever step took care of activating R1, the moment the clear signal makes the 393 to output 0000, the micro code bits that handles R1 is resetted. Mission acomplished!


Latching the opcode: the Instruction Register

IC98, a 573 8 bits latch, is the so called Instruction Register (IR): it latches the opcode which is only present at step 1. The Instruction Register makes sure that the opcode is available during the other steps. The signal to clock the data comes from the AND gate IC81C, as already mentioned above.


Latching FIRQ, Reset, NMI and IRQ

My very first idea was to feed these signals directly to the inputs of the FlashRAMs. But when I started to design "My Own 6502", FlashRAMs were very expensive and I had to use EPROMs. But the reasonable priced EPROMs had too less inputs, thus another idea was needed.
Then it occurred to me that during a reset or interrupt, the opcode part of the ID wasn't used. So I decided to feed the FlashRAMs with these signals instead of the opcode. Now I only needed one signal to tell the ID whether it was dealing with an opcode or a reset, interrupt or equivalent signal: RIND. IC86, a 573, latches Reset, FIRQ, IRQ and NMI and feeds them to the ID when needed.

NMI
NMI, a negative edge triggered interrupt, is inverted first (IC23E) and fed to the CLK input of a 74 D-flipflop (IC85A). Why not tying NMI directly to PRE and saving a gate? At the end of the process the ID has to reset the flipflop. Using PRE as input would immediately set the flipflop again and thus forcing the decoder to repeat the whole process.
After handling NMI, the flipflop is resetted by R2.

IRQ
IRQ is a level triggered interrupt and it is only checked at the end of PHI0. IRQ can also be disabled. NOR gate (IC77B) serves all these demands in one go. If the IRQ is active (L) at the end of PHI0 and the "disable interrupt" flag is inactive (read: (L)) as well, then the moment PHI0 becomes (L) the rising edge of the output of the NOR gate will trigger the D-flipflop U205A.
After handling IRQ, the flipflop is resetted by R3.

FIRQ
FIRQ is an input that is in fact typical for the Motorola 680x series. So why is it here? I copied this circuit from the Mini6502 without realising at all at that moment that the Flag Register of the Big6502 had its own SO input. When connecting the flipflop to the SO pin of BNig6502 port, I noticed the mistake. I could omit this part from the whole circuit but it would not have saved me any IC. One idea was to connect this board to a Eurocom-1, a 6802 equivalent of the KIM or Micro-Professor, and that triggered the idea to use this part for the FIRQ interrupt signal.
To be very short about the circuit: FIRQ is treated the same way NMI is. IC23D is the inverter, IC70B the used flipflop and R7 the reset signal.


Reset
Reset doesn't suffer the above problems because the counter cannot start until the Reset signal is inactive again. Therefore it can be connected directly to the PRE input. After handling Reset, the flipflop is resetted by R0.

The further processing of FIRQ, Reset, IRQ and NMI
The four Q outputs of the flipflops are latched by a 573 (IC86) at step 1 and NORed by the OR/NOR combination IC204A and IC77A. If one or more of these signal are set = (H), IC77A's output becomes (L). This signal goes through two 3-input NOR gates, IC7B and IC7C (see later), to the data input of a 74 flipflop, IC205B. The output of AND gate IC81A that is used to clock the data into IC96 and IC86, is also used to clock this data into the flipflop.
The outputs of this flipflop now either enable the outputs of IC96 (= opcode) or those of IC86. The Q output of the flipflop, RIND, is the signal that tells the FlashRAMs whether a special signal has been detected or not.

Why is D-flipflop IC205B needed at all? The output of IC77A can change in the middle of handling an opcode or a special signal. And we cannot have in the middle of handling an instruction that another micro code set is chosen. Therefore the state of the output of IC77A at step 1 has to be saved as well.
The flipflop does not have to be resetted: the moment all special signals have been handled, the D input becomes (H) at step 1 and the latch for the opcodes is selected.

What about the two 3-input NOR gates, IC7B and IC7C? As said, at step 1 the state of the output of IC77A is checked and saved. But we cannot have that when dealing with a multi-byte opcode. When dealing with a multi-byte opcode, O8, O9 or both are set. So we OR the output of IC77A with these two opcode bits and and when even one of them is set, any interrupt is ignored. Only the interrupts, a reset will clear O8 and O9 and nothing will block the output of IC77A anymore.


SYNC
SYNC is an active (H) 6502 signal that tells the outside world the first cycle of an opcode is being processed. Just by coincidence the signal to reset the flipflops for the extra opcode bits is exactly what we need.


M1 signal
M1 is the Z80 equivalent of SYNC. But in contrary to SYNC is M1 active (L). It is created by inverting SYNC using NOR gate IC7A.


ReaDY signal
RDY is a signal to tell the 6502 to halt as long as RDY is (L). The outputs of the 393 are increased at every falling edge of PHI0'. The basic idea is that RDY should prevent PHI0' to reach the counter. Before PHI0' is fed to the 393, it goes through an OR gate, IC204D. This gate ORs PHI2 with the \Q output of IC85B, a 74 D-flipflop. This D-flipflop represents the state of RDY at the end of PHI0 and does this by saving the state of RDY at the rising edge of PHI1. If RDY is (L), output \Q becomes (H) and will block all pulses from PHI2 towards the 393 and ID by keeping CLK0 (H).
To avoid the risk that the blocking signal coming from the flipflop arrives too late and the 393 would still count up, I delayed the PHI2 signal towards the OR gate using a left over AND gate, IC81D.

Having some left over Lx lines, I decided to implement an idea that I used on My TTL CPU: the HALT instruction. It is nothing more then connecting L2 to the Clear input of the RDY flipflop.
In contrary to the HLT instruction of the Z80 and 8088, this state cannot be ended by an interrupt. Here HLT is really halt. Why? Simply because it was possible with the means still available.
But then I found out that the STP (= SToP) intsruction of the 65816 exactly does what the hardware now did. And then there is WAI, WAIt for an interrupt, which does what HaLT of the 8088 does: halt the CPU and continue when an interrupt is received. Bummer, if I want that as well, more hardware is needed. Or not?
IC77A outputs a (H) the moment an interrupt is active (disregard the Reset in this case). If I place an OR gate between L2 and the Clear input of the Ready flipflop and connect the output of IC77A to the other input of this OR gate, Things could work. Having a good look at the left over 139 demultiplexer, I realized that it could emulate an OR gate. Mission accomplished!
So how does it work? Negating L2 brings Big6502 to a halt. An interrupt will awake it again. Big6502 will finish the WAI instruction and the interrupt can be handled. Step 0 of every instruction will pull L2 (H) anyway so nothing further regarding L2 has to be done.


HALT signal
Z80's HALT signal tells the system that the HALT opcode has been executed and that the processor has been halted. In this case the Q-output of the RDY flipflop, IC85BB, generates HALT.


Static addresses

After a reset, the address bus has to output the addresses $FFFC and $FFFD. And when serving an interrupts or accessing the stack, other static addresses have to be outputted. In the Mini6502 the ALU took care of that but that costed time. So here I decided to let two 29F020s, IC21 and IC22, handle it. Maybe a big overkill but at least a very fast one.


The Stack Pointer

The Stack Pointer (SP) takes care of providing the address when pushing data to or pulling data from the stack. The heart of the SP is made out of two pairs of cascaded 191s (IC208..211), preloadable 4-bits binary up/down counters. Because the counters don't have any tristate capabilities, two 541's 8-bit buffers (IC203, IC202) have been added to provide this function.
Why two pairs of 191s, this make 16 bits? Indeed the 6502 has only an 8 bits SP but the 65816 has a 16 bits one. So if I want to emulate this CPU, I need a 16 bits SP. For more, see later.
The SP is completely operational but when in 8 bits mode, the output of the HB is disregarded and the HB Static Address taked care of outputting the address $01xx.

Please notice the 8 pins connectors CON2 and CON3. These enable someone to connect, for example, TIL311 7-segment LED displays to the 191s so the actual pointer can be read at any time.


The Program Counter

The Program Counter (PC) takes care of the address lines during normal operations. The heart of the PC is made out of four cascaded 191s (IC201, IC202, IC206, IC207). Contrary to what one would expect, this PC can count down as well. Why? Just to do something different. Needed? I don't know, time will tell.
Again, because the counters don't have any tristate capabilities, two 541's 8-bit buffers (IC15, IC16) have been added to provide this function. CON1 and CON4 enable the user to read the actual address for that moment.

The two 573's (IC13, IC14) are needed when the PC has to be fed with a new address. For example, in case of a JMP or JSR instruction the new address has to be stored temporarily because, during loading the two bytes, the original address and the next one are still needed. The ID takes care of copying their contents to the 191s at the end of the instruction.


Read the momentary address

If an interrupt has to be served, the CPU must be able to read the output of the PC somehow so the return address can be saved. Two 573s, IC17 and IC18, take care of that, they copy the address at step 1 and output it to the data bus on request.


Temporary address

During the execution of an instruction like "LDA $1000" the CPU needs to output the address $1000 to be able to read the data that is to be found there. We could use the PC or or SP for this purpose but that would mean we had to store the original address first and to restore it after the action. Better it is to have a separata buffer, IC36 and IC41.


The address lines A16..23: the Bank Address

I use two 573 latches and three 541 buffer to generate the address lines A16..23 directly towards the processor port. One 573/541 combination, IC19/25, is used when running a program. You can consider it as the extension of the PC. One combination, IC20/26, is used for accessing data. See it as an extension of the temporary address.
In a 65816 the stack is situated in the first 64 KB of memory. So one idea I copied from "My Own 6502" is to use a 541 to output $00 at the address lines A16..23 when the Stack Pointer is in control of the address bus.


The A, X and Y registers, plus more

Every processor has several registers. Three 573/541 combinations, IC29/32, IC30/33, IC31/34, take care of the registers A, X and Y. CON12, CON13 and CON8 enable one to see the contents of thesse registers when in use.

To be able to emulate the 16 bits registers of the 65816, I at least needed another three 573/541 combinations. But that would enlarge the desing to much IMHO. So I decided to install a 6116 2 KB static RAM. 128 bytes can be used as extra registers. But this feature comes at a price: speed. The 65816 and 6809 can copy the 16-bits version of register A into register X in one go, Big6502 certainly cannot.
Because I want to be able to read, for example, register A and to store its content into the SRAM, I cannot use a Rx line to select the SRAM. So the SRAM has its own direct Ixx line from one of the FlashRAMs to select it. But this also mean we can only use 15 Rx outputs of IC44 as we need a neutral one for the moment we need to read the SRAM, output 15 with the not draw R15 in this case.


The ALU

The ALU, short for Arithmetic Logic Unit, is the calculator of the processor. The 74181 is a real ALU IC and is used by me in My TTL CPU. The problem is that the ALU of the 6502 can handle several types of shift plus the so called Decimal mode and so far I haven't seen any ALU IC capable of doing that. I have thought about using 181s plus an upgrade circuit for those extra functions but that would expand the design way too much. So I decided to use FlashRAMs here as well, IC46 and IC47. The idea is just to program every possible situation into the FlashRAMs.

The needed inputs for the ALU FlashRAMs
As you can see I use two cascaded FlashRAMs, IC46 and IC47, each handling four data bits. Handling eight bits would mean I would need a FlashRAM with at least 24 inputs but I don't know of one that can work with +5 Volt. Cascading two FlashRAMs and each handling just four bits has the same result.

The FlashRAMs need to be able to handle at least the next commands:
- ADC
- ADD
- AND
- ASL
- BIT
- CMP / SUB
- DEC
- EOR
- INC
- LSR
- ORA
- ROL
- ROR
- SBC
As an extra the ALU should be able to deal with branches. When handling a branch, it calculates the new addres using the adress of the opcode plus/minus the ofsset plus two. Four ID bits will cover the above commands.

The 65C02 can clear registers i.e. filling it with zero. IMHO the ALU should output the needed zero. The ALU should also serve as a temporary register when handling data exchange between registers inside the SRAM. So I think an extra ID bit should cover these and future extras.

An extra input bit is needed to deal with the decimal mode. It has to be an extra bit because it is an external input coming from the Flag Register.
After every operation the processor may want to know if the result was zero. In this case the second FlashRAM first has to know whether the result of the first FlashRAM was zero or not. Another extra input.
In case of an addition, subtraction, rotation or a shift to the left, the second FlashRAM needs the Carry of the first one and that one on its turn needs the Carry of the Flag Register. In case of a rotation or shift to the right, the first FlashRAM needs the Carry of the second one and the second one on its turn needs the Carry of the Flag Register. This means two inputs for two different Carries for both the FlashRAMs.

The result (for the moment): - Zero flag
- Carry flag (2*)
- Decimal mode flag
- 4 bits 1st operand
- 4 bits 2nd operand
- 5 function bits
So two 29F010s would do.

Remark: I copied the design from Mini6502 in the first place, that's why you see two 29F020s in the schematic. But these are wired in such a way that you can use 29F010s as well.


The Flag Register

This design is based on the one of My Own 6502 as well. I can imagine that your first impression will be: this is a big design! Yes, it is, and with good reason. In contrary to Mini6502, this design enables Big6502 to update one or more registers in just one step.

The core of the Flag register (FR) is made out of ten 74 D-flipflops. Eight of them are part of the official FR, the other two are needed for other functions:
- The first one I call "Hidden carry". When calculating a new address for a branch or an indexed address, at least one addition or subtraction has to be made. This can result into a carry which means the high byte of the address has to be increased or decreased. The ID has to act on that. But this carry has nothing to do with the Carry we find in the FR. Therefore I created s separate flipflop for it.
- The second one is the "6502 Mode bit. It tells Big6502 when it is in 6502 mode or not. In 6502 mode Big6502 will disregard the Bank Address in so far that when calling a subroutine or when an interrupt occurs, the Bank address will not be pushed to or pulled from the Stack. Using a real 65816 it would be called "Emulation mode". But Big6502 is meant to be a 6502 in the first place, therefore the different name.
The 65816 sets or resets the emulation bit by copying the state of the Carry flag into the Emulation bit. Wanting to emulate the 65816, Big6502 can do this as well. But i decided to set or reset this bit directly as well. For further explanation, see next part.

In most cases these flipflops can be set or reset by either using the Preset or Clear input or using the data input. The Preset or Clear input will be used when there is a specific need for it. These inputs are activated using IC87, a 154, 4-to-16 demultiplexer. Using a demultiplexer has the disadvantage that only one input can served at a given moment. The advantage: four FlashRam outputs can serve 15 inputs, saving one-and-a-half FlashRAM.
For example the opcode SEC (= Set Carry) demands that the Carry Flag is set which means that the Preset input has to be asserted. So far I haven't seen any reason to set or reset the Zero and Negative flag by "hand"; IMHO only the ALU should be responcible for it.
After an addition done by the opcode ADC, the resulting Carry has te be stored. As we have no idea what the value of this Carry is, we need need to use the data and clock input. Another and more obvious use of the data input is when the content of the FR needs to be restored during the execution of the PLP or RTI instruction.
How is the data clocked into the individual flipflops? Ten ID bits tell a flipflop if the value at the the data input has to be clocked or not.

As said before, either data or flags can be stored in the FR. That means we need a mechanism to distinguish between these two sources. This is where IC76, a 157 quadruple 2-to-1 multiplexer comes in. It enables us to choose between:
- Data bit 0 or the Carry flag coming from the ALU flag part
- Data bit 1 or the Zero flag coming from the ALU flag part
- Data bit 6 or the Overflow flag coming from the ALU flag part
- Data bit 7 or the Negative flag coming from the ALU data part
The Break, Decimal and Disable Interrupt flags will only need data input. (bit 5: see later)

IC37, a 245 buffer, enables Big6502 to read the contents of the Flag Register.

In case of a branch the ID needs the state of a particular flag of the FR to decide whether the branch should be taken or not. IC72, a 151 8-to-1 multiplexer, enables the decoder to select the flag needed for a particular branch. The result, BRAD, is fed to the FlashRAMs.

What about bit 5 of the FR to the 151? In a real 6502 bit 5 isn't used, in a 65816 it is. In the original "My Own 6502" I just happened to have a left over flipflop, so why not use it? The original idea was that a free input at the 151 multiplexer enabled this bit to use BRAD to tell the ID if an 8 bits or 16 bits operation had to be performed. IMHO it was a too good idea to omit just to save the halve of a 74LS74 IC.
But writing this text for Big6502 I started to wonder how I would handle a branch when in 16 bits mode? That is when I decided to use this signal as an extra input for the FlashRAMs. Having done that I realized that the connection with the 151 wasn't needed anymore. But changing the board was more trouble then keeping the connection so I left it.

Remark: you probably noticed that the Clear and Preset inputs of the Zero flipflop, IC73B, have been connected to R13 and R14. And the same for the 6502Mode flipflop, IC73A. For both the same reason: making use of some left over outputs. But in case of the Zero flipflop with a thought in the back of my mind: when using the CLR instruction of the 65C02, it is simpler to Preset the flipflop than activating the ALU and related circuits.


Again: emulating the 65816

So far I'm quite unsure if I can simulate it completely at all. Main reaso: the block instructions. But I also never worked with the ABORT interrupt: I have no idea at all that the FIRQ input is good enough for this purpose. We'll see....


Testing the Big6502

One question to myself was: "How do I test the Big6502?". I just happened to have some PC ISA cards with four 8255s on them. These four 8255s are good for 96 input and outputs, presented to the outside world by two 50-pins headers. In my case I only need one of these headers:


In my design the two 8255s behind CN1 are used to simulate the host system. This is done by connecting it to the processor connector. As you can see one 8255 is used to read the first 16 address lines and to handle the data bus. The second 8255 handles the last eight address lines and all the control lines. The reason I teamed the data bus up with the first 16 address lines is that the 8255 has a disturbing feature, one cannot call a bug because it is documented:

The moment you change the data direction of a port, any other port that has been defined as output, will be resetted.

The two ports handling the first 16 address lines are input ports and therefore are not affected by the above behavior when changing the direction of the port handling the data bus.


The outputs of the Instruction Decoder





Programming the Instruction Decoder FlashRAMs

The FlashRAMs of the ID have to be filled with data but how to obtain it? My own idea: I write a program in Free Pascal that emulates every step. So for all instructions at every step every bit of every FlashRAM has te be set or reset. This is saved into an huge table. After having gone through all possible original and new instructions and special signals, this table is read and the result is converted to bytes that on teir turn are fed into various BIN files needed to program the FlashRAMs.


Programming the Static addresses

The idea is to use the same Pascal program but then I will delete all parts except the parts where the Static RAMs are involved. At this point I have to tell the program what value is expected. For example, in step 0002 of the Reset routine I tell the ID to activate the Static RAMs. Here I tell what value each FlashRAM should output. The not used bytes are filled with $FF.


Programming the ALU

For every possible function, special input and the two input nibbles, the Pascal program calculates the byte that has to be outputted.


Remarks

I already mentioned that I wanted to use the Big6502 in combination with a PC-XT motherboard. IMHO it could be done by replacing the 8088 itself by the Big6502. But it would need some additional hardware on the board to be placed on the motherboard. One reason the extra hardware is needed: the first 8 bits of the address bus and the data bus have been multiplexed. My idea is to remove various ICs like the 8288 and various latches and let the Big6502 control the lines directly, for example the MEMx and IOxx lines.





Having questions or comment? You want more information?
You can email me here.