Skip to content
This repository has been archived by the owner on May 15, 2024. It is now read-only.

WDC 65C02 STZ issue #78

Open
munsie opened this issue Mar 27, 2024 · 0 comments
Open

WDC 65C02 STZ issue #78

munsie opened this issue Mar 27, 2024 · 0 comments
Labels
bug Something isn't working

Comments

@munsie
Copy link

munsie commented Mar 27, 2024

Hello --

While testing against my in development 65C02 core, I noticed that the STZ opcode tests have no way of knowing if the zero was actually written if you are ignoring the memory read/write cycles due to the memory being initialized to zero already. Here is an example test:

{ "name": "64 eb 28", "initial": { "pc": 43470, "s": 126, "a": 172, "x": 181, "y": 204, "p": 45, "ram": [ [43470, 100], [43471, 235], [43472, 40]]}, "final": { "pc": 43472, "s": 126, "a": 172, "x": 181, "y": 204, "p": 45, "ram": [ [235, 0], [43470, 100], [43471, 235], [43472, 40]]}, "cycles": [ [43470, 100, "read"], [43471, 235, "read"], [235, 0, "write"]] },

In this example, the final values of memory do include memory address 235 being set to 0. But the initial RAM values do not initialize it to anything besides 0. I was able to fool the test in this case by just reading the zero page address and doing nothing, which is definitely not a valid way of implementing this instruction.

For these instructions, can an initial value that is non-zero be specified in the RAM location the STZ opcode is being tested on? I can also work around this by randomizing the contents of my RAM before running tests, but this means the testing is non-deterministic and will also take longer to run due to initializing 64KB of memory to random values for each test.

Thanks!

@TomHarte TomHarte added the bug Something isn't working label Apr 3, 2024
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
bug Something isn't working
Projects
None yet
Development

No branches or pull requests

2 participants