Oh, what to call them. Sorry, I misunderstood what you were getting at.

With a few exceptions, I'd be reluctant to assign names (mnemonics) that would be used by other people. It seems to me most of that responsibility is best left to the individual programmer. But I'm interested in hearing suggestions.

The name should make a clear statement about what the instruction does. But what these NOP's do isn't very clear (there are one or two exceptions). That's why I think a person should take stock of what the instruction does then invent their own name. That way they can't take an incorrect inference from a name I invented!

I'd be comfortable assigning a name (1~NOP perhaps?) to the one-cycle NOP's. Likewise I'd be OK assigning a name to the Immediate Mode NOP's (2 byte, 2 cycle). SKIP_1BYTE (or whatever) would be alright. But after that things get progressively fuzzier. For example, SKIP_2BYTES (or whatever) is less clear because the Absolute Mode NOP's that do this carry with them the risk of touching an I/O device. (Because it's absolute Mode, I mean. An ordinary instruction like BIT absolute has the same risk.) Anyway, a name like SKIP_2BYTES is perhaps too glib. This instruction isn't worry-free the way SKIP_1BYTE is. Maybe it's better to let the person take stock of what's what then invent their own name.

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

I would only implement them in the simulator and disassembler and just call them U## (## = hex opcode, UDC for example). They should be followed by a .db or .dw according to the number of bytes skipped.

The assembler would only allow them as .db $## in order to make sure the programmer understands he is on his own beyond this point. Of course the programmer can use a macro and call it SKIP or whatever he tries to achieve.

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

SKIP_1BYTE, SKIP_2BYTES?

Do we need a different names for the skip pseudo instructions though?
LDA for example has different opcodes for different addressing modes and we still call it LDA.

How about:
SKIP_TO $Address
or just
SKP $Address

The correct skip opcode can be determined based on the distance to $Address.

I was working on fixing the other bugs you mentioned and found a way to separate the simulator from the assembler and disassembler. Using this, I should be able to simulate their behavior and not have them appear in the assembler's list of opcodes. The disassembly will show .db followed by .db or .dw as will the simulator. I really didn't want to elevate them to a valid opcode, and using this discovered method will allow that.

By the way, in fixing the BRK not pushing bit 5 to the stack, I discovered that BRK was being masked by the IRQ bit and was only being acknowledged when Interrupts were enabled. That has been fixed too.

Daryl

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

This is great stuff!

Seems I need to add "BRK when IRQ is disabled" to my test.

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

Also great stuff!

Sounds good. As Klaus said, make sure the programmer understands he is on his own.

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

Here's another one, from the 65C02 Tutorial by Bruce Clark


The simulator was not doing this either. As far as I can tell, the D bit was not being cleared in 65C02 mode. It's fixed now.

Daryl

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

There is actually a 65C02 test for the BRK to clear decimal mode, but it doesn't work because the interrupt is not taken due to the BRK not being executed when IRQ is disabled bug. Oh well...

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

Perhaps after the BRK the test could snoop beyond the top of stack to check that the right address was pushed? (Having first put a canary there.)

The 6502 test does check for the registers to be modified to a certain pattern on return. But it tests the BRK only with the interrupt disable flag off. The additional 65C02 test makes the humble assumption that the BRK instruction works in general and does not check if the BRK is actually executed.

I will add a second pass with I flag on to the test and repeat the full BRK test for the 65C02.

Sorry for hijacking this thread. Maybe I should have created a new one. I have now opened an issue (bug report) on GitHub.

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

Just discovered that the BRK instruction behaves differently between 6502 and 65C02 mode of the simulator.

6502 mode:In 6502 mode you get the known bug where the processor status pushed by the BRK to the stack at $1fd ($10) has the break bit set but not the unused bit. The other 3 errors are from the second pass with interrupt disable and indicate that the interrupt handler has not modified any of the registers A, X or Y.

65C02 mode:This time the stack at $1fd ($30) is correct, but the saved active flags currently at $1f9 ($24) has the break bit off. $1f9 is the saved accumulator after PHP, PLA (subsequent JSR> PHP PHA TXA PHA TYA PHA is part of the report generator). Since it was originally saved with a PHP the break bit should be on.

The test detects a second error after the interrupt handler returns to the caller. The popped processor status after RTI also does not have the break bit set. Again it was initially moved with a PHP PLA and the report generator pushed the accumulator to the stack at $1fc ($20). So it looks like RTI is broken when in 65C02 mode.

Like in the 6502 mode the last 3 errors indicate that the interrupt handler was never executed due to the interrupt disable bit being on.

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

Hi Klaus,

I found the PHP command was not setting the BREAK bit or the unused bit in 65C02 mode. I have fixed that. I will check the RTI again since it may be fixed with the BRK and PHP mods. I'm almost finished with bug fixes.... I've been stuck on 1 small artifact of simulating the unused opcodes. I ran your test suite yesterday and both 6502 and 65c02 tests passed. Once you get your mods posted, I'll re-run them.

Daryl

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

While you are fixing things, you might want to look into the ADC and SBC decimal modes. This fails for sure on the simulator (1.2.12):



I haven't tried testing SBC op codes. I was using this to test my NMOS 6502 CPU core that I wrote in (dsPIC33) assembly. This failure drove me nuts and I finally tried it on real hardware to find that there is a bug in the 6502 simulator.

Any news on getting a newer executable that corrects the various things you have found?

If you load latest Klaus' test suite and do a reset, the simulator has $0B in the test_case and is hung at $37C9 on a failed compare.


edit: I just found the thread with the 1.2.13.zip attachment. The decimal test fails still, but further along that v1.2.12 did.

Any idea how to get the HELP file to work with Windows 10? I would like to figure out how to enable breakpoints for LOADed code.

Only in 65C02 mode the flags N & Z represent the content of the accumulator after the decimal correction. On the 6502 the flags N & Z represent the content of the accumulator before the decimal correction. This is why the 65c02 takes an extra cycle for add and subtract in decimal mode.

What you are seeing is the correct result in 6502 mode!

P.S. The help file is in Polish language and might not be as helpfull to you than you think!

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