it is certainly true that the optimal amount and kind of testing depends on your development environment. if for some reason you find yourself writing 6809 assembly, here are some ways you can make testing cheaper
- don't write the tests in assembly. there are c compilers. forth is also a fine option. or you can test manually from a debugger or monitor program
- forth makes a decent monitor program and macro assembler and is scriptable for testing. it's maybe a lot better at that than it is at being a programming language. there are reportedly very good forths for the 6809
- don't do the development self-hosted. you can simulate a 6809 on a laptop or cellphone hundreds of times faster than real time, and the author is in fact doing that. if you have a big computer with either a 6809 simulator or a debugging umbilical to your 6809, you can run the test scripts on the big computer instead of the 6809, while running the code under test on the 6809, real or emulated. then you don't have to write your tests in c or forth; you can write them in tcl, python, js, lua, squirrel, or whatever you prefer. they can control the 6809 like a marionette, and you can use property testing frameworks like hypothesis, which would be very ambitious to implement on the 6809
- maybe non-time-critical parts of your logic can be written in a language that can be compiled to either the 6809 or the big computer, such as c, so you can test it compiled natively on the big computer. cross-compiled to the 6809, this will generate bloated code that uses more memory, so it depends on how tight you are on space, though the 6809 isn't quite as unfriendly to c as something like a 6502 or pdp-10
- the exception is that if you write the non-time-critical parts in an itc forth instead of c or something, it won't use an unreasonable amount of memory, but it will be a lot slower and more bug prone
disclaimer, I haven't programmed a 6809 since 01985, and then it was in basic, and my forth isn't all that hot either