6502.org

I wanted to try to summarize where I'm at with these aptly named UFOs - particularly the "unstable" ones. I've learned more about these in the past couple of weeks (BigEd and drfiemost shared some amazing information here - viewtopic.php?f=8&t=4164), and I must say, my original hope of finding some clear and deterministic behaviour for these beasties has proven to be a little naïve. There is just too much variability to contend with. The reasons are fascinating, but the net result is that at best, any one behaviour will work in some instances and fail in others. In fact, no 6502, commercial or otherwise, is immune here. So the good news is that we are in effect doing no worse by simply settling on one set of "common" behaviours and calling it a day. And this is exactly what I have chosen to do. I'll just mention, though, that the "Stable" opcodes not listed below (including LAS $BB) all do behave as documented and are cycle accurate. The "unstables", on the other hand, I have decided to treat as follows:

1) (& H + 1) Group: AHX($$9F, $93), SHX($9E), SHY$(9C), TAS($9B) - these opcodes exhibit two instabilities - the (& H + 1) operation is "sometimes" dropped and the high-byte of the target address is corrupted on page-crossings in some cases. My own tests on a VIC20 seem to show that page-crossings that stay within the lower nibble of the high-byte appear to work correctly, but it's hard to be definitive about this. In the end, I have decided to honour the (& H + 1) construct in all cases and ignore any page-crossing anomalies.

2) MAGIC Constant Group: ALR($4B), ARR($6B), XAA/ANE($8B), LXA ($AB) - these are dependent on a so-called MAGIC constant which in fact varies across systems and in many cases even within specific systems at different times. Some claim that of these, only $8B and $AB are in fact unstable, but my own tests showed differences do exist with the others as well. There simply seems to be no right answer for the value of MAGIC. So, I have somewhat arbitrarily chosen to use specific values as a convenient and plausible solution knowing full well this will not work in all instances. With the chosen values, these opcodes reduce to the following functions:

• ALR($4B) = A <- A & (CONST | #IMM), A <- LSR A, where (CONST = $00) becomes A <- A & #IMM, A <- LSR A
• ARR($6B) = A <- A & (CONST | #IMM), ROR A, where (CONST = $00) becomes A <- A & #IMM, ROR A
• XAA($8B) = A <- (CONST | A) & X & #IMM, where (CONST = $FF) becomes A <- X & #IMM
• LXA($AB) = A,X <- (CONST | A) & #IMM, where (CONST = $FF) becomes A,X <- #IMM

As a side note, tests on my VIC20 showed that $8B seems to remain stable at $FF through thousands of iterations, but that certainly has not been what others have seen on other systems. In addition, with LXA($AB), the VIC20 showed $EE as a stable value, rather than the more common $FF which I have chosen to use.

Despite all this, I do feel I've landed in a good place: cycle-accurate and reliable operation for the 96 stable undocumented opcodes, and reasonable expectations regarding the 9 "unstables" that remain. Namely, that software that properly accounts for the variabilities in the "unstables" will run without a problem. This can be done, as the excellent paper that drfiemost shared advises (http://csdb.dk/release/?id=143981), by not reliying on a given value for MAGIC and by keeping page boundaries well away from "& H + 1" instructions. Otherwise, all bets are off on this as well as other 6502 systems.

Time to move on to other challenges

Thanks for summarising! As you say, the paper "No More Secrets" by Groepaz is very good indeed - thanks to drfiemost for linking it.

I was reviewing the critical-path analysis on the TTL CPU as part of getting ready to finalize the design when something jumped out at me. It turns out that of the 132ns on the critical-path, fully 51ns are spent fetching the next microcode instruction from ROM. Of course, this is to be expected, but nearly 40% of the total delay spent just waiting for microcode! Suddenly that seemed like way too much, so I decided to look for an alternative.

I had thought of replacing the ROMs with fast RAMs, but that requires cumbersome bootstrapping and in the end does not get at the root of the problem. Then it occurred to me that the datapath is completely idle while we wait for the microcode that drives it. And the reverse is also true - the ROMs are merely holding a value fixed when the datapath is active. If we can overlap these operations and pre-fetch the microcode, we would see a massive improvement in speed! Now this was too compelling to pass up, so despite being in a wrap-up mode, I found myself saving a version of the files and starting down the path to retro-fit a single-stage microcode pipeline into the design.

Dr Jefyll had in fact mentioned something akin to this early in this whole process, but frankly it went way over my head then. Somehow this now looked quite feasible, ignoring for the moment pcb density an layout considerations (and Dr Jefyll was once again on-hand to sort me out on a couple of issues!). After all, with the opcode in the IR, it seems simple enough to fetch the next micro-instruction and latch it into a Micro-Instruction Register (MIR) ready for use in the next cycle.

The first cycle after the opcode-fetch is clearly going to be a problem since we don't yet have the opcode for the pre-fetch. A quick scan of the 6502 and 65C02 instruction sets showed that nearly all opcodes perform exactly the same function in that initial cycle, namely to fetch the opcode operand with the address at PC and increment PC. That being the case, pre-loading the MIR with this "default" micro-instruction would satisfy most of the requirement, and leave only a few exceptions to handle. Also, re-working the microcode so that an "all-zeroes" control-word produced this function meant that a set of 74'273 registers could be cleared during the opcode-fetch to achieve the desired result.

As for the exceptions, there are only three:

1) We need to inhibit the incrementing of PC for any single-byte opcodes
2) We need to replace the current instruction with an opcode-fetch for 65C02 single-cycle NOPs
3) We need to generate an opcode-fetch in the next cycle of a branch if the branch is not taken

Let's look at each in turn:

First, single-byte opcodes have the form $x8 or $xA, meaning that a three input gate can catch them all. We don't have to worry about RTS($60) and RTI($40) since they replace the value of PC anyways. Similarly, the KIL($x2) illegal opcodes certainly need no protection from incrementing PC. This was looking very promising. It turns out the board already has logic for inhibiting +PC on the first cycle of an interrupt, so a couple of gates was enough to have it to do the same for single-byte instructions.

Next, single-cycle NOPs are $x3 and $xB opcodes on the 65C02, except that WAI($CB) and STP($DB) need to be excluded from this list (and included in the single-byte list above). A little more glue logic would be needed to trap these and, if detected, to replace the "default" micro-instruction with a fetch-opcode. That replacement requires only that we enable a couple of control bits - "IR.LD" to load the IR and "END" to reset the Q ROM-index to zero, all of which can be managed with just two OR gates on the outputs of the MIR.

Finally, interrogating the Branch Test Result (BTR) in the first cycle of a branch instruction was straight forward. All branches are of the form xxx1-0000 so once again fairly simple logic can detect them. If the branch test fails, a "FETCHOP" flip-flop can be set to generate a fetch-opcode micro-instruction in the next cycle (as above but for the next cycle this time).

With that done, I could then delete the first step of every opcode in the microcode, so that the micro-instruction for cycle 1 would then sit at index location 0 ready to be "pre-fetched". And with that, the basic engine was ready to go! The mechanism is surprisingly simple: clear the MIR on an opcode-fetch and latch the next micro-instruction at the end of every cycle. The micro-instruction is then ready to go at the start of the new cycle and the ROM delay is gone!

But, I needed also to deal with page boundaries during address calculation. This was accomplished before by incrementing the Q index by 2 if no page-boudary was crossed. Doing so had the effect of "skipping" the micro-instruction that adjusts the high-byte of the target address. Unfortunately, we don't discover the need to "skip" until very late in the cycle, at which point any progress in pre-fetching the microcode to that point is lost and we must begin again (which in effect puts the microcode fetch right back on the critical-path, this time at the end of cycles, rather than at the begining). Something had to be done ...

For branches, if adding the branch offset to PC does not cross a page, we can set the "FETCHOP" flip-flop for the next cycle and end the instruction early (just as we did above when a branch test failed). This can happen very late in the cycle with no adverse impact on the critical-patch. FETCHOP simply clears the MIR on the next cycle and then applies the required control bit transformations. There is no delay penalty incurred.

For indexed addressing modes, on the other hand, we need to insert an instruction into the stream to increment the high-byte, and then continue on to complete the memory read or write as the case may be. So, rather than "skipping" to avoid an operation, we introduce an additional cycle to execute it "on the fly" only if necessary. To do so, we can stall the Q counter so the same "low-byte increment" micro-instruction is re-fetched on the next cycle, but this time, it is transformed to a corresponding high-byte increment (DPL changed to DPH, etc.).

However, since these address operations go through the ALU, introducing gates at the outputs of MIR for those control signals would hit the critical-path. Instead the required micro-instruction is presented to the MIR inputs through 74'541 buffers with no delay penalty. The ROMs outputs which normally go to the MIR are simply disabled in that case, so the MIR obligingly loads the inserted instruction at the right time and then goes back to regular programming thereafter. Once again, the required control-word ends up in the MIR ready to go at the beginning of cycle without delay, which is the objective.

And that, so far as I can tell, does the job. After some careful counting, I estimate the pipelined CPU will run with a cycle time of just 69ns, or at a 14.4MHz clock rate! That's nearly a 100% improvement over the roughly 7.5MHz the non-pipelined version could manage. So this certainly seems like a very worthwhile effort.

I've tested all of this on the Logisim model and all seems to be well. Frankly, I'm amazed at the substantial payback for what is, in the end, a fairly contained set of changes (which albeit do come at the cost of adding yet more ICs to already very dense boards). I'm hoping I have not made some unfortunate error here as it does seem a little "too good to be true". Nevertheless, it sure is exciting to contemplate a TTL 6502 which runs as fast as its present day commercial counterparts!

Now I wonder how I will ever get this thing built

Very nice analysis and result! I think the original 6502 designers went to some pains to reduce cycle count with respect to the 6800 which they'd previously worked on. It's actually typical, for a successor CPU to have additional cleverness, because the predecessor CPU couldn't take the risk and the engineers might not have fully understood what was possible - the challenge being to make something which works! What's not quite so typical is for the successor CPU to be done by a different company, but it does happen.

We have noticed using visual6502 that the 6502 has a little predecode logic which inspects the databus value towards the end of the fetch cycle, in order to set up the 2 or 3 cycle branch instructions. The 6800 takes 4 cycles for a branch. The 6502 steals a few nanoseconds from the memory access time to reduce that dramatically.

Edit: but see my following post below

Thanks BigEd. I'm very happy with the result.

Interesting to see pre-decode logic on the 6502. Presumably, the branch test logic gets going before we've even figured out the opcode is a branch ... is that what's happening? Thankfully, the TTL version can afford to wait until the next cycle before taking any action. Much easier .

I need to revisit this topic of the predecode logic - I've been exchanging thoughts and notes with Jeff. I think there is something interesting going on, but I no longer think it has anything to do with the branches! I do still think that the 2 and 3 cycle branches were an interesting innovation and there might be something to say about the implementation...

Edit: see my post in a new thread here.

I had to look back to check ... I posted this on March 20th: It's hard to believe it's nearly 4 months later! Additions since then:

• 65C02 instruction set
• 65C02 plug-compatible pinout
• NMOS undocumented opcodes
• NMOS and CMOS compatible BCD flags
• Microcode pipeline with 14MHz clock-rate

The design now feels like it's reached a nice milestone: a cycle-accurate, pin-compatible 6502/6510/65C02 TTL processor capable of modern clock-rates. The instruction set is selectable on distinct ROM banks and various other jumpers do the rest. If all this works, the CPU should be able to plug directly into either NMOS or CMOS 6502-based computers and run without any appreciable difference ... that's pretty amazing to me, and well beyond my original goals. (it's also more than a little amusing to think that all this work is merely to replicate what the original chip does but in a much larger and cumbersome package. )

I finally had the opportunity to go back and re-route the Registers Card. Ironically, it doesn't look very different, but there are now five additional ICs on the bottom layer and every new trace was a challenge to sort out! Happily, it all still fits on a Eurocard pcb. Pic below: The ALU & CU Card has even more ICs (about 20 actually) but luckily many are smaller gates and selectors rather than the much larger registers and buffers. And there are no pinout headers, resistor arrays or large DIP packages here. A rough layout (below) suggests this card just might be ok as well, which would be pretty great. The two cards would then stack together with all external connections on the top card. It will still take while to route the second board so time will tell how things will turn out.

Cheers for now,
Drass

Since Drass is away for the moment, I now remembered to have three kludges
for OurCPU (pun intended) in the drawer, which might be getting outdated
when Drass posts his new set of schematics.

So I think I just should place them here.

Wikipedia:
A kludge is a workaround or quick-and-dirty solution that is clumsy, inelegant,
inefficient, difficult to extend and hard to maintain.

Oh, and please don't expect that stuff to be free of errors.

;---

First kludge: SPI.
Some ideas about implementing a minimalistic\crude SPI interface into the CPU
by using as few components as possible.
SS (slave select) would have to be generated by an additional I\O port, sorry. ;---

Second kludge: Kludge24.

Many years ago, I did build that M02 TTL CPU.
The instruction set basically was "a poor man's 65816" without the 16 Bit
and without the E flag...
but it had a 24 Bit address bus, and most of the 65816 instructions to make use of it.
And it was possible to make any of the 256 pages in the lowest 64 kB of memory
work as the "zero page".

Kludge24 is a PCB which is supposed to be plugged to OurCPU,
giving it a non_multiplexed 24 Bit address bus and most of the M02 instruction set
(microcode not included, sorry).

It's just an "extension", means that OurCPU still will be able to work without it.
Edit: fixed some errors in the kludge24 schematics.

;---

Third kludge: switching to another microcode set by software.
It's just a "crazy" idea.

We happen to have 4 address lines at the microcode ROMs which are tied to jumpers.
When using a latch instead of the jumpers (plus maybe the WDM instruction),
it might be possible to switch between NMOS6502, 65C02 and Kludge24
instruction set during runtime by software within two clock cycles or such...

Oh, and I also happen to have a crude block diagram of the CPU.
So I'm just posting the pictures before they become obsolete
by the next revision of the CPU.

I wanted to drop in just for a moment to say thanks Dieter for posting. The block diagrams look great!

As it turns out, the data path looks correct, even after the microcode pipeline changes. The CU block diagram will need only minor changes. I'll review and update and add them to the schematics when I get a chance. Wrt, the "kludges" - after the quick "recon" layout, it looks like there may still be room on the ALU & CU pcb for an SPI interface (which is a great idea). I think also I can manage a "Kludge24" header to fit the optional 24 bit address bus expander as you suggest. It would be a great follow-on project.

Many thanks as always.

Best,
Drass

Drass,

I'm sorry that this is a mundane query, but can I ask: what tolerances you are working to? I see you have 4 traces routed between 2 pins on the PLCC44 socket. This must make for some pretty fine traces and clearances! Also, who will be making up the boards for you?

Good luck with your project. It looks like a fantastic undertaking!

Thanks Aslak3, and good eyes! That's the tightest spot on the whole board.

The specs are from OSHpark.com for 4 layer boards: "Minimum design rules are 5 mil trace clearance, 5 mil trace width, 10 mil drill size, and 4 mil annular ring."

As it happens, I'm using 6 mil width, 5 mil clearance and a 13 mil drill size most of the time (not sure why, but so it is). The traces between the two pins of the PLCC44 socket are in fact 5 mil width/5 mil clearance - just taking OSH Park at their word and hoping for the best. I have very little prior experience with this (as in none) so I'm very open to any and all suggestions on all matters PCB! Please don't hesitate to point out anything that looks dodgy. Chances are I am not aware of it .

Btw, here's a close-up of the section in question:

Dieter calls it "the need for speed" and I guess I'm hooked.

Looking at it, the microcode architecture makes the ROM fetch-time the upper limit on speed. Using the microcode pipeline, the CPU is able to overlap the time required to fetch a microcode instruction with the processing time required for the rest of the circuitry. In perfect world, the two intervals match, resources are used optimally, and the CPU is going as fast it can.

Now, it takes 5ns to bump a counter to index into the ROMs, 45ns for the ROMs to respond and 2ns setup-time to latch the data into the Micro Instruction Register. That's 52ns, but just for fun, let's call it an even 50, and set 20MHz as the ceiling on this CPU design. The question is how close can we get to this theoretical maximum? The microcode pipeline delivered 69ns. Let's see where we can get to with a few more optimizations:

First up, CBT Parts: some time ago, Dr Jefyll suggested these in the context of bi-directional busses. I ended up not using them at the time, but I well-remembered their amazing propagation delay - 0.25ns tpd! Take the 74CBT3245 Octal FET Bus Switch, for example. The enable-time is roughly the same as the equivalent 74AC245 part. But once enabled, the CBT version is effectively a wire and lightning fast. The key (as Dr Jefyll explained) is to use it in situations where the "enable" signal is available a few nanoseconds before the data is ready to pass through the switch.

As it turns out, the outputs of the ALU are one such situation. Three distinct buffers are used to select between a shift, a binary or a BCD result. The control signals are ready early in the cycle, but the data goes through the ALU and arrives much later. So, the FET switch can be set up well in advance and the data flies through when it arrives. Jeff also suggested that a 74CBT3251 might replace a 74AC151 under similar conditions. Luckily, there is a selector on the board that's perfect, a '151 used for the V flag evaluation, and it's also on the critical path. The total savings from these two things: 12.5ns.

Now, by far the slowest path through the CPU is the BCD-adjust logic. However, the BCD operation can be spread over 2 cycles, so it's really the ALU binary path that's critical. As it happens, the two paths share the high-nibble adder, which saves a chip, but forces the binary carry through unnecessary logic. Inserting a dedicated BCD adder separates the paths, and removes a further 6.5ns from the critical path. Add that to our previous balance and the ALU is 19ns faster - right on target for our theoretical limit!

Now, as much fun as this is, a grain of salt is in order. The tolerances here are small, and tiny variances can throw the whole thing off - and by a wide margin. The savings above are significant, but the absolute numbers will only bear out once the CPU is built. For now, I'm very happy that the clock-rate might be pushing 18MHz. At the same time, 1-cycle NMOS BCD is also faster, and if enabled may get as high as 16MHz. Time will tell.

Cheers for now,
Drass.

Run it at 5.5V! And with an icepack! This should be wonderful - a 20MHz 6502 in discrete logic.

To put that into perspective:

MyCPU2.3 is rated 1.16MIPs at 8MHz (feels like one machine cycle is three clock cycles ?),
and a clock speed of 10MHz might be possible.

In OurCPU, one machine cycle is one clock cycle, like in the 6502.
Wikipedia says, 6502 is rated 0.43MIPS at 1MHZ.
So if OurCPU would make 16MHz "typical", that would be 6.88MIPS...
in other words: ca. 5.93 times the speed of a 8MHz MyCPU2.3.

Since it was Dennis who had talked me into having a homepage many years ago,
I hope he doesn't mind...