6502.org

I am (actually can run on Windows and nonWindows), that's on this branch here:
https://github.com/Kelmar/kowalski/tree/wx_port
(Builds but does not yet work as the old version does)

When I have an update for that branch that is note worthy I'll post to the other thread where that's being tracked.

This is a proposed update for the older Windows version that Daryl is working with.

Trying to get that version to build requires Visual Studio 2010 which is not the easiest thing to find and install these days. Visual Studio 2022 at any rate was barfing on the solution/project files because they're so old now; so I've rebuilt the project files so you can use the more readily available version of VS.

The bug he fixed for 1.3.5.3 also made me think of one of the changes I first made to the new port; which is to replace that int with an enumeration for clarity. I've back ported that change. Which shouldn't (operative word) change the functionality of the program, but should (I hope) make reading/updating the code a bit easier to do moving forward.

After 3 months of on & off coding, I have a beta version of the Kowalski Simulator complete with 65816 simulator.

I have modified a 65816 test suite targeting an NES platform and the simulator passed that suite. I plan to test the suite on my SBC-4 this weekend to ensure I have consistent results.

In the mean time, here is a beta copy of the program for those who want to give it a test run. Please report anything unusual via this thread, pm, or email.

Enjoy!
Daryl

A small note on the v1.4 program. It reads and writes the option settings to a new Registry location, so the v1.3 settings are not overwritten. That way you can go back and forth between programs and your option settings are independent.

Have fun!
Daryl

Let me know when you want me to update the git hub repository with the changes!

Will do - let's give it a few weeks for others to find any major issues. Once I tackle any major issues, I'll post the source.

The major changes are in sym6502 with associated support from the various view pages ( register, memory, disassembly, etc)

thanks!
Daryl

First bug - WDM instruction was like NOP and only using 1 byte. Documentation has it using 2 bytes. The assembler was tucking $00 after the $42 WDM opcode but the Simulator was not passing over the $00 operand. I had disabled that opcode in the test suite and forgot to go back to it when the other tests were completed.

Since it is not a "functioning" opcode, I will wait to fix it in the next release that addresses any other bugs.

I ran into some issues with running the test suite on my SBC-4 as the test suite writes to upper memory my SBC does not have. I am working to modify the test suite to run within 512k since that is a common SRAM chip size.

thanks!
Daryl

Second bug - a remnant of my troubleshooting. 16 bit values of register Y print with 6 digits vs 4, cutting the right-most digit off. I was using the Y register space to show addresses while troubleshooting various addressing modes and forgot to reset it back to 4 digits. It does properly show the value of Y.

This will be fixed also in the next release.

Daryl

No worries - I'm still testing and looking for errors and cleaning up the source.

Found another one - the MVN and MVP commands do not observe the Protected Memory region settings and those settings were limited to bank 0. I fixed the range error and am working on the MV* commands.

Also, to note: The pull from stack operations have never observed the memory protect region. Now that the stack can extend into all of bank 0, I will look at adding that feature as well.

Daryl

Protection is just for writes to the specified range. My guess is it was set up to emulate a ROM area and to ensure user code is not trying to write there. It would not be effective for testing software for systems with shadow RAM or other hardware registers under the ROM area.

The program stops running with a message in the Register window status when protected memory is written to.

I would have to add monitoring for pushes to the stack if the stack pointer were to enter the protected area.

BTW, you may have noticed I removed the address bus width parameter from the General Options page. 6502 & 65c02 have full 16-bit address buses and 65816 has a full 24-bit address bus.

While working through the 65816 modifications, I found that more than a few original opcodes were not being masked by that parameter. I had the choice to go back and re-write that code and add code to 65816 opcodes, or to simply remove it.

I can see its value back in the days when 1k of SRAM was expensive, but not in todays world. So, I removed it.

Daryl