I've started to write a 6502 emulator (my first ever emulator) and have been doing a bit of research on the 6502. I came across Klaus Dormann's test suite and I would really like to use this to test my emulator.

My problem is that I don't think I have enough experience to know what I'm supposed to do with it. Here's what I think I understand:

1. Assemble with AS65
2. Load binary and set PC to $0400 (does this mean the binary should start at $0400 or that it should be loaded at the beginning of memory but the PC starts at $0400?)
3. Start program.

At this point I'm not sure what's supposed to happen. The comments in 6502_functional_test.a65 say: "Loop on program counter determines error or successful completion of test." OK, am I supposed to somehow detect this condition? How? Another comment gives a hint: "No IO - should be run from a monitor with access to registers." OK, but I still wouldn't know what I'm looking for.

This blog post gives a bit more insight but I'm still left wondering what to do. It says:



How do I then figure out what test failed?

I also see that there's a configuration variable "report = 0" which seems promising and when I look in report.i65 it does appear that there is a way to get some output when a test fails but, again, I don't know how to do it.

As you can see I'm pretty inexperienced with this stuff and would appreciate some direction. If there's an existing tutorial, that would be ideal.

Thanks!

What I did, as I didn't have enough working to have any kind of terminal output, was to set my emulator to run for a fixed number of cycles (I used 1000). This can be a large number, it doesn't really matter how many, but when the emulator stopped, either the program counter was at the end of the test suite or was in an infinite loop. I then looked at the source code to see what test failed.

Normally the failure is something like a status flag that is incorrect, and that is what causes the code to enter the infinite loop. You'll then have to look at the preceding instructions and figure out where your emulator went wrong. It helps to look back at the data sheet to see what flags a particular instruction sets and compare this with your code. You should be able to trace back in the source to see where it went wrong and what is wrong with your emulator. You'll get very familiar with the instructions, but you need this to write an emulator anyway.

Load binary (usually from where the variable zero_page points to, in the predefined binary test I replaced org zero_page with org 0) and (then) set PC to $0400

Yes you need to be able to detect this condition! You must have a user interface to display the registers and memory. While the test is running display the program counter from time to time. If it doesn't change anymore look up the address in the test's listing to determine what was beeing tested. Interrogate the other registers and the memory locations beeing used in the listing and verify that with the expected behavior of the opcode under test.

It requires a functional output vector to a display, ideally a serial interface to a terminal. Since a lot of opcodes need to be in working condition for the interface to work propperly, that option is not really meant for the initial debug of an emulator.

There is a 3rd option to flag errors by changing the trap_xx macros to include a specially handled opcode in your emulation. The famous HCF opcode comes to mind - halt and catch fire. Just check out how report=1 does that (not the HCF of course but JSR).

_________________
6502 sources on GitHub: https://github.com/Klaus2m5

(Welcome tmciver! I'm sure you'll enjoy the journey, and get a lot of help here.)

I am probably also going to test this at some point, so a further clarification may be needed.

You indicate that a variable "zero_page" should point to the start of the Loaded binary. Can this variable be anywere in memory?

What does "org 0)" means?

How does setting PC to $0400 relate to the starting point of the binary?

If you search for zero_page in the source code you will find its definitionand later the variable is used to organize the start of zero page locations used by the testSo it is not a variable to the test but a variable to the assembler to tell it where to start allocating bytes in zero page. The binary output of the assembler will be a continuous block of bytes from the lowest (zero page) to the highest byte (Reset/IRQ/NMI vector block) and unused or uninitialized areas are padded with $00 in this block.

org is an assembler directive and tells the assembler where to put things. In this case it simply means: start at location zero. So instead of org zero_page I usedso the binary output would actually start with location zero with padding up to where zero page addresses are actually allocated.

This is where program execution starts and points the program counter to the first executable opcode in memory.

In general: For assembler directives and how they work please read the assembler manual. For how the test is configured refer to the source code which has quite a bit of explanation for each test parameter. The preferred assembler output of the test is Motorola or Intel Hex and not binary. The Hex formats carry all the information where things go and where to start while the binary does not.

_________________
6502 sources on GitHub: https://github.com/Klaus2m5

Just to note, Klaus' supplied bin files are 64k in size, which is ideal for loading into an emulator as a complete memory image. You then need to start the program at 0400 - again, in an emulator, this should be easy.

@BigEd Thanks for the welcome and thanks to everyone who has given feedback.

@Klaus2m5 I think I have enough to get started, so thank you!

One question that remains (and this will show you just how green I am with low-level programming) is how to load the output of the assembler into memory. I believe I need the binary output and am not sure what to do with the Motorola or Intel hex. Are there loaders that know what to do with this?

Thanks again for all the help. I just need a bit of hand-holding and then I'll be off and running!

On startup of the emulator you could just simply copy the binary into the address space of your emulation. However, I expect somebody being able to write an emulation also to be able to write a loader for that emulation. Since we don't know anything about the planned platform for the emulator there is no way to tell wether there are already loaders for one or the other format. A loader coded in 6502 machine code wouldn't help as the next question would be: How do I load the loader?

_________________
6502 sources on GitHub: https://github.com/Klaus2m5