6502.org Forum  Projects  Code  Documents  Tools  Forum
It is currently Sun Nov 24, 2024 11:21 am

All times are UTC




Post new topic Reply to topic  [ 413 posts ]  Go to page Previous  1 ... 21, 22, 23, 24, 25, 26, 27, 28  Next
Author Message
PostPosted: Sun Jun 23, 2024 7:45 pm 
Offline
User avatar

Joined: Thu May 28, 2009 9:46 pm
Posts: 8514
Location: Midwestern USA
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.

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


Top
 Profile  
Reply with quote  
PostPosted: Sun Jun 23, 2024 8:39 pm 
Online
User avatar

Joined: Tue Feb 28, 2023 11:39 pm
Posts: 258
Location: Texas
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.


Top
 Profile  
Reply with quote  
PostPosted: Fri Jul 05, 2024 3:22 pm 
Offline
User avatar

Joined: Fri Aug 30, 2002 9:02 pm
Posts: 1748
Location: Sacramento, CA
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


Attachments:
6502 v1.4.zip [769.89 KiB]
Downloaded 16 times

_________________
Please visit my website -> https://sbc.rictor.org/
Top
 Profile  
Reply with quote  
PostPosted: Fri Jul 05, 2024 3:31 pm 
Offline
User avatar

Joined: Thu May 28, 2009 9:46 pm
Posts: 8514
Location: Midwestern USA
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.

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


Top
 Profile  
Reply with quote  
PostPosted: Fri Jul 05, 2024 6:00 pm 
Offline
User avatar

Joined: Fri Aug 30, 2002 9:02 pm
Posts: 1748
Location: Sacramento, CA
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

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


Top
 Profile  
Reply with quote  
PostPosted: Fri Jul 05, 2024 6:32 pm 
Offline
User avatar

Joined: Thu May 28, 2009 9:46 pm
Posts: 8514
Location: Midwestern USA
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!  :D

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

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


Top
 Profile  
Reply with quote  
PostPosted: Sat Jul 06, 2024 12:54 am 
Online
User avatar

Joined: Tue Feb 28, 2023 11:39 pm
Posts: 258
Location: Texas
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!


Top
 Profile  
Reply with quote  
PostPosted: Sat Jul 06, 2024 4:02 am 
Offline
User avatar

Joined: Fri Aug 30, 2002 9:02 pm
Posts: 1748
Location: Sacramento, CA
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

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


Top
 Profile  
Reply with quote  
PostPosted: Sat Jul 06, 2024 9:24 pm 
Offline
User avatar

Joined: Fri Aug 30, 2002 9:02 pm
Posts: 1748
Location: Sacramento, CA
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

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


Top
 Profile  
Reply with quote  
PostPosted: Sun Jul 07, 2024 1:53 am 
Offline
User avatar

Joined: Fri Aug 30, 2002 9:02 pm
Posts: 1748
Location: Sacramento, CA
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

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


Top
 Profile  
Reply with quote  
PostPosted: Sun Jul 07, 2024 4:01 am 
Offline
User avatar

Joined: Thu May 28, 2009 9:46 pm
Posts: 8514
Location: Midwestern USA
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.

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


Top
 Profile  
Reply with quote  
PostPosted: Sun Jul 07, 2024 4:23 am 
Offline
User avatar

Joined: Fri Aug 30, 2002 9:02 pm
Posts: 1748
Location: Sacramento, CA
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

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


Top
 Profile  
Reply with quote  
PostPosted: Sun Jul 07, 2024 4:33 am 
Offline
User avatar

Joined: Thu May 28, 2009 9:46 pm
Posts: 8514
Location: Midwestern USA
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.

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


Top
 Profile  
Reply with quote  
PostPosted: Sun Jul 07, 2024 5:22 am 
Offline
User avatar

Joined: Fri Aug 30, 2002 9:02 pm
Posts: 1748
Location: Sacramento, CA
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

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


Top
 Profile  
Reply with quote  
PostPosted: Sun Jul 07, 2024 5:47 am 
Offline
User avatar

Joined: Thu May 28, 2009 9:46 pm
Posts: 8514
Location: Midwestern USA
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.

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


Top
 Profile  
Reply with quote  
Display posts from previous:  Sort by  
Post new topic Reply to topic  [ 413 posts ]  Go to page Previous  1 ... 21, 22, 23, 24, 25, 26, 27, 28  Next

All times are UTC


Who is online

Users browsing this forum: No registered users and 5 guests


You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot post attachments in this forum

Search for:
Jump to: