Kowalski Simulator Updates

[BigDumbDinosaur]

Yuri wrote:

I've also gone ahead and setup a version that will build with Visual Studio 2022.
(Note that installing MFC is an advanced option buried in the installer)

I’m a little confused.  I see a reference to Visual Studio and immediately think “Windows.”  I thought you were creating a package that could be built on a non-Microsoft system.

[Yuri]

BigDumbDinosaur wrote:

Yuri wrote:

I've also gone ahead and setup a version that will build with Visual Studio 2022.
(Note that installing MFC is an advanced option buried in the installer)

I’m a little confused.  I see a reference to Visual Studio and immediately think “Windows.”  I thought you were creating a package that could be built on a non-Microsoft system.

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.

[8BIT]

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

[BigDumbDinosaur]

8BIT wrote:

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

I’ve downloaded it and will give it a spin ASAP.

[8BIT]

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

[BigDumbDinosaur]

8BIT wrote:

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.

Now he tells me! 

I haven’t tested yet, but did back up the registry location...just in case.

[Yuri]

8BIT wrote:

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

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

[8BIT]

Yuri wrote:

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

[8BIT]

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

[8BIT]

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

[BigDumbDinosaur]

8BIT wrote:

First bug...

I haven’t been able to do any testing yet...busy music weekend and just got back from a gig.  Hoping to mess with this in a day or two.

[8BIT]

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

[BigDumbDinosaur]

8BIT wrote:

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

I was never clear on exactly what the memory protection was supposed to do.  Does protection apply to any access, or just to stores?  If the protected range is ROM and read-enabled, a stack pull would be legit, if of dubious value.  MVx would also be legit as long as the destination is writable.

[8BIT]

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

[BigDumbDinosaur]

8BIT wrote:

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.

Given that the Kowalski simulator is a simulation of the 6502 family (some of it, anyway) and not of a particular machine, attempting to mimic the effect of a shadow write would be inappropriate—the ability to shadow is not contingent on the capabilities of the MPU.  Also, there is no I/O hardware, only a generic console.  So a lot of what would appear in a real system should not be present.

Quote:

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

I’ve never tried that.  Any simulation I’ve done has been to test algorithms and in some cases, get cycle counts.

Quote:

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

Yep, but only if simulating the 816 in native mode—a stack push to ROM can’t happen in emulation mode unless ROM is mapped over page $01...which brings to mind an interesting observation.

When the 816 is operating in emulation mode, it is mostly a 65C02, but not exactly.  Accordingly, simulating the 816 in emulation mode shouldn’t be the same as simulating the actual C02.  For example, none of the Rockwell extensions would be legit in emulation mode.  Also, an 816 can execute all instructions in either mode and can touch extended RAM even though in emulation mode.

Quote:

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...I can see its value back in the days when 1k of SRAM was expensive, but not in today’s world. So, I removed it.

I don’t think that the “adjustable address bus” feature will be missed.