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