Maybe I'm missing something, but rather than actually running (and tracing) the code, might it not be easier to compare the binary output file from your assembler with that of a known good assembler?

The routines that handle IO could be left as stubs; they don't need to actually work. I'm suggesting you could do two assemblies of the source and see how the output files compare.

If you like, I can supply you with FIG source code, tweaked to be palatable for the assembler in the Kowalski simulator. I seem to recall I made other changes as well, but it might be good as a guideline for what sort of stuff need to be done; just PM me and I can send it along.

-- Jeff

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

Whatever you can do, whenever you can do it is fine.

@Dr Jefyll, source that is known to works would be great.

Martin:

Reran my traces for the 8-bit 6502/65C02 version of figForth. You can find the source, and the traces in this github repository: https://github.com/MorrisMA/PyAsm65/tree/master/figForth. File trace.txt is a trace that contains both an instruction and a Forth level trace. File trace_fig6502a_19J31.txt contains a Forth level trace only.

I load the file fig6502a.bin at address 0x0400 in my version of py65. The corresponding assembler file is fig6502a.asm.

I simply transfer control to 0x0400, and when activity stops I issue the mon[cr] command to the figForth interpreter and it returns to the monitor.

Hope this helps.

The previous (one or two) updates detail the error that I had in my assembler, PyAsm65, which prevent my 16-bit processor implementation for operating correctly.

_________________
Michael A.

@Michael A, thanks!

That helped as I found a bug in my cout routine. I forgot to mask off the high bit, and some of the trace requests were sending unprintable characters that confused my terminal.

Right now it comes up to the prompt and crashes after I enter some text and hit return.

I suspect I am almost there, but I also noticed additional bug fixes in Michael A's code that aren't in the original source.

Success.

I accidentally located the user area over my I/O routines, and that's why it crashed on input. But debugging the problem made me learn a ton about how the inner interpreter works, so mission accomplished.

Now I just need to update the code with some bug fixes mentioned up thread.