also, a monitor can never be a finished product thing since it requires RAM for code storage. While it can be fun to play with it is not a fully capable development system any more than a simulator is. The issue that simulators, monitors and other things of that ilk can never help you with the REALLY pesky bugs. We have seen many posts here "it works with the simulator/monotor but not when burned into the chip" and all that can be answered is "tough"

Were I to develop anything in this range, I would develop a code module, that when included as part of the program would allow breakpoints, core dump etc, and force it linked in the top of memory. Then I would equip my system with a chip that had an interrupt (PCA5?) that I would never use and simply make ONE "irrelevant" change to the production code making that interrupt link to the start of the 'debug module'. To ensure full transparncy there should somwhere be a 'ret' that this would call when not in dbug mode. A breakpoint would be simply to insert a sbit (e.g. PCA5_interrupt_causator) where the bkpt was wanted. This way you could run 'real' and still have breakpoints etc. I do realize that such a scheme would require flash writes but, when no money is available for a real tool, what is most important? the non-interference (i.e. true emulation) of the tool or the speed of using it. Since, with modern chips, your code is likely to run on internal memory, this scheme allows implementation without external memory, thus all 32 pins available. Of course you will need internal RAM available, the size of a flash page and a few other things, but the scheme is feasible and the processor, when not breakpointed would run TRUE.

So, what is the 'cost'? you will never be able to use the top (2k?) of code memory. Also some ERAM, the size of a flash page (512?), must be unused.

Erik