It would be great to have alternative OS choices.

Keep us posted on your progress!

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

Erffff....

Okay, I've spent the better part of the last 3 to 5 days ripping apart all of the code in the simulator. I've also translated probably about 80 to 90% of all the comments from Polish into English at this point.

This code has definitely seen some millage; I saw some copyright marks going as far back as 1995. Looks like there are tones of different licenses through out the code too; not sure how that gets sorted out.

Anyhow, the code itself is very heavily intertwined with MFC. Even the core of the simulator uses some MFC classes, and has some hard references back to the UI (specifically for the IO window and memory views)

I've gone through and gutted a good chunk of the MFC classes and did a tentative start at translating them to wxWidgets. The various string classes I've replaced with the STL std::string where I could. No idea yet if this will still run as intended (I'm still getting it back to building), but it is getting there. I'd say about 90% of the files now build on Linux at least to some form of semi-functioning.

Now, the fun bit:
The simulator is using some inline assembly. While I don't really have an issue with inline ASM, the problem is that it's very compiler specific. In this case MSVC, and can't be ported as-is to something like the newer Arm based Macs, or to Linux/Un*x that tend to use GCC/Clang, so I'll have to rework that into C code.

So I'm currently staring down at this code which is probably 60-70% gutted and looking like it might need some additional changes in the deepest parts of it and I'm wondering if it makes sense to continue down this path, or not.

Curious to hear what other people might have to suggest.

Edit:
Also, the branch that I'm working out of can be found here:
https://github.com/Kelmar/kowalski/tree/wx_port

No, it won't successfully build for you.
Yes, I have basically taken an axe to the source code. ^^;

Wow!!! Sounds like you really went to work!

I'd say keep going if you are having fun or learning something new. It definitely takes passion to complete such a big lift. When I started updating the Simulator, it was to fix the opcode timing for a project I was leading. In other words, I needed a tool to count cycles but it needed to be 100% accurate. I knew nothing about C++ and only dabbled in C and the MFC stuff was and is a big black box. I've managed to fumble my way through the code and make some improvements - most notably the 65816 assembler. I'm not sure I'll ever get the 65816 simulator started let alone finished... but its on my bucket list.

Having better source code that is more platform independent will allow others such as you and I to keep this tool moving forward. I hope you can stick with it and see it through.

best wishes!
Daryl

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

When I get started I tend to go full tilt at something.



Don't think it's a lack of passion, just considering if what I have left when I'm done will resemble anything like the original or not.



I did note when I was running this on my modern day PC, this thing is just blindingly fast. (It got up to 5 million cycles in less than a minute)
Which lead me to wonder if it would be at all worth while at this point to simulate the clock itself to some extent. (I.e. slow it down to be more in line with a real world 6502/65816)



Cool beans! Hopefully I can help you realize that goal. I'd love to see 65816 support fully realized in this. I have other thoughts about things that could be done to make this a more interesting and useful tool, but the current goal is to get relatively feature complete with what already exists.

Here are my rough thoughts:

1.80.x.x (current goal)

• Where I'm starting the versions (gives plenty of space for bug fixes on the old code while I work)
• Port code to Linux and wxWidgets, get to build/run on Linux and Windows. (And hopefully Mac)
• Some minor code clean up, translation of comments.
  Nothing too crazy, just a bit of spring cleaning, trying to demystify some of the more esoteric parts of the code, and a removing some bits of duplicated code I've found.

1.81.x.x (further out goal)

• Refactor code so that assembler and disassembler are usable as standalone command line utilities.
  Should allow folks to build their code w/o having to fire up the GUI as well as use make and other utilities to build more complex projects.
• Adjust the GUI so that it can call any assembler if you want to use something else. (WLA, CA65, w/e)
• Adjust IO window to support different character sets? (E.g. PETSCII)

1.90.x.x (far fetched goal)

• Refactor simulator so that it is easier to make new CPUs. (E.g. 65816, 6809?, Z80? other!?)
  
  • Generic bus/attachment of hardware devices.
  • Simulated clock speed 1~32MHz, (or unlimited)
• Perhaps begin designing/dreaming of way to allow custom hardware to be added. (E.g. simulating a TMS9918, 6551, or Yamaha YMF262?)