It took while, but I now have a first pass of the 65816 in Logisim! (pic below)
It's a beast, that's for sure, but it looks like it will still make 100MHz!
At least that's the theory -- the reality of laying all this out on impedance-controlled PCBs is sobering to say the least. But be that as it may, I'll just press on for now and we’ll see how it all works out in time.
To recap, the new architecture required the following additions:
- A 16-bit adder/incrementer in the ALU (this is an 8-bit adder followed by an 8-bit carry-select incrementer for the high-byte),
- A 24-bit carry-select incrementer on the address bus,
- 16-bit WriteBack and flag evaluation stages (Z flag evaluation is pipelined across two-stages),
- 16-bit C, X, Y, S, and D registers,
- Selectable 16 and 8-bit busing and muxing to shuttle values around,
- Mode-dependent register-widths and interrupt vectors,
- Initialization of various registers to appropriate values on reset,
- A "Loop-on-Carry" function to support the MVP and MVN opcodes,
- Tighter encoding of microinstructions to control all this (with associated decode logic).
With that, I'm happy to report that the CPU now supports cycle-accurate 65816 operation with just a few exceptions:
- The (dir,x) and dir,x addressing modes take an extra cycle if DH is non-zero,
- The long,x and [dir],y addressing modes take an extra cycle if a bank boundary is crossed or if a write is performed,
- Decimal Mode takes and extra cycle.
The extra indexing cycles could be overcome with a true 16-bit adder, but at the expense of more hardware and a longer cycle. The same is true for Decimal Mode, where a longer cycle could accommodate a separate decimal adjust circuit in series with the binary adder. In both cases the extra cycles occur relatively infrequently, so it makes more sense instead to forgo compatibility and keep to the faster clock-rate. The CPU will both perform better and require less hardware as a result.
Overall, I'm quite happy with the where this design is at the moment. I have completed "unit testing" on the current model (by which I mean that every instruction has tested correctly at least once). The next step is to run more comprehensive testing using some sort of suite. I'm not planning anything like the Dormann suite, but investing a little time on some test code is sure to pay dividends down the line. If anyone has some 65816 code that can be reasonably adapted to run as part of such a test, that would be very helpful. Complete programs with lots of I/O are probably not great candidates for this. But a compute-intensive code fragment whose result can be tested against a pre-computed value would work very well.
Many thanks to Dr Jefyll, ttlworks, BigEd and Hoglet for their help in getting to this point. As always, all suggestions welcome.
Cheers for now,
Drass
P.S. I thought it might be interesting to mention a few words about the MVP/MVN opcodes. As one might guess, these opcodes move one-byte when executed, and are then "re-executed" for each remaining byte to be moved. This is can done efficiently by inhibiting FetchOpcode for as long as the move is in progress. Meanwhile, the X and Y registers are incremented (or decremented for MVN) and the C accumulator is decremented on every pass. The end of the loop is triggered when C wraps from "0" to "FF", which conveniently fails the “loop on carry” test. The final subtlety here is that PC must be restored on every iteration so the operand bytes can be re-read as normal. (Yes, this is done redundantly even though the operands don't change. The FetchOpcode cycle too is executed redundantly, even when the operation is inhibited. The net result is that the opcode executes it's full contingent of seven cycles for every byte moved). The rationale for this rather awkward implementation is simple: it requires a minimum of specialized hardware. I briefly contemplated an enhancement to skip the re-reading of operands and save two cycles per byte. However, that’s quite messy for the pipeline, so I decided to leave well enough alone and stick with the stock implementation.
