In the "why didn't I think of that" category I had a suggestion over on AVR Freaks.

Use a larger chip with enough free pins to emulate the 85 while handling the the ISP programming as well.

The trouble is if you want to use the USI in the target application you are back to the same problem, ie sharing ISP pins with the programmer and you can't remap the USI function to different pins on AVR processors...or so I thought.

With the Tiny861 you can map the USI pins to another port while leaving the SPI functionality on the original pins, so it should be easy to design a small adapter board and write code with conditional blocks to run on either chip, 861 for developing ans 85 for application.

I still might build Mk1 because it is a more geniune emulation, for example you can use AREF with Mk1 but that's not practical with Mk2, but MK2 has a lot more potential for debugging because it has links to the outside world to display data and trigger test equipment.

ASM code running on the target processor. This sits on the watch dog interrupt and serves data one byte at a time to the control processor. This runs entirely in the background and uses almost no target resources.

Arduino code running on the 328. This handles a set of commands from the PC, asks for data from the target processor, and returns the data suitably formated.

Note that at this point the monitor only works with absolute addresses in HEX format and as such is more aimed at assembly programmers. However I plan to write a GUI front end which should be able to interrogate the MAP file and work symbolically.

However I plan to write a GUI front end which should be able to interrogate the MAP file and work symbolically.

To support the GCC debugger, I suspect the compiler / linker are capable of outputting a symbol table. It's probably less work to "steal" the symbol table code from the GCC project than it is to write code to parse the MAP file.