6502.org

I've been working on an application that requires exact cycle counting and have found a small error in the Kowalski simulator.

While the WDC documents are not consistent across many versions of the W65C02 datasheet, it does elude in many that the zero page indirect Y addressing mode will add 1 clock if a page boundary is crossed while computing the target address. I confirmed this using the Visual6502 simulator.

So an LDA (zp),Y instruction will take 5 cycles to complete with no page crossing and 6 cycles if there is a page crossing. The Kowalski simulator calculates 5 cycles regardless of page crossing.

Here is my test code: This is the Visual6502 trace: I know this won't affect many projects, but wanted to share in case someone found it useful.

Daryl

Interesting. I do use the cycle count function now and then, but never noticed this in the past.

I took a quick look at the source code for the simulator. I'm not positive, but it may not be accounting for ANY page crossing adjustments (except for branches, which do work correctly). It may take some time, but I will try to verify each address mode against the Visual6502 to verify that.

Daryl

Do you have the tools necessary to build a revised version of the simulator?

That would be great. Maybe we could look at a few of the other bugs in it if someone can build it. Breakpoints for one don't work very well...

That's true for LDA ADC CMP and many of the others. But in the case of a write -- STA indirect Y -- the extra clock occurs whether or not a page crossing occurs. An important piece of trivia, especially if someone does dig in and try to fix the simulator.

No, not unless there is a free C++ compiler somewhere I can use.

Daryl

Note 1 from the instruction timing chart in the WDC 65C02 manual (2004 version) says:
"1. Add 1 cycle for indexing across page boundaries, or write. This cycle contains invalid addresses."

So yes, any write will contain the extra cycle needed to adjust the address pointer. It's just the read instructions that I can see.
So far, [LDA abs, x], [LDA abs, y], and [LDA (zp), y] all need an extra cycle if the page is crossed. [LDA (zp, x)] does not as it wraps back around within zero page. ADC, AND, BIT, CMP, EOR, LDA, LDX, LDY, ORA, SBC all need to be tested. With ADC and SBC, the decimal mode flag also needs to be considered, and I believe the Kowalski simulator adds a cycle correctly.

Daryl

I have managed to hack together a VC++ tool set and have compiled the 1.2.6 version from the sources. If a couple of you can try to run the attached in your systems, that would help me ensure the tool set is working correctly. I'm a novice with C++ and the whole Windows build environment, so I make no promises to fix anything. I will try to update the cycle counting, once I get them documented better. After that, we can work together to make other changes or enhancements.

Please let me know if this works on your system. Unzip to a any folder. Run the 6502.exe. Load the "min_mon.asm" and assemble and Simulate. Open the Output window and press RST on the tool bar. You should see the EHBASIC start screen. You may need to set the input/output window to $F000.

Daryl

FYI, the current executable that may be downloaded from Mike Kowalski's website is version 1.2.12. This version fixes several bugs in conditional assembly, listing format and other items. I have contacted Mike via E-mail to see if the source for 1.2.12 is available.

BTW, I downloaded and tried out your compiled version. It appears to be functional and is able to assemble the firmware for POC V1.1, with the only errors coming from conditional assembly bugs that were in versions 1.2.8 and older.

It would be great if we could get the latest source. Thanks for chasing that down!!

Daryl

Be on the lookout for irregularities like this, which almost all documents omit.

Thanks Jeff. I was planning to use the Visual 6502 as a base reference. But, it looks like I may need to consider the 6502/65C02 differences as well when determining cycle adjustments. I will most likely create a table to document all options.

Daryl

Would it make sense to make a list of bugs we might be able to fix?

Sure, but lets wait to see if we can get a more recent source to start with. Some bugs may have been fixed, such as BDD's conditional assembly.

I'm hoping we can get the 1.2.12 source.

Daryl