High Bit Stripped

[art kennedy]

Following is a routine I have used for a long time on a NMIX board with MAXFORTH
version 3.3. It works great. I use it for debugging. Just insert SHWAIT in the
code for a word and when execution reaches that point it shows the stack in a
nifty little frame and waits for a key. The frame is made of PC box characters,
in case you're not viewing this message that way and were wondering.


: SHWAIT ( shows stack preceeded by new line and waits for key
CR ." „¡„Ÿ„Ÿ„Ÿ„Ÿ„Ÿ„Ÿ„Ÿ„Ÿ„Ÿ„Ÿ„Ÿ„Ÿ„¢" .S CR ." „¤„Ÿ„Ÿ STACK „Ÿ„Ÿ„Ÿ„£" KEY DROP
;


I am working on version 2 of my project and my new NMIX board has version 3.5E
of MAXFORTH. Not good!! The frame characters have the high bit stripped when
loaded and I have had to create an AWFUL kludge to correct them. Of course my
communication setup is for 8 bit transfer and still works porperly with the
older board.

What is happening here and how do I fix it???

[RMDumse]

I can speculate on what happened, although I don't yet know how to fix it.

In V3.3, if you got a character with the 8th bit accidentally set, and it was passed that way to the parser, the dictionary search would fail in an endless loop. This made embedded applications using the Outer Interpreter and dictionary look up functions "dangerous". So we had an app note how to intercept the serial and strip the 8th bit. SO I suspect when we did V3.5, we responded to pressure to prestrip the 8th before passing it to the interpreter.

I'll have to research a bit more to look at the actual implementation and if it can some how be bypassed for the opposite purpose.

[art kennedy]

Great! Thanks. I'll watch for the fix.

[RMDumse]

I'm thinking now, you would have to rewrite from KEY on, so it would require rewritting ABORT which calls QUIT which calls QUERY INTERPRET so you'd have to rewrite QUERY, and it calls EXPECT which calls KEY.

Is it worth this level of effort?

[art kennedy]

Nope! Thanks anyway. I've already dumped the kludge and substituted underscores etc for the graphic chars.