6502 Simulator

["Shawn B." <leabre@html.com>]

Greetings,

I am wondering if anyone would be interested in a simulator that I'm working
on.  First, I realize there are many out there.  I am not trying to reinvent
the wheel.  What I am looking for, is something a little more "robust" than
what I can freely download without hefty purchase.

My purposes are simple:  I want to be able to enter code in, assemble,
execute, and debug in one environment with a chosen CPU core (6502, 65c02,
or 65816).  I want to be able to develop and debug Atari and NES/SNES games
in the same enviroment.  I'm not talking about an emulator.  I have one more
stipulation that is of interest to me: I want to be able to modify the
source code during execution time (a debugging session with an active break
point).

So, where am I today on this project?

This program is being written in C#.  It seems to be a very good language
for the task.

My CPU core is about 40% complete (I've worked on it now about 30 total
hours).  This is my first time writing such a beast, or an assembler, or a
debugger, so it'll take me some getting used to.

The CPU is broken into a few concrete steps:

  1) Fetch();
  2) Decode();
  3) Execute();

Thats it.  Then there are a bunch of private/protected methods that support
it.  But publicly, that's all you need.  The host will provide ways to hook
into the CPU while it is executing so if a breakpoint is set, you can see
the debugging info (memory listings/program dissassembly), register dumps,
the usual.  The host will actually be responsible for causing the Fetch,
Execute methods in its own loop.

The CPU will act as a plugin to the host so you can plug in whatever CPU you
want (I may also implement a Z80 once I'm done deciphering the spec for the
65xx series).

Then, you can write more plugins to do more.  Because as it is, there is no
IO window.  It just executes.  So, if you are wanting to test output on an
Apple, while I realize it's a little more complicated, in simple terms, you
can write a plugin that will act as a text output window so as your
application is executing you can get "visual" feedback in some manner.  Why
all the trouble?  I want to debug my NES games.

Now for the reason I'm making it in the first place: when you are debugging,
and a breakpiont is set, you can modify the source code and next time you
step the breakpoint, it will execute your new instructions as if you
originally compiled it that way.

The way I intend to implement this trick is like this:  when you chance the
source, and step the breakpoint, it will then recompile the program (only
your source code) and overlay the old memory with the new memory and then
adjust any branches and references as necessary and then adjust the Program
Counter to the necessary memory location to cause the change to "appear" to
have taken effect.  This way, if I have a nasty defect that I"m trying to
correct, then I can just keep it in the breakpoint and change the source as
I'm debugging without having to constantly start over again.

I also intend to include a profiler with it so I can profile my code.

While this isn't an open source project, I'll make the source code available
for the CPU cores and perhaps not not guaranteed, the host application
itself.

Would anyone be interested in such a project when released?

I do not intend to implement undocumented opcodes, however, you can always
inherit my CPU core classes and implement them yourself and "plug" that CPU
into the host if you wish.

So far, I can execute quite a few of the opcodes but I still have to
implement the branching and timing (I'm not quite sure how to simulate 1MHz,
2 MHz, etc.).

I'm not asking for help, but I would be interested if having people help me
debug this if anyone cares todo so.


Thanks,
Shawn