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

Was there a problem with the COP instruction or is it you didn't have the handler loaded? BRK and COP should simulate correctly. BRK does have the option to include a signature byte following from the options menu.

As far as the disassembler goes, yes, I am aware of the confusion with 16 bit immediate values. The disassembler was written to disassemble a single line from an address pointer input. It knows nothing about what the simulator is doing or what mode it is in. The immediate value is stored in a 16 bit variable so sometimes you will see a 16 bit value to the right of the mnemonic and other times its only 8 bits. The operand byte field to the left of the mnemonic will always be 1 byte as you observed.

The simulator will pass the correct address for the next instruction, so it resyncs itself and continues correctly.

I've also observed some confusion with the yellow step pointer getting lost with JML/JSL/RTL jumps to other banks but it resyncs after one instruction. I have to track that down as well.

I will try on some future release to get the immediate modes corrected but it was not in my original release plans.

Thanks for looking!!

Daryl

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

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

Yes, if the vectors are loaded @ $FFE0..$FFFF and the handlers are installed at the right addresses, then BRK, COP, INT, NMI, and RST all function as they would in hardware. This includes emulation mode and native mode behaviors as I understand them.

Give them a test!

thanks!
Daryl

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

Another setback with my test suite. I was able to rewrite it to use banks 0-7 vs 0-7F and was able to make a bootloader that would load the suite from $008000 - $04FFFF on my SBC-4. It started to run but had several test failures. Then I saw why. Many tests are testing stack wrapping vs non-wrapping modes. In some tests, data is stored and read on page $02xx. That happens to be where my SBC-4 has its IO page. So writes were not being read back correctly. I could move the stack for native mode but there are a few tests that runs in emulation mode that read or write to $200. These would fail.

I may dig out my Zilinx CPLD programmer and remap my IO to another page and modify the bootloader accordingly. I'm not sure when that will happen.

I'm going to go ahead package up the test suite and post it here, in case others would like to give it a try. It only needs a chr output and chr input (waiting for input) routine and lots of RAM to work.

Daryl

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

I have uploaded an update correcting most of the items found so far. The only outstanding issue is the disassembler & 16 bit immediate issue.

Source code is also available for this version (1.4.0.1). https://sbc.rictor.org/kowalski.html

Daryl

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

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

I have uploaded an update correcting the 65816 instruction timing. Executable and source files are on my website.

https://sbc.rictor.org/kowalski.html

This will be my last feature update for the Kowalski Simulator. I feel it has been uplifted to a point where it is capable of supporting development on the 6502, 65c02, and 65816.

I will continue to support bug fixes of course, but do not plan to add anything more as far as capabilities or features.

Enjoy!

Daryl

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

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

I know. As stated previously "Find Pattern match and Find & Replace crashes - these are Microsoft AFX functions that I do not want to dig into, so most likely will not get addressed anytime soon."

I don't have enough time or ambition to try to figure that framework out. Maybe Yuri's updates will be able to resolve it.

Kindly,

Daryl

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

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

Probably will, considering that I'm effectively having to rewrite the GUI portions of the code. I'll get these new versions up on the git hub as soon as I am able. (I've been out of pocket for a while while my apartment complex remediates my unit for mold)


That being said, I can probably track down the AFX issue if you can get me a core dump or know how to reliably recreate the crash. It is also possible that it got fixed with a newer MFC version, which is what I've been compiling with when I ported the project over to be usable in Visual Studio 2022.

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

I just remembered there was another minor change in V1.4.0.2. MVN and MVP now function more like the hardware in that they execute one copy in 7 cycles and don't increment the program counter until the A register equals $FFFF (creating a do until loop). That way, interrupts will happen in between the 7 cycle steps. Previously, the whole copy would have happened before an interrupt would have been recognized.

Happy coding.

Daryl

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

Question for the group:

Assembling a 65816 file... should LDA #300 cause an error (parameter won't fit in a byte) or should I let it go and have it assemble 3 bytes (A9 2C 01). The intended way is to use LDA !#300, which forces a 2 byte operand. Having no error can lead to logic errors the programmer may miss.

thanks!
Daryl

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