Timing Error with Kowalski Simulator

[8BIT]

Dr Jefyll wrote:

8BIT wrote:

Here is a chart of the resulting timing of the instructions that cross page boundaries and/or are affected by the decimal flag

For what it's worth, JMP (ind) and JMP (ind,X) also involve possible crossing of page boundaries.

This is wonderful work you're doing, Daryl. Thank you!

One other point has to do with 'C02 undefined NOP's. (Unlike undefined NMOS ops these are very simple.) Dunno if it merits your attention, or if the simulator even recognizes them, but some of those instructions *are* occasionally useful (as a trick to avoid coding a BRA instruction). Details here.

-- Jeff

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

[8BIT]

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

[hoglet]

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

Code: Select all

0 7c 1 1 1
1 01 1 0 1
2 32 1 0 1
3 32 1 0 1
4 95 1 0 1
5 4d 1 0 1

4D8F : 7C 01 32 : JMP (3201,X)   : 6 : A=4D X=FF Y=43 SP=FF N=1 V=1 D=1 I=1 Z=0 C=1

0 ad 1 1 1
1 02 1 0 1
2 32 1 0 1
3 0a 1 0 1

4D95 : AD 02 32 : LDA 3202       : 4 : A=0A X=FF Y=43 SP=FF N=0 V=1 D=1 I=1 Z=0 C=1

G65SC12

Code: Select all

0 7c 1 1 1
1 01 1 0 1
2 32 1 0 1
3 32 1 0 1
4 29 1 0 1
5 51 1 0 1

5123 : 7C 01 32 : JMP (3201,X)   : 6 : A=51 X=FF Y=43 SP=FF N=1 V=1 D=1 I=1 Z=0 C=1

0 ad 1 1 1
1 02 1 0 1
2 32 1 0 1
3 08 1 0 1

5129 : AD 02 32 : LDA 3202       : 4 : A=08 X=FF Y=43 SP=FF N=0 V=1 D=1 I=1 Z=0 C=1

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

Dave

[8BIT]

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

[BigDumbDinosaur]

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

[8BIT]

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

Daryl

[BigEd]

A most excellent result! Thanks for reaching out BDD.

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

[8BIT]

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

[BigDumbDinosaur]

8BIT wrote:

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

Get the Polish-to-English dictionary ready!

[Klaus2m5]

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.

[8BIT]

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:

Code: Select all

Init0      CLC
           UN2      ; skip the SEC instruction
Init1      SEC
           ...

Prompt1      LDA #'>'
             UN3      ; skip the following LDA command
Prompt2      LDA #'!'
             ...

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:

Quote:

I will say, though, that if you used any labels or variables without a dot before them between referencing .multiplydone and the .multiplydone label, then the Kowalski assembler forgets all labels and variables that begin with a dot. viewtopic.php?f=2&t=4978&hilit=kowalski&start=15#p57348

Quote:

Just discovered another bug in the simulator having to do with macro processing. I accidentally passed one too many parameters with a macro call—the macro only accepts one parameter—and the assembler got hung up in an error loop when it tried to assemble the statement. I had to go into the task manager and manually kill the simulator to break the loop. Fortunately, I had saved the source file before this happened. viewtopic.php?f=1&t=4981&p=57332&hilit=kowalski#p57332

Quote:

Kowalski's simulator is cycle-accurate except for not duplicating timing when an IRQ hits during the execution of a branch instruction viewtopic.php?f=2&t=4948&p=56785&hilit=kowalski#p56785

Quote:

BRK test while checking the flags pushed onto the stack by LDA from page $100, expected $30 - actual $10. viewtopic.php?f=2&t=2241&p=20774&hilit=kowalski#p20774

Here are some feature enhancement requests as well:

Quote:

As it has been said before, the Kowalski assembler does not support passing the immediate modifier to a macro viewtopic.php?f=2&t=2832&p=31316&hilit=kowalski#p31356

Quote:

The assembler recognizes @F as denoting a Forward branch to the closest location marked F@ viewtopic.php?f=8&t=1932&hilit=kowalski#p21361

Quote:

Speaking of editors, the one in the Kowalski simulator doesn't have the ability to insert ANSI box graphics characters from the keyboard viewtopic.php?f=1&t=2250&p=21094&hilit=kowalski#p21094

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

[whartung]

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

[8BIT]

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

[Dr Jefyll]

8BIT wrote:

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

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.

[8BIT]

Dr Jefyll wrote:

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.

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

Code: Select all

     LDA #$80
     NOP $00A9     ; LDA #$00  - Also, will the assembler try to optimize this down to NOP $A9??

or

Code: Select all

     LDA #$80
     UN3
     LDA #$00

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

Daryl