TTL 6502 Here I come

[barrym95838]

Just a simple thought, with no offense intended ... it seems obvious to me that you're doing this for you, since your finished product would have "issues" competing in the real world with a 40-pin DIP for economy and practicality, so the motivating design force should be you, and no-one else. Just follow your heart and see where it takes you ... it's a labor of love, and we understand that.

Mike B.

[Drass]

No offence taken Mike. I appreciate the sentiment. It's simply that I'm not familiar with the 65C02 and may be missing something obvious. My sense is that I won't need these functions in any future builds but if folks use them all the time, then I might rethink that.

Best,
Drass

[barrym95838]

Well, in that case, I really like bra, phx, phy, plx, ply, ina, dea, stz and (direct) ... especially the first five. I only avoid them for legacy reasons in my personal projects. Those would almost make it a 'c02.

Mike B.

[Dr Jefyll]

barrym95838 wrote:

I really like bra, phx, phy, plx, ply, ina, dea, stz and (direct)

I agree examples like these are most important -- examples where the 'C02 introduces additional programming capability, as opposed to additional hardware features. Any computer can use the programming features, but hardware features such as VPB & MLB and STP & WAI are meaningless unless the prospective host computer has wiring that uses them. Even the programming features BBS & BBR and SMBn & RMBn are unlikely to be widely used because they are primarily useful for I/O located in Zero page -- and, as a characteristic of the hardware, many computers don't have the I/O located in Zero Page.

Your goal as I understand it is to make a TTL CPU that will work in as many 65xx computers as possible. I expect there won't be much impact on that goal if you omit VPB & MLB, STP & WAI, BBS & BBR and SMBn & RMBn, so supporting them is perhaps not worthwhile if it requires a lot of effort.

-- Jeff

[GARTHWILSON]

We had a similar discussion at viewtopic.php?f=2&t=2913 .
See also my article, "Differences between NMOS 6502 and CMOS 65c02."

[Drass]

Thanks for the feedback gents. And thanks Garth for the links. Very helpful. Space is at a premium on the boards so an order of priority is useful. VPB and MLB seem lowest, followed by STP and WAI, and then the zero-page-only bitwise instructions. It turns out the more valuable "additional programming capability" instructions require only new microcode rather than new hardware, so that works out pretty well! I'll see what fits on the boards for hardware and otherwise dispense with the rest.

Best,
Drass.

[Drass]

Just a brief update about the 65C02 implementation. I'm happy to report that the Logisim model has now passed Klaus Dormann's 65C02 test suite! It turns out there was plenty of room on the boards to add a Binary Constant Generator (BCG) for SMB/RMB and the Bitwise Branch Test MUX (BBTR) for BBS/BBR. Very happy about that. I have updated the schematics to reflect this and completed also the little bit of re-routing required on the Registers Card.

The new 'C02 instructions are cycle-accurate, for the most part. I had trouble with TRB and TSB which required an additional cycle to set the Z flag (AND of the accumulator with memory) prior to setting or resetting the appropriate bits. I also ran into an interesting challenge with JMP (ind,x). The 65C02 executes JMP (ind,x) in 6 cycles. But, there is potential for two distinct page-crossings: one when adding X to the absolute address in the argument, and another when fetching the high-byte of the target address. In actual fact, either can occur during any one execution of the instruction, but not both. Unfortunately, the sequencer in this CPU requires that each test be performed independently but neither can be omitted since that might take the cycle count to 7. So, the maximum number of cycles is indeed 6, but if neither page-crossing is triggered, then only 5 cycles are executed by the processor.

I'd like to address both these inconsistencies but not at the expense of dedicated circuitry to do so. Maybe I've missed something, so I'll likely come back to this. In all other respects, the processor is cycle-accurate, including correctly replicating the multi-cycle NOPs which Dr Jefyll cleverly exploits in KimKlone (see http://laughtonelectronics.com/Arcana/K ... pping.html).

I have to say, I'm very happy to have made these 'C02 additions, even if quite late in the game. I'm going to spend a little more time looking at the few incompatibilities that remain. If it's not too difficult, it may be worth addressing what I can before moving on to routing the ALU& CU Card. Don't think I would want to make any changes once that's done. We'll see how things go.

Best,
Drass.

[BigEd]

Well done... that's an interesting little wrinkle in the 65C02's instruction set.
I note that http://www.llx.com/~nparker/a2/opcodes.html describes 7C as JMP (abs,X) rather than JMP (ind,X)

What might the cycles be: [Edit: but see next post correcting this]
1 - opcode fetch
2 - first operand (low byte of absolute address)
3 - second operand, add X to low byte
4 - no-carry target in PC is on the address bus, high byte is incremented in ALU in case there was a carry
5a - if carry, this is an unwanted read, reload PC high byte from ALU, next cycle is 5b/6
5b/6 - if no carry, fetch low byte of destination address, increment PC
6/7 - fetch high byte of destination address, update PC to new value, next cycle is a fetch

Because the PC has a 16-bit single-cycle incrementer, I'd expect there never to be a carry when fetching successive bytes using the PC. So I'd expect there's only one source of a page-crossing delay from instruction 7C - the addition of X. Are you sure that's not so?

(We don't have a transistor-level simulation of the 65C02, so I'm not sure exactly which registers and busses might be in play, so the above is a guess.)

[BigEd]

Hmm, checking Rockwell and WDC datasheets, and other tabulations, I see no mention of an extra cycle for 7C at all...
http://archive.6502.org/datasheets/rock ... essors.pdf
http://www.westerndesigncenter.com/wdc/ ... 65c02s.pdf
http://www.westerndesigncenter.com/wdc/ ... 5c816s.pdf
So it looks like cycle 4 must sort out the carry and form the correct high byte for 5.

[Drass]

BigEd wrote:

Well done... that's an interesting little wrinkle in the 65C02's instruction set.
I note that http://www.llx.com/~nparker/a2/opcodes.html describes 7C as JMP (abs,X) rather than JMP (ind,X)

Noted, thanks. I should really use the correct nomenclature.

Quote:

Because the PC has a 16-bit single-cycle incrementer, I'd expect there never to be a carry when fetching successive bytes using the PC. So I'd expect there's only one source of a page-crossing delay from instruction 7C - the addition of X. Are you sure that's not so?

Mystery solved BigEd I think you're quite right. I was in an 8 bit frame of mind and neglected the 16-bit PC incrementer I have on the board! Here is the microcode now (as yet untested):

Code: Select all

(fetch-opcode from the previous instruction)
B := *PC; PC += 1                 # fetch low byte of abs address
PCL := B + X; B := *PC            # Add X to low-byte; fetch high-byte of abs address
PCH := B + 0; USE(IC)             # Add the Internal Carry (IC is set by B + X  above)
DPL := *PC; PC += 1               # fetch the low-byte of the target address, 16 bit increment PC
DPH := *PC                        # fetch the high-byte of the target address
IR := *DP; PC += 1; END           # fetch the next opcode; here PC += 1 is equivalent to PC := DP + 1 as a 16 bit operation.

Note: the operation PC +=1 performs a 16-bit increment of whatever address is on the address bus at the time and places the result in PC. 

Six cycles, no conditional branching. Ironically, this is less efficient than what I had before (since it does not save a cycle if a page is not crossed), but the aim here is compatibility. So this is in fact a better solution. Thanks for your comments BigEd. Very helpful!

While we're here, below is the microcode for TSB <zpg>

Code: Select all

DPL := *PC; PC += 1               # fetch the zero page address
B := *zDP                         # fetch the target byte in zero page
B := *zDP; T := A AND B; SETF(Z)  # Set the Z flag, re-read the target byte
T := A OR B                       # OR in the bits in the accumulator
*zDP := T                         # Store the result back in memory
IR := *PC; PC += 1; END           # fetch the next opcode

Six cycles rather than 5. I require one cycle to set the Z flag with an AND and another to set the correct bits through an OR. Since the busses are in use during the OR, a final cycle is required to write the result back to memory. Can't quite see how to do it in 5. What am I missing?

Cheers,
Drass.

[barrym95838]

The OR is a full-featured OR, but the AND ... I don't have the hardware chops to pull it off, but maybe you could tack on an auxiliary "look-ahead" AND circuit that is only concerned with updating the Z flag (simultaneously with the full OR), and not with saving the complete 8-bit AND result in T?

... just thinking out loud ...

Mike B.

[Drass]

Thanks for the note Mike. I agree, a purpose-built AND circuit may be the way to cut out this one cycle. I'd rather not do that at this stage, but if in the end this becomes the last remaining incompatibility, well then, I'll be very motivated to address it It may even be the case that I end up with a bunch of spare gates on the board, and then this becomes much easier to consider.

In the meantime, I'm going to stop short of a dedicated circuit until I get other items sorted out.

Drass.

[BigEd]

I can't quite figure out how the 65C02 manages TSB - the NMOS 6502 detects zero on the internal databus, which means the ALU has to compute a result and place it on the IDB in order to affect the Z flag. The ALU itself does compute AND and OR in parallel, which it needs in order to compute SUM, and in principle those intermediate results could be brought out, or a zero-detect function could be squeezed in. What I'm saying is that the 65C02 must have a different datapath arrangement, and possibly must have two zero-detect functions. It would only cost an extra 8 transistors.

[ttlworks]

TSB,TRB:

When freezing the B latch after reading the Byte from memory by making "creative use" of the /ML signal,
the AND operation which modifies the Z flag could be done in parallel with the next instruction fetch.

[Drass]

ttlworks wrote:

the AND operation which modifies the Z flag could be done in parallel with the next instruction fetch.

Of course! The ALU is idle during the opcode fetch so we can use it to set Z at the end of the sequence. Every ALU instructions ends this way - perform the ALU operation and fetch the next opcode. Thanks Dieter! Nice catch.

Now, if the clock to the B data latch is inhibted on every write cycle, then B is preserved across the store operation and the code below should work:

Code: Select all

DPL := *PC; PC += 1
B := *zDP
B := *zDP; T := A OR B
*zDP := T
A AND B; SETF(Z); IR := *PC; PC += 1; END

Latching B on write cycles is of no value anyways since all we get is the very value we are writing out. It can be safely omitted. And that makes it 5 cycles .

Mission accomplished. A fully cycle accurate 65C02. Gotta love this forum. Thanks guys.

Best,
Drass.