Hi Michael
Good to see files appearing in your github repo!

I collected some 6502 test suites and ROMs here. Wolfgang Lorenz' is exhaustive (for 6502, rather than 65C02), but is set up for a C64 environment. Of course in principle it could be ported.

Cheers
Ed

Thanks very much.

Just finished updating the BCD mode test bench, but will also take a look at using the Appendix B test program from Bruce Clark.

_________________
Michael A.

It's probably impossible, though, to write a definitive test. This particular bug illustrates the point. 'LDX abs,X' disguised as 'LDX abs' may appear to work fine in some particular cases, as it did in mine (e.g. if X happens to be 0 beforehand, or 'surrounding' memory locations happen to contain suitable values, depending on the test). It may even depend on accidental timing within the FPGA (type, speed, compiler used, settings, etc.). Tricky stuff.

It is tricky. The whole column $E, odd rows are abs,x. Except for opcode $BE which is LDX abs,y, not an abs,x. I will have to check my decodings as well as I not noticed this in my recent adventures...

Agreed - both tricky and practically impossible! This is why, comparing the cores which people have written, one should be interested in the clarity and simplicity of the source as well as the track record and the support. A core which correctly runs a slew of console games has something going for it, as does one with a visible history of (not too many) bug fixes.

(The test suites I catalogued are all meant for software emulators, which suffer from different kinds of bugs. Still worth passing them, if they are easy enough to run. If only.)

Of course, for a 65C02 core, not a lot of choice!

If you look at the WDC65C02 datasheet though, $BE is LDX abs,x. Is this another typo?

Always use the latest WDC datasheet. Even then, be wary. I use this page.

And here it is.

You're not wrapping DP,X and DP,Y addresses. E.g. 'NA' should become something similar to :

always @(*)
case (NA_Op)
pNA_DPX : NA = {8'h00, AL[7:0] + AR[7:0]};
pNA_DPY : NA = {8'h00, AL[7:0] + AR[7:0]};
default : NA = AL + AR;
endcase

My chunk of test code now seems to work okay. Will do some more testing, e.g. trying to find how far I can push the clock ...

Windfall:

Thanks again. I found that very case late last night while working on the second core's address generator testbench, but hadn't a chance to flow it back to the core you are working with. The solution I applied was:

always @(*) NA <= AL + AR;

assign AO = ((NA_Op == pNA_DPX) | (NA_Op == pNA_DPY)) ? {8'b0, NA[7:0]} : NA);

Don't know if that will provide a higher performance level than what you implemented. In the new core, I've separated out the address generator into a module in order to implement a registered address output, i.e. a memory address register (MAR). When I found the wraparound issue, I attempted a solution as you describe. That solution essentially synthesizes to an 8-bit adder and a 16-bit adder followed by a multiplexer. Checking its implementation resulted in missing the 10 ns period constraint. I then changed it to the above solution, and I got an implementation that would meet the timing constraint.

I will make a correction to the M65C02_Core.v file using the approach that appears to maximize performance without resorting to SmartXplorer or MPPR and update the github repo.

Once again thanks. Any chance of getting your test code posted as a compliance diagnostics tool? I have been looking for a more comprehensive set of assembler files for testing the cores that have known good performance.

_________________
Michael A.

All:

Just as a point of calibration, the M65C02 core is targeting the original WDC 65C02 instruction set. The W65C02S instruction set in the datasheet that Ed referred to uses an updated instruction set that is a combination of the Rockwell 65C02 (WDC 65C02 plus BBRx, BBSx, RMBx, and SMBx) plus several extensions included in the WDC 65802/65816 processors. I have stayed away from using the WDC synthesizable W65C02S data sheet as a reference for the M65C02 core, and concetrated more on other data avaiable here, at bitsavers.org, and in "Programming the 65816" by Eyes and Lichty.

In the near future, there may be a reason to standardize on the W65C02S instruction set, but for the moment I am concentrating on trying to establish a trusted 6502-compatible logic core and a set of trusted test programs (assembler and Verilog testbenches) for validation and verification of extensions.

_________________
Michael A.

Better still. It can now use the same adder, and simply mask the result. You may want to try {NA[15:9], 1'b0, NA[7:0]} though, since NA[15:9] will be zero anyway.


Not really, there are many prerequisites, including external hardware.


It would be nice to have the Rockwell extensions eventually, though. I don't think I have seen any software that requires them, but it's just a couple of instructions, really.

It would be good to reach a common set of instructions for a base synthesizable core.

_________________
Michael A.

Certainly.

As far as I know, though, the opcodes of the Rockwell instructions have never been used by anyone else, so should be (multi-byte) NOP everywhere else. Nevertheless, adding the extra instructions may perhaps bring down the performance in unexpected ways ... Still. Ideally you'd have a pin to enable them, or two designs.

WDC uses them. When they added them--I'll estimate it was in the mid-1990's--they added a "B" at the end of the part number to indicate they had the bit-test-and-branch istructions (BBSx and BBRx) plus the ones for setting and clearing individual bits (SMBx and RMBx); but later they took the B back off, with the logic that they'll all be that way anyway so there's no need to specify.

_________________
http://WilsonMinesCo.com/ lots of 6502 resources

Yes, for those same instructions. Not something else. Only the 65816 uses them for something else, but that's not a 65C02.