6502 Klaus Test Program Question

[aaronmell]

First time poster here,

I decided to spend a few weekends implementing yet another 6502 simulator in C#. I've got all of the Op Codes implemented, and I am trying to get Klaus's test suite to run on the simulator, but so far I have not been able to get it working.

I was able to get the tests compiled into hex using the as65 assembler and the same command line switches with no modifications to the source, and loaded into my simulator. I am pretty sure that I don't know where the tests are supposed to be loaded though. I tried loading them at a few places based on my best guess, but the test seems to fail with an invalid opCode after a few steps or immediately, depending on where I loaded them. The header isn't clear, it just says to load the tests and set the PC to 0x1000.

Edit: my project is at https://github.com/aaronmell/6502Net/ in case anyone is interested in looking at the implementation.

Thanks

[Klaus2m5]

Hi Aaron and welcome to the forum!

The Intel Hex output option -s2 of the assembler creates an ASCII file with the required load addresses implied. So a hex loader would put it automatically into the right location. It is not a binary that you can load directly.

The format of the Intel Hex output:

Code: Select all

:16000A00C38241007F0000000000001F71800FFF7F80FF0F8F8F92
-                                                       start of record
 --                                                     hex count
   ----                                                 address (big endian)
       --                                               type 00=prog 01=end
         --------------------------------------------   data or code
                                                     -- checksum

To create a binary, you need to remove the assembler output option -s2. I recommend, that you change load_data_direct = 0 in the source code. The binary image should then start at $1000.

cheers, Klaus

[aaronmell]

Klaus2m5 wrote:

Hi Aaron and welcome to the forum!
To create a binary, you need to remove the assembler output option -s2. I recommend, that you change load_data_direct = 0 in the source code. The binary image should then start at $1000.
cheers, Klaus

Klaus,

Thanks for you help here.

I followed your steps, loaded the progam into memory starting at $1000 and then Set the PC to $1000. No failures this time.

LOP:0 PC:4096 SP:253 A:0 N:False V:False D:False I:True Z:False C:False
LOP:216 PC:4097 SP:253 A:0 N:False V:False D:False I:True Z:False C:False
LOP:162 PC:4099 SP:253 A:0 N:False V:False D:False I:True Z:False C:False
LOP:189 PC:4102 SP:253 A:1 N:False V:False D:False I:True Z:False C:False
LOP:149 PC:4104 SP:253 A:1 N:False V:False D:False I:True Z:False C:False
LOP:202 PC:4105 SP:253 A:1 N:False V:False D:False I:True Z:False C:False
LOP:16 PC:3987 SP:253 A:1 N:False V:False D:False I:True Z:False C:False
LOP:0 PC:0 SP:250 A:1 N:False V:False D:False I:True Z:False C:False

Last line repeats forever. With Stack Pointer Decrementing by 3

Just to confirm, does that look like correct operation up to the repeating SP decreasing? Would that be a trap condition?
I think I need to learn how to read assembly

[Klaus2m5]

You need to verify the steps of your program with the listing the assembler produced. Unless you convert your simulator's output to hex, this will be hard to do.

The last operation is a 16 or $10 which is a BPL opcode. This should branch back to 4099 but it goes to 3987. Since this is empty space, it hits a $00 (BRK) opcode and sends the simulator in a loop trying to get the unitialized IRQ vector pointing to uninitialized space and executing another break forever.

You should fix the relative addressing in your simulator.

Please get the newest version of the test here: http://2m5.de/6502_Emu/6502_functional_tests.zip

[aaronmell]

Klaus2m5 wrote:

You need to verify the steps of your program with the listing the assembler produced. Unless you convert your simulator's output to hex, this will be hard to do.

The last operation is a 16 or $10 which is a BPL opcode. This should branch back to 4099 but it goes to 3987. Since this is empty space, it hits a $00 (BRK) opcode and sends the simulator in a loop trying to get the unitialized IRQ vector pointing to uninitialized space and executing another break forever.

You should fix the relative addressing in your simulator.

Please get the newest version of the test here: http://2m5.de/6502_Emu/6502_functional_tests.zip

Yeah, this is going to be some learning for me. I think I need to write a monitoring tool next, so I can see whats going on. I have the simple output from the test I wrote, but I wouldn't mind having something more robust.

[aaronmell]

So, I sorted through things, but I am a bit confused about the negative numbers, I am not quite sure why the range is backwards for negative numbers?

IE: why is 0x80 = 127 and 0xFF = 0 when using relative addressing?

[John West]

aaronmell wrote:

why is 0x80 = 127 and 0xFF = 0 when using relative addressing?

It's because relative addressing uses the same two's-complement representation as general arithmetic. If you treat the numbers as unsigned, adding $ff to (say) $58 gives $157. Ignore the carry, and you've got $57, which is what you'd expect from adding -1 to $58.

For adding the 8 bit offset to a 16 bit address, the offset has to be 'sign extended' to 16 bits first. That means copying bit 7 to each of bits 8 to 15. So $80 extends to $ff80, and $40 extends to $0040. Then you can do unsigned addition, ignore the carry, and get the same value as if you had done a signed addition.

Say we want to calculate x + (-y). We can write that as x + (65536-y) - 65536. So we can use 65536-y to represent -y. We'll get an answer that is 65536 too large, but that's just the carry bit, which we can ignore.

[Klaus2m5]

aaronmell wrote:

IE: why is 0x80 = 127 and 0xFF = 0 when using relative addressing?

This is one's complement. As John already pointed out, the 6502 uses two's complement for negative numbers.

More reading: http://en.wikipedia.org/wiki/Two's_complement

[whartung]

I dunno, if you're having basic issues like these, I'd be testing with some real simple programs before tossing something like Klaus's test at it. The test is good, but it's REALLY big, and a bit daunting vs grabbing a couple of simple math and loop utility routines, etc. that are 10-20 instructions long and testing those first.

I think Klaus's test is better to find edge cases that are failing once you have a better feel for how you system is working. I got FORTH up and running on my system, and it still failed Klaus's test, since the FORTH just uses a subset of the coverage the Klaus's test does.

[aaronmell]

whartung wrote:

I dunno, if you're having basic issues like these, I'd be testing with some real simple programs before tossing something like Klaus's test at it. The test is good, but it's REALLY big, and a bit daunting vs grabbing a couple of simple math and loop utility routines, etc. that are 10-20 instructions long and testing those first.

I think Klaus's test is better to find edge cases that are failing once you have a better feel for how you system is working. I got FORTH up and running on my system, and it still failed Klaus's test, since the FORTH just uses a subset of the coverage the Klaus's test does.

I do have close to 1000 unit tests, unfortunately, I used my incorrect assumption's based on the documentation i found about the 6502 of how the system operates to test them, which has quickly shown to be not good enough. Is there a good resource for some smaller test programs that test a subset of functions? I think I know where some sample tests are for ADC and SBC, but I haven't really seen many smaller test programs that test specific subsets of functionality. I would write my own, but since I have a rather limited knowledge of assembly, I run the same risk of failure that my unit tests had.

After fixing the issue with relative addressing, I did get the test to run further, maybe 500-600 cycles in. I don't have a good tool set to monitor the status of the CPU as it runs, so I switched gears temporarily to build out a monitor program that makes it easy to visualize what its doing, much like Symon for java.

[zellyn]

I actually had pretty good luck doing test-driven development: run the test, wait for it to break, fix the error, repeat.

I recommend Bruce Clark's decimal mode tests for figuring out bugs there.

You can see how I load and run the tests here: https://github.com/zellyn/go6502/blob/m ... al_test.go

I heartily recommend at the very least writing something that can do very simple disassembling...
eg. https://github.com/zellyn/go6502/blob/m ... /disasm.go When getting the tests to pass, I simple printed out each address, instruction bytes, opcode, and all registers at every iteration. It certainly slowed things down, but if you pipe the output through tail -20 or something, and keep a listing of the tests (which includes source addresses) handy, it's not too bad. Finding one bug tends to point you to fixing the same bug in all your other similar opcodes.

For understanding the overflow flag, I recommend http://www.righto.com/2012/12/the-6502- ... ained.html and the links he points to.

[aaronmell]

zellyn wrote:

I actually had pretty good luck doing test-driven development: run the test, wait for it to break, fix the error, repeat.

I recommend Bruce Clark's decimal mode tests for figuring out bugs there.

You can see how I load and run the tests here: https://github.com/zellyn/go6502/blob/m ... al_test.go

I heartily recommend at the very least writing something that can do very simple disassembling...
eg. https://github.com/zellyn/go6502/blob/m ... /disasm.go When getting the tests to pass, I simple printed out each address, instruction bytes, opcode, and all registers at every iteration. It certainly slowed things down, but if you pipe the output through tail -20 or something, and keep a listing of the tests (which includes source addresses) handy, it's not too bad. Finding one bug tends to point you to fixing the same bug in all your other similar opcodes.

For understanding the overflow flag, I recommend http://www.righto.com/2012/12/the-6502- ... ained.html and the links he points to.

Thanks for the advice, The disassembler is on my short list of things to implement for the simulator. I want to add that, along with the ability to view/poke memory and status flags, and I also want to implement the ability to point to the correct place in a listing file of the program, much like a debugger would work.

[whartung]

In the end, on my simulator, I've added:
- a trace facility, which is a checkbox and shows each instruction, registers, status and top few points of the stack
- breakpoints (read an address, write an address, reach a PC, write a value to an address)
- a memory dump, which shows changes from view to view (so, set a break point, hit continue, when it hits the bp again, the memory view highlights the changed bytes)
- single stepping

I also track the last 100 instructions that were executed, so you know not just when you hit a break point, but how you got there.

These are all done at the emulator itself, not as a facility of the CPU. For example, I don't have a monitor -- the emulator loads memory from HEX and BIN files itself, and the CPU just starts.

All of these are pretty much useless without an assembly listing giving you addresses and such.

These are all things that I've needed in my adventures so far. I can't imagine working with a raw 6502 CPU without these kinds of tools available.

[BigEd]

Hi aaronmell, and welcome.
I've collected some links to 6502 test suites at http://visual6502.org/wiki/index.php?ti ... stPrograms
If you want a few simple cases, the ones from py65 might suit you.
But, running Klaus' suite should be fine, if you just fix things as you find them.
Cheers
Ed

[aaronmell]

BigEd wrote:

Hi aaronmell, and welcome.
I've collected some links to 6502 test suites at http://visual6502.org/wiki/index.php?ti ... stPrograms
If you want a few simple cases, the ones from py65 might suit you.
But, running Klaus' suite should be fine, if you just fix things as you find them.
Cheers
Ed

Thanks for the link. BTW, the tests for py65 seem to be returning a 404.