Hi Matthias, Thanks for the reply. I've made a small breakthrough, although I don't have it working yet. Initially the only difference between a setup that worked and one that didn't was that the scenario that failed ran on battery power and had an xbee radio plugged in rather than an ftdi USB chip. Debugging over the USB is a nightmare because you can't get to forth - just send xbee packets.
However, I can now recreate the problem over USB, and it seems to be a hardware oddity. If I disconnect the USB power link and run the board off batteries it fails to update the counter. However, I have to boot the device off batteries and then plug the usb in for it to stop incrementing. If I have the USB board plugged in first it increments the counter properly. I guess the tx and rx lines are giving some power to the device, which is a bit naughty, but it didn't go bang ;) So, it appears to only take effect when it boots on battery power. Why this buggers up evaluate but the rest of forth works ok is very bizarre, but that seems to be the situation. However, after my turnkey has finished and I'm dropped back to the prompt, evaluate works!?? I have a couple of questions: Can I safely use (evaluate) by itself when evaluating RAM strings? It just makes it less complex and in my final application the string to execute will come over the xbee and will be in RAM. Also, can you explain the stack comments that you have put on (evaluate) \ i*x addr len -- j*y Many thanks for your help. David ------------------------------------------------------------------------------ Slashdot TV. Video for Nerds. Stuff that matters. http://tv.slashdot.org/ _______________________________________________ Amforth-devel mailing list for http://amforth.sf.net/ Amforth-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/amforth-devel
