lib6502/run6502 updates

[resman]

Here is a very minor update to Ian Piumarta's excellent 6502 simulator. I was in need of a simple command line environment to test my Apple 1 PLASMA VM - running a full blown emulator was just too inconvenient to test my code. However, lib6502 didn't easily allow for tracing executing code which is what I was looking for. So, I made some very minor changes to the spectacular C macros he created to allow for single stepping. And I do mean his macros are spectacular; really, you should check them out.

Now, by setting a flag in the mpu structure such as:

Code: Select all

mpu->flags |= M6502_SingleStep;

One can run the simulator and trace/single step the 6502 code for easy debugging:

Code: Select all

while (M6502_run(mpu))
  {
    char state[64];
    char insn[64];
    M6502_dump(mpu, state);
    M6502_disassemble(mpu, mpu->registers->pc, insn);
    printf("%s : %s\n", state, insn);
  }

This will display to the console:

Code: Select all

PC=0677 SP=01FC A=6A X=10 Y=00 P=05 -----I-C : iny 
PC=0678 SP=01FC A=6A X=10 Y=01 P=05 -----I-C : lda (F2),Y
PC=067A SP=01FC A=82 X=10 Y=01 P=85 N----I-C : sta E7
PC=067C SP=01FC A=82 X=10 Y=01 P=85 N----I-C : iny 
PC=067D SP=01FC A=82 X=10 Y=02 P=05 -----I-C : lda (F2),Y
PC=067F SP=01FC A=0B X=10 Y=02 P=05 -----I-C : sta E8
PC=0681 SP=01FC A=0B X=10 Y=02 P=05 -----I-C : sty E4
PC=0683 SP=01FC A=0B X=10 Y=02 P=05 -----I-C : ldy #00
PC=0685 SP=01FC A=0B X=10 Y=00 P=07 -----IZC : lda (E7),Y
PC=0687 SP=01FC A=40 X=10 Y=00 P=05 -----I-C : dex 
PC=0688 SP=01FC A=40 X=0F Y=00 P=05 -----I-C : sta D0,X
PC=068A SP=01FC A=40 X=0F Y=00 P=05 -----I-C : iny 
PC=068B SP=01FC A=40 X=0F Y=01 P=05 -----I-C : lda (E7),Y
PC=068D SP=01FC A=0B X=0F Y=01 P=05 -----I-C : sta C0,X
PC=068F SP=01FC A=0B X=0F Y=01 P=05 -----I-C : ldy E4
PC=0691 SP=01FC A=0B X=0F Y=02 P=05 -----I-C : rts 
PC=069B SP=01FE A=0B X=0F Y=02 P=05 -----I-C : jmp 00F0
PC=00F0 SP=01FE A=0B X=0F Y=02 P=05 -----I-C : iny 
PC=00F1 SP=01FE A=0B X=0F Y=03 P=05 -----I-C : lda 15BF,Y
PC=00F4 SP=01FE A=62 X=0F Y=03 P=05 -----I-C : sta F7
PC=00F6 SP=01FE A=62 X=0F Y=03 P=05 -----I-C : jmp (0362)
PC=05DE SP=01FE A=62 X=0F Y=03 P=05 -----I-C : lda D0,X
PC=05E0 SP=01FE A=40 X=0F Y=03 P=05 -----I-C : sta BF,X
PC=05E2 SP=01FE A=40 X=0F Y=03 P=05 -----I-C : lda (BF,X)
PC=05E4 SP=01FE A=A6 X=0F Y=03 P=85 N----I-C : sta D0,X
PC=05E6 SP=01FE A=A6 X=0F Y=03 P=85 N----I-C : inc BF,X

It's simply based on the return value from M6502_run: 1 (or non-zero) means it is single stepping, 0 means error/exit. I sent email to Ian but he may not check that email address very often or is busy with real life. So I thought I would post it here if anyone is interested. It's part of the PLASMA project located here: https://github.com/dschmenk/PLASMA/tree ... rc/lib6502

The Apple1+CFFA1 code is in a1cffa.c which is a very simplistic version of an Apple 1 with CFFA1 card but sufficient for my needs.

[BigEd]

Thanks for this! Ian's code really is a splendid example of what can be done.

[resman]

I've updated the location of the lib6502 to a different directory in the PLASMA project: https://github.com/dschmenk/PLASMA/tree ... rc/lib6502

The reason being, I've decided to expand my "universal" PLASMA interpreter written in C that I was using to execute simple modules under Linux into a more full-blown environment capable of executing 6502 code that is part of most low-level PLASMA modules.The universal PLASMA interpreter, PLVM, has been instrumented to help in testing and debugging of PLASMA modules in a more sophisticated environment. The alternative excuse is to build a PLASMA environment for the new, cheap, small, but very powerful embedded MPUs based around ARM and RISCV cores. They can become full blown development environments running PLASMA bytecode and 6502 native code through emulation libraries. PLASMA bytecode can exist outside the 64K address space of the 6502, freeing up memory for data and machine code.

More details to follow...

[resman]

Fixed another bug in lib6502.c - Carry out of ADC and SBC in decimal mode wasn't working properly so I made a simple fix. Not sure what was intended in Ian's code but it now is able to run the SANE floating point package. I've got the universal PLASMA interpreter far enough along to run my FORTH and LISP interactively under *nix. They are two of the biggest programs to date, with the exception of the compiler itself which I hope to have running when I port file writes over. All module dependencies load and run properly as a mix of 6502 and PLASMA code.

[BigEd]

(Does that fix look like it's fixing the same thing fixed here?
https://github.com/hoglet67/PiTubeDirec ... 1ae597f30f
)

[resman]

Hi Ed-
Yes, although my changes weren't as extensive and I didn't really check any of the flags other than carry:

https://github.com/dschmenk/PLASMA/comm ... 781848ebe3

BTW, I was able to track this down by enabling the single step/trace feature I added to lib6502 and dumping the output to a file, all 3.5 MB of it. Then looking for setting the decimal mode and quickly seeing where the error was. I really should run an opcode verification suite, but I'm pleased to be able to run everything simulated the same as real hardware now.

[resman]

And by implementing the rest of the file I/O functions for read and write, the PLASMA compiler in PLASMA generates the same binary as the PLASMA cross-compiler in C, all running under *nix. I did have to make a small change to the PLASMA compiler in PLASMA (I need a better way to describe these!) to take into account the large amount of free memory in PLVM - it was using a signed integer for the buffer size check and was coming back negative because it was greater than 32K

I also faked out lo-res graphics by using ANSI terminal codes and now Rod's Colors runs at warp speed.

[6502inside]

resman wrote:

Hi Ed-
Yes, although my changes weren't as extensive and I didn't really check any of the flags other than carry:

https://github.com/dschmenk/PLASMA/comm ... 781848ebe3

BTW, I was able to track this down by enabling the single step/trace feature I added to lib6502 and dumping the output to a file, all 3.5 MB of it. Then looking for setting the decimal mode and quickly seeing where the error was. I really should run an opcode verification suite, but I'm pleased to be able to run everything simulated the same as real hardware now.

This is basically the same as what I did for the 6o6 test suite:

https://github.com/classilla/6o6/blob/m ... imal.patch

That is enough to pass Klaus' tests.

[BigEd]

It would be good, I think, to allow for enabling tracing from run6502, perhaps with a -t flag. I've done something like that locally. (I think I've also sometimes put in some kind of cycle count delay interface, so I can start tracing the code I care about, not the entire reset sequence.)

[resman]

6502inside wrote:

resman wrote:

Hi Ed-
Yes, although my changes weren't as extensive and I didn't really check any of the flags other than carry:

https://github.com/dschmenk/PLASMA/comm ... 781848ebe3

BTW, I was able to track this down by enabling the single step/trace feature I added to lib6502 and dumping the output to a file, all 3.5 MB of it. Then looking for setting the decimal mode and quickly seeing where the error was. I really should run an opcode verification suite, but I'm pleased to be able to run everything simulated the same as real hardware now.

This is basically the same as what I did for the 6o6 test suite:

https://github.com/classilla/6o6/blob/m ... imal.patch

That is enough to pass Klaus' tests.

Good to know. Thanks!

[resman]

BigEd wrote:

It would be good, I think, to allow for enabling tracing from run6502, perhaps with a -t flag. I've done something like that locally. (I think I've also sometimes put in some kind of cycle count delay interface, so I can start tracing the code I care about, not the entire reset sequence.)

I think it would also be nice to have it run for a certain number of 'ticks' before returning from run6502. Could be useful for emulating certain speeds, too.

I'm starting to look into more debugging features to set breakpoints, look at memory, etc. I'll share what I come up with.