Writing to SCI 2 on NMIN2114

[les@windstream]

Not sure if this is a FORTH or NMIN2114 issue; it's an odd one. In "HEX", if I "61 EMIT" I get an "a" as expected on the terminal port. If I "61 emit2", where the later word emits a character to the SCI2 port on the 2114, I get a "#" sign. All the characters codes I've checked up to 5F seem to behave the same with both forms of EMIT. But above 060 hex, there is not similarity. Any ideas of what may be happening? I can work around not being able to write lower case letters for this application, but would prefer not to.

Thanks,

Les Snively

[rob]

You shouldn't be having that problem so there is either something wrong with emit2 or with your hardware configuration of SCI2. Check the configuration registers of SCI1 against SCI2 and see what is different. You should be setting it to 9600 baud, 8 data bits, no parity, one stop bit and no interrupts (unless you want more of a challenge). If you still can't locate a problem then you'll need to post some code and more details about how you are setting up the SCI port.

Rob

[les@windstream]

Thanks, Rob, for responding. Both ports are configured to the same baud rate and other settings. But the problem still persists. Here's the relevant simple minded code I'm using.

: p2XR? ( -- ) BEGIN cd0004 C@ C0 = UNTIL ;
: emit2 ( c -- ) p2XR? 00cd0007 C! ;
: nl ( -- ) a emit2 d emit2 ;
: p2Type ( addr len -- ) 0 DO DUP I + C@ emit2 LOOP DROP nl ;

Note, this code seems to work fine for any character value, e.g., it outputs something. However, for all values above 60h, emit2 displays something different than EMIT, while 5Fh and below they match. (Of course, I'm using two different terminal windows, so it's possible something is different there; Zterm for SCI1 and minicom for SCI2.) It must be something in my setup, but I haven't been able to figure out what.

[les@windstream]

Just to show what I'm seeing, here are the two outputs for all characters between 31h and 51h. First line is sci1, and second line is sci2 output.

123456789:;<=>?@ABCDEFGHIJKLMNOP
123456789:;<=>?@ABCDEFGHIJKLMNOP

Now the characters from 51h to 71h, in same order:

QRSTUVWXYZ[\]^_`abcdefghijklmnop
QRSTUVWXYZ[\]^ *#°±++++ÅÄÄ

I can't see what's special about character numbers greater than 60h, but there seems to be something different.

Les

[les@windstream]

I found the reason for the odd behavior, and it had nothing to do with the 2114 or my simple little routine to write to the second port. It seems the terminal emulator I was using was coming up in a VT102 mode, and that mode must use the character values above 60h differently than most emulators. After shifting to ANSI mode, everything is working as expected.

Les

[RMDumse]

Wonderful. Glad you caught it.

[nmitech]

Les,

For your convinience, we have a terminal window program, NMITerm for PC. It supports multiple comports at once. You can download it here, http://www.newmicros.com/download/NMITerm.zip

One thing, NMITerm does not support XMODEM protocol so if you have to reflash the FORTH Kernel, you can use ZTERM or Hypertem to do so. As far as downloading FORTH application programs, NMITerm will work just fine on Win9x/2000/XP operating systems

=LC=