On the 6502, JMP (ind) appears to use 5 cycles and does not cross a page, it wraps back to the first byte of the same page. On the 65C02, it takes 6 cycles and will go to the next page. I found no references to additional cycles being needed as they all use 6 vs. 5.

The JMP (inx,x) is only a 65C02 instruction, and takes 6 cycles. The WDC manual does mention add 1 cycle for page crossing, but the 65C02 tutorial on this website does not mention it. I will add this unless someone else can prove otherwise.

As for unused 65c02 opcodes. The Simulator treats them all as an illegal opcode and stops the simulator.

For the 65C02, I could add support for the cycles and bytes used treat them as a NOP code. If I do that, I should consider adding an option to select how they are treated. I don't want to venture down the 6502 road though... I'll just let the sim stop.

Thanks Jeff!

Daryl

_________________
Please visit my website -> https://sbc.rictor.org/

From Jeff's previous comments, I have added references to the indirect JMP opcodes and corrected the cycle counting. updated files are attached.

Thanks Jeff!!!

Daryl

_________________
Please visit my website -> https://sbc.rictor.org/

I've just looked at the Dormann 65C02 tests running with the 6502 bus protocol decoder, and I don't think page crossing adds an extra cycle to JMP (IND,X) (opcode 0x7C). It seems to take 6 cycles regardless.

R65C02



G65SC12



The addresses are slightly different between the processors because they were running different variants of the Dormann 65C02 tests.

Dave

It really sucks having so much disparity on the documentation. Ok, the JMP (inx,x) will get changed back to 6 with and without page crossing.

Thanks Dave!

Daryl

_________________
Please visit my website -> https://sbc.rictor.org/

Mike Kowalski has responded to my E-mail message about the source code. He has posted everything at Github.

_________________
x86?  We ain't got no x86.  We don't NEED no stinking x86!

Awesome! Thanks for the link. It says we can use the free VS 2017 to compile it. I'll give that a try!

Daryl

_________________
Please visit my website -> https://sbc.rictor.org/

A most excellent result! Thanks for reaching out BDD.

And thanks, Daryl, for taking up the challenge of moving the code forward.

I could not get the MS Visual Studio 2017 Express to compile the source. I then tried it with VS 2008, and was successful, after adjusting 1 parameter in the SaveCode.cpp file. I then made all the modifications that I had made to version 1.2.6.1 (I did not find any modifications to that part of the source in 1.2.12). It also recompiled without error.

My next step was to run the program and try to assemble the project I had been working on. I had several errors. The biggest one was this version of the source has the .BYTE command commented out. The original compiled version 1.2.12 seems to accept the .BYTE command. I'm not sure if Michal was working on some changes, but this is peculiar. If I uncomment that line, I get another error when assembling my 6502 source. This time, it does not like a variable label named "byte". Again, the compiled 1.2.12 does not complain as it can distinguish ".byte" from "byte". I need to try to figure out the source code to see why these changes were made.

I'll keep you all informed as I go.

Daryl

_________________
Please visit my website -> https://sbc.rictor.org/

Get the Polish-to-English dictionary ready!

_________________
x86?  We ain't got no x86.  We don't NEED no stinking x86!

Good to hear Daryl has picked up the task to apply some fixes to Kowalski's IDE.

There are some bugs in the simulator I want to bring to your attention.

6502 mode:

BRK
When the processor status is pushed to the stack the unused bit (bit 5) is clear (0). It should be set (1). PHP correctly stores the bit as 1.

65C02 mode:

All undefined opcodes stop the simulator with a message. They should execute as NOPs with various length and cycles.

BIT #
BIT immediate alters the overflow & the sign bit in the status register. Opposed to the other addressing modes of the BIT opcode only the Z flag should be modified.

TRB/TSB
test and reset/set bit modifies the N & V flags in the processor status register. Similar to the BIT immediate opcode only the Z flag should be modified.

ADC/SBC decimal
The N & Z flags should be based on the actual result in the accumulator after the decimal correction. They seem to be based on the accumulator before the decimal correction like on the original 6502.

_________________
6502 sources on GitHub: https://github.com/Klaus2m5

Thanks Klaus,

After searching through the forum for "Kowalski", I have dug up quite a few items, including the BRK issue. I will add these to my list.

I looked briefly into changing the undefined opcodes. The Simulator pulls the opcode/operand/timing info from the same database the assembler uses. I have to essentially add a NOP+0 byte, NOP+1 byte, and NOP+2 byte instruction to the assembler's list of valid opcodes. I am considering UN1, UN2, and UN3. This would allow me to model the number of bytes used in the simulator along with the cycles used and allow the programmer to include them in their source code without locking in the skipped bytes to an operand.

Here's an example of what I think Jeff was eluding to:



The other bugs you reported should be straight forward to fix.

This is the list of bugs I found that I plan to test & fix if needed:






Here are some feature enhancement requests as well:





Do you guys think we should move this discussion over to the Emulation and Simulation group?

_________________
Please visit my website -> https://sbc.rictor.org/

So did the Simulator ever pass that 6502 test that's been floating around?

I'm not sure... but I plan to run both the 6502 and 65C02 tests after I finish with the known bugs list.

I also found a cycle count test here viewtopic.php?f=8&t=3340&p=38584 that the Kowalski simulator had failed. It now reports 1141 cycles, which validates the changes I have already made concerning cycle accuracy.

Daryl

_________________
Please visit my website -> https://sbc.rictor.org/

Many of the 'C02 undefined NOP's have actual address modes. In other words they compute an address and do a fetch just as an ordinary instruction would do. The byte counts and cycle counts are ordinary as well. Perhaps this info will make your job easier.

• 02 22 42 62 82 C2 and E2 are NOP's that use Immediate mode.
• DC and FC are NOP's that use Absolute mode.
• 44 is a NOP that use Zero-Page mode.
• 54 D4 and F4 are NOP's that use Zero-Page,X mode.

Because they're NOP's the data they fetch is discarded. Full details here.

The remaining NOP's don't match any ordinary instruction. 5C is 3 bytes, 8 cycles. And all the NOP's in column $3 and column $B are 1 byte, 1 cycle.

Several of the undefined NOP's are suitable for the skip-a-byte (or skip-two-bytes) trick. And any of the undefined NOP's could conceivably turn up in someone's code, used as time-waster in a software delay loop. [Edit:] It's unlikely, of course. Only the 1 byte, 1 cycle NOP's are especially apt for time delays.

_________________
In 1988 my 65C02 got six new registers and 44 new full-speed instructions!
https://laughtonelectronics.com/Arcana/ ... mmary.html

I understand your explanation. But would you rather code a skip this way:


or


That is why I was considering the new pseudo-opcode. I'm open to a consensus from anyone interested though.

Daryl

_________________
Please visit my website -> https://sbc.rictor.org/