If you can't provide with something better, then don't discourage others.

I did work with ICEs in 1990 and if anyone gave me a unit with such performance today I would severely hurt him. For that reason I do not think an article that is 15 years old has relevance today.

Here is Jacks view on the same:

quoting from
http://www.embedded.com/shared/pr...D=15300080
The ICE hardware design was simple, using only 17 integrated circuits. The emulation processor was also the ICE control CPU. A bit-banging UART made the software more complex but saved a chip or two.

The firmware was a nightmare and also more fun than you can imagine. On a breakpoint, the CPU had to store the entire context of the executing program. Since I'd made the ridiculous decision to use no target-system resources, when transitioning through a breakpoint the hardware had to swap in local ICE RAM and turn off user memory. State-saving PUSHes stashed information wherever the user's stack pointer had been—anywhere in the ICE's address space. Hardware stripped off some of the address bits to ensure the data went into the emulator's RAM, but the need to minimize chip count meant it was usual for the writes to wipe out local variables used by the ICE. Reconstructing the data while correctly preserving the target context was quite a challenge. It was a cool design, though I probably should have used more hardware to simplify the code.

Erik