How to run Klaus Dormann's 6502 test suite on real hardware with separate ROM and RAM

0
votes

I would like to run the full 6502 test suite by Klaus Dormann to test my Kansas Lava 6502 implementation. However, the code uses self-modification (see all uses of range_adr), which, while trivial to implement in an emulator, doesn't bode well for a hardware implementation: the program image needs to be stored on ROM, so the write-backs are going to be blackholed by whatever routes writes based on addressing ROM or RAM-backed parts.

The same problem, of course, applies both to synthesizing it to a real FPGA and to running it in a simulator (either the low-level VHDL one or the high-level Kansas Lava one).

Is there a way to run the test suite without doing a lengthy (in terms of cycles) dance of suspending the CPU, copying the program from some unaddressable ROM into an all-RAM memory byte-by-byte, and then initializing the CPU and letting it run? I'd prefer not doing this because simulating these extra cycles at startup will slow down running the test considerably.

1
self-modifying6502commodore

1 Answers

3
votes

Knee-jerk observations:

Despite coming as a 64kb image, the test is actually just 14,093 bytes of actual content, from $0000 up to $370d, then a padded fill of $ffs up to the three vectors in $fffa–$ffff. So you'd need to copy at most 14,099 bytes rather than the prima facie 65,536.

Having set up that very test suite in an emulator I wrote yesterday (no, really) the full range of touched addresses — using [x, y] to denote the closed range, i.e. to include both x and y, is:

  • [000a, 0012], [0100, 0101], [01f9, 01ff] (i.e. the stack and zero pages);
  • 0200;
  • [0203, 0207];
  • 04a8;
  • 2cbb;
  • 2cdc;
  • 2eb1;
  • 2ed2;
  • 30a7;
  • 30c8;
  • 33f2;
  • 3409;
  • 353b; and
  • 3552.

From the .lst version of the program, that means all you need to move are the variables with labels:

  • test_case;
  • ada2;
  • sba2;
  • range_adr;

... and either move or remove the routines that:

  • test AND immediate from 2cac down to 2cec;
  • test EOR immediate from 2ea2 to 2ee2;
  • test ORA immediate from 3098 to 30d8;
  • test decimal ADC/SBC immediate from 33e7 down to 3414 (specifically to include chkdadi and chksbi);
  • test binary ADC/SBC immediate from 3531 down to 355d.

All the immediate tests self modify the operand. If you're happy leaving that one addressing mode untested then it shouldn't be too troublesome.

So, I guess, edit those tests out of the original file, and you can safely relocate range_adr to the middle of the stack page if my simulation is accurate.