6502_65C02_functional_tests VS trv

Klaus Dormann's 6502 tests don't rely on a particular emulator environment. They could be used with Ghidra.

https://github.com/Klaus2m5/6502_65C02_functional_tests

How about some assembler code to test all of the opcodes? https://github.com/klaus2m5/6502_65c02_functional_tests

https://github.com/Klaus2m5/6502_65C02_functional_tests might be worth a look, it's a comprehensive test suite

Great! (and not surprising). You may want to look into using a 6520 test suite to check correctness of your emulator, like this one -- note: I have no experience with it, but it took me some time to iron out the last error of my 6502 emulator, and in hindsight I should probably have used such test suite.

Currently i'm trying to implement 6502's instructions one by one using TDD. I was curious are there any test - corner cases already been written ? I found out ( https://github.com/Klaus2m5/6502_65C02_functional_tests ) but this requires all instructions to be implemented which I don't currently. Is there any way to test a single instruction in isolation for all the edge cases ?

By "bad branch", I mean the emulator takes the wrong branch because it fails to emulate some part of the Apple hardware properly. The 65C02 emulation has passed some pretty stringent tests (https://github.com/Klaus2m5/6502_65C02_functional_tests/blob/master/bin_files/65C02_extended_opcodes_test.lst), so I'm pretty confident in it. But the instruction trace file is around 90,000 lines, so is kinda hard to slog through.

Spike is a pure interpreter -- no JIT or anything like that. It is written to be very portable, very easy to add new instructions to, and easy to reason about whether you have done it correctly. Essentially no effort is made to get high performance. Spike was the "Golden Standard" for RISC-V semantics until some academics said "that's not good enough, you should use Sail because formal this, proof that".

The only time the RISC-V instruction set should be changing is when new instructions are being added, and during the extension development process the set of instructions and meaning or especially the binary encoding of individual instructions can change.

I have been the person doing the modifications to Spike during development of RISC-V extensions, and in particular during a quite fluid stage of the development of the Vector extension. I know how easy it is to do this. Just as easy as Sail, I would say.

Here's one example of why.

Most RISC-V emulators decode instructions using a series of nested switch statements. Zeroth, switch on non-C vs which page of C (if C is implemented) bits 1:0. First switch on the "opcode" field bits 6:2 e.g. OP-IMM or LOAD or BRANCH. Second, typically, switch on the "funct3" field bits 14:12 which distinguishes e.g. ADD / SLT / SLTU / AND / OR / XOR / SLL / SRL for arithmetic instructions or BEQ / BNE / BLT / BLTU / BGE / BGEU for conditional branches, or operand size for loads and stores. Third, for some instructions switch on the "funct7" field bits 31:25 to distinguish between e.g. ADD / SUB or SRL / SRA.

This is pretty fast and efficient and makes compact code/tables, but it is high maintenance.

Spike decodes instructions with a loop searching a linear list of MASK and MATCH values until it finds the correct instruction. So, by the way, does my simple "trv" emulator.

Here is my own complete executable C definition of RV32I:

https://github.com/brucehoult/trv/blob/main/instructions.inc

The 3rd and 4th values (the hex ones) are the MATCH and MASK values. The logic is "if ((instruction & MASK) == MATCH)" for example:

    if ((instruction & 0xfe00707f) == 0x40000033) rd = rs1 - rs2; // sub

bruce@rip:~$ git clone https://github.com/brucehoult/trv.git Cloning into 'trv'... remote: Enumerating objects: 10, done. remote: Counting objects: 100% (10/10), done. remote: Compressing objects: 100% (8/8), done. remote: Total 10 (delta 2), reused 10 (delta 2), pack-reused 0 Receiving objects: 100% (10/10), 4.37 KiB | 4.37 MiB/s, done. Resolving deltas: 100% (2/2), done. bruce@rip:~$ cd trv bruce@rip:~/trv$ gcc -O trv.c -o trv bruce@rip:~/trv$ cat >foo.s < .globl main > main: > li a0,3 > li a1,23 > call __mulsi3 > ret > END bruce@rip:~/trv$ riscv64-unknown-elf-gcc -O -march=rv32i -mabi=ilp32 foo.s -o foo bruce@rip:~/trv$ qemu-riscv32 foo bruce@rip:~/trv$ echo $? 69 bruce@rip:~/trv$ riscv64-unknown-elf-objcopy -O ihex foo foo.hex bruce@rip:~/trv$ ./trv foo.hex bruce@rip:~/trv$ echo $? 69

I completely understand. I have a toy RV32I emulator myself at https://github.com/brucehoult/trv which desperately needs even a README. I want to do it, but I keep forgetting to do it...

I didn't see what actual emulator this uses, but I have a super-simple one (sadly undocumented but the code is short!) that runs Intel hex files at https://github.com/brucehoult/trv

The easiest way would be to get a C compiler for 6502 or z80 and compile a simple RISC-V emulator such as my one at https://github.com/brucehoult/trv

If you're making the actual game, and can therefore implement the virtual machine in native code on the host machine (instead of in a shader on the GPU as here) then you can very easily get 10 to 100 MIPS performance in an emulated machine with a very simple emulator. Such as https://github.com/brucehoult/trv

Bear in mind that the original Mac was roughly a 2 MIPS machine and an early Pentium or PowerMac 100 MIPS.