Date   : Fri, 17 Dec 1982109:07:00-PST
From   : bridger@Rand-Unix
Subject: Interrupting CONOUT with CONOUT => lost data?

       I've been using a clock/calendar that interrupts once a second and
calls a service routine that sends the current time to the bottom right
corner of the terminal screen.  To do this it sends escape sequences to
save the cursor, position it, and restore it.  The characters are sent
by  BIOS calls to CONOUT.
       Randomly, the terminal would print the time but then fail
to restore the cursor, or switch into reverse video or some other mode.
Things got worse with a new terminal rom (the Super19 ROM for the Heath
H-19) running at 38.4K baud, because this rom has a host of new
escape sequences for extra modes, some of which reinterprete the 
standard ASCII characters.  Having the terminal suddenly in never-never land
is a real pain; to recover you have to go into off-line mode, and reset
the correct modes.
       It turn out that the BIOS is sending characters to the terminal
when it isn't ready to accept them.  At least one gets lost; when the last-
arrived character is an Escape, and its successor is overtaken by another
character, the terminal switches executes a faulty sequence.  For example:

       'ESC k p' --  'ESC k' is restore cursor, 'p' is data
       If 'k' is overtaken, the terminal executes 'ESC p' = reverse video !

       My CONOUT implements hardware handshaking, using the H-89's
8250 serial chip.  I assumed that this, coupled with handshaking by the
H-19 terminal, would prevent dropped characters.  

       NOT SO!! -- because the interrupt routine uses the console output data
port the following sequence of events can and does occur:

       main program sends character to CONOUT
               CONOUT checks clear-to-send line:  it's clear
               now clock interrupts
                       saves registers
                       clock routine sends a string of characters,
                          filling the terminal buffer
                       terminal turns off clear-to-send line: not clear now
                       restores registers & returns
                 character sent to terminal (!!)
                 returns to main program
       
       In other words, the real-time status of the CTS line changes from
the time CONOUT reads the line to when it outputs the character.

       Solutions: (1) disable interrupts before reading CTS, enable after
sending the character; have the clock routine use a private version of CONOUT
that doesn't enable interrupts.  (2) Set a flag on entry to CONOUT, reset it
on exit; when flag is set have the clock routine poll CTS until clear before
returning.
       This complexity wouldn't arise if the 8250 had on-chip handshaking
(like the Z-80 SIO) and didn't send out a character until the CTS line
is clear.  I guess the moral is not to trust an interruptible handshake!

       My suspicions that the Super19 ROM was at fault were unfounded, and
I appreciate the time Bob Todd at Extended Technology Systems took to check 
out my questions.  It is indeed a high performance addition to the H-19.
With hardware handshaking and 38.4K baud, text can be redisplayed and edited
very effectively.  
       Now I'm curious to see what the game writers can do with it!
       .


*** Problem during mail receipt from Arpanet ***