• Please review our updated Terms and Rules here

Soroc serial terminal - Part 4. The software


Veteran Member
Apr 24, 2009
Canberra, Australia
I wanted to keep the boot time as close as possible to the fast boot of the original ROM-based terminal - basically the few seconds it took for the CRT to warm up. With the available system unit (a Pentium 2 Compag Armada 7800), the software boot process would be:

1. Powerup, BIOS redirects monitor to VGA output port
2. Boot to DOS 6.22
3. Configure text-mode display, 640x480, green foreground, black background.
4. Configure keyboard remapping
5. Launch terminal emulator configured for 9600,8,N,1
6. From terminal, operate S100 system at ROM monitor or run CP/M 2.2

The console configuration is managed by the GPL'd NANSI.SYS, which has a better console control range than Microsoft's ANSI.SYS. Most original serial terminals had built-in functions that are beyond the scope of ANSI/NANSI - such as Send Line, Break, Print, and Page functions. They are not needed for the basic function of the terminal as RS232 serial client console. They reflect that serial terminals often operated as sort of primitive "thin clients" to multi-user host systems.

Nansi.sys is loaded by DOS in config.sys.

Autoexec.bat calls a file Remap.bat, which is a series of ECHO commands which send ANSI escape sequences (ASCII strings) to the console, that NANSI.SYS interprets and implements as console configuration. Each key remap command is a separate string of an arbritrary number of characters. For convenience, I included the console FG and BG color and clear commands in remap.bat. The only limitation is that NANSI can only hold 100-bytes of remap information, which is ample for single characters or ANSI escape sequences, but can not be used for unlimited slabs of boilerplate text.

Next autoexec.bat types a file that displays the Soroc bootsplash.

Autoexec.bat's final command is to launch the terminal emulator, displaying nothing but a flashing prompt.

There are a great many DOS programs that offer terminal emulation. Most include bells and whistles, such as modem controls, dial-out routines, capture routines or diagnostic screens. These are redundant for a simple terminal function. Eventually I found a very, very small and simple program called NRDterm.com which somebody had kindly made available online.

The final software layer is the way that CP/M-based programs can drive the Soroc console. CP/M will not be aware of the VGA display but CP/M applications may send ANSI escape sequence strings to the console where NANSI.SYS will interpret and apply them.


In my case, WordStar 3.0 is my most important CP/M application and it uses many display control functions for positioning, scrolling, and highlighting. Careful patching via WordStar's internal patch system (in the INSTALL program) managed most of these functions.

It took some experimentation (and some Forum) advice to work out how Wordstar could highlight text by turning inverse video on and off.

I found that the standard ANSI instruction for reverse video not only assumes a monochrome display, it also resets any color attributes when reverse video is invoked or cancelled. The ANSI or NANSI documentation says the command "inverts foreground and background", but this does not apply (in my experience) to foreground and background set with the ANSI color attributes, which I need for the green phosphor emulation.

My inverse video function would need to use the set color escape sequence to set foreground black, background green. Then another set color to reset to foreground green, background black.

The problem here was that Wordstar's patch area for the inverse video commands allows only six bytes per command, where I needed a minimum of eight bytes.

The solution was to use that patch area to nominate an extended ASCII character as a "flag" for each command, then write a separate filter routine for Wordstar's console output, that would capture the "flag" character and substitute the necessary escape sequence in the console output stream. WordStar offers a patch location to point to a custom output routine, and some scratch space to locate code segments. The patching is done in HEX, so the assembler code is compiled externally then typed manually, byte by byte, into the scratch space at the selected address.

There is also scope to have WordStar, or another CP/M application, reprogram Soroc function keys by sending the necessary escape sequences to NANSI.SYS in an initialisation string when the application is loaded. So far I have had partial success with that. There are complications with the way that WordStar intercepts Ctl [key] pairs for its own internal command interpreter. Some seem Function key outputs seem to become lost as they pass through Wordstar, CP/M, NANSI.SYS, DOS, NANSI.SYS again, CP/M again, and WordStar again.

However, this is "authentic", because I remember that the original Soroc was also very limited in its response to function keys over WordStar. This remains a teaser for the future.