Figured I should put status up dates for my efforts to port the code here.

The current status is that I've gotten the code to compile, and I can now load up and edit assembly files.

My next task is to get it to load binaries and run the simulator itself.

Here's a screen shot of the current state running on Linux and Windows.
(My Linux box is forwarding its X11 requests to my Windows machine)

looking good - thanks for the update!

Daryl

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

For context, see this post and others which follow in the topic "Kowalski Simulator Updates."

-- Jeff

_________________
In 1988 my 65C02 got six new registers and 44 new full-speed instructions!
https://laughtonelectronics.com/Arcana/ ... mmary.html

Just a quick update on this.

I now have an automatic build setup on github that will build both Windows and Linux when code is checked in. Hopefully this will be a good start on a simple CD/CI pipeline to have builds and releases automated.

This will also afford automatic unit testing in the future, and building in a clean build environment.

Added a raw binary format loader, and I'm going to proceed with getting the simulator itself to run with some basic 6502 diagnostic software.

Changes from 1.4.0.3 have been merged into the wx_port branch.

Okay, after some head bashing from a weird NULL de-reference bug in wxWidgets, that I still haven't quite figured out, I was able to get the assembler to run on a dirt simple assembly file.

Still needs work in that department; however it is progress.

Next up will be to try and actually run the simulator.

EDIT:
For reference this is where the NULL error is/was.... The debugger wouldn't even let me step into the line..... >_<

Working on the memory display:

This is what I have working in action on Linux


I'd like to be able to support displaying different character sets in the right there. (E.g. Petscii)
Are there any other character sets that might be good to show there?

ATASCII, maybe. Screen code glyphs, maybe, in case a program is not bothering to convert whatever version of ASCII its host uses to screen codes at run time.

You might use the Unicode control pictures to display the ASCII control codes rather than blanks:
https://www.compart.com/en/unicode/block/U+2400

_________________
http://WilsonMinesCo.com/ lots of 6502 resources
The "second front page" is http://wilsonminesco.com/links.html .
What's an additional VIA among friends, anyhow?

I'll take a look at that one



For Un*x (and presumably Mac) it should already be UTF-8, though it complains a bit if I try to print character 127 (which is a delete character)

Windows has it's own crazy NOT QUITE UTF-16, but IIRC Microsoft has some character set translation functions.



Don't think that should be an issue.


So far the memory dump is working, and the assembler is able to parse my derp test program:


The jump to edit is much like the old goto dialog, but now you can just type in there.
Recognizes decimal, 6502/C style hex addresses.
Also handles special cases of: "zp", "zeropage", "sp", "stack" and "stackpointer" to jump straight to those locations.

You can also prefix with a + or - to do a relative jump.

Unicode provides a replacement for DEL/0x7f too:

https://www.compart.com/en/unicode/U+2421

Been a while, wanted to toss an update out there. Got the I/O window reworked, currently maps CP-437 to UTF.

I'm now working through getting the actual simulator code running again and working happily with the new UI bits and bobs. It says it runs, but so far my test application has not generated any output to the I/O window (yet). Still much to go through there.

The core simulator had several direct Win32 calls for sending update messages to the UI and creating Win32 specific threads.
The messages have been replaced in favor of a much cleaner signal/slot system, and isn't tied to any specific UI now.
The threads have been replaced with std::jthread in conjunction with std::stop_token.
In addition the use of newer C++ lambdas/std::bind have helped simplify a lot of the thread boiler plate.

With a fair chunk of that cleaned up, I'm hoping that part can be moved into a standalone library where a command line version might be created in the future.

Code is running and writing to the IOWindow now!



The smattering of direct calls to the IOWindow have been removed from the simulator.

The simulator now uses a simulated "bus" which it does all of its read/writes from, in combination with an abstract Device class, it should now be possible to create new devices without needing to modify the core simulator itself.

(E.g. one could make a simulated 6551 or 6522 for example)