WordStar or CP/M patches for VT100 terminal
s100fan
I've been searching this group and other forums for help to get
maximum compatibility between WordStar (3.0) and a VT100 terminal on
CP/M 2.2.
A few years ago Edmund Cramp and Roger Ivie had this exchange here on
the same topic..
<begin quote>
On 2005-01-21, Edmund Cramp <eacn...@emgsrus.com> wrote:
> One issue to be aware of when taking to a real VT100 is that
> the only handshaking that a VT100 understands is XON/XOFF ...
> and as far as I remember, sending an XOFF to the terminal means
> that it will stop transmitting within 32 bytes - it's not an
> instant command.
The problem is actually the other way 'round. The VT100 likes to
send XOFF and it likes to send it a lot. And XOFF is a WordStar
command. The good news is that when it sends an XOFF, it doesn't
take long for it to catch up and send an XON. It's possible to make
your BIOS (or a custom WordStar console input routine) start a short
timeout to determine whether an XOFF is real or generated by the
terminal.
Seems to me there was a patch to make WordStar deal with a terminal
that sends XOFF a lot; or maybe I'm thinking of 4.0. My 4.0 docs are
unavailable just at the moment.
--
Roger Ivie
<end quote>
According to the VT100 Programmers Guide, the VT100 has a 64-character
input buffer. When it fills to 32 chars, it sends XOFF to the host. If
the host stops transmitting, the buffer depletes. When it holds 16
characters, the VT100 sends XON. If the host doesn't respond to the
XOFF, there will be buffer overflow at the VT100.
This becomes more complicated when WordStar uses ^S (XOFF) and ^Q
(XON) as application commands.
I'm hoping someone might have more suggestions on where to find the
solutions that previously must have been used for exactly this
problem. There's the general VT100 hand-shaking issue plus the
specific command code conflict. A WordStar input routine, or a CP/M
BIOS patch, or both? Or maybe just slowing down the serial ports?
Rick
Roger Ivie
> Or maybe just slowing down the serial ports?
Good luck with that. I wasn't kidding when I said the VT100 likes to
send XOFF a lot. It's quite underpowered with its little 8080 whirring
away. I know that a VT220 will generally behave if you keep it below
9600, but I don't recall at which baud rate a VT100 can keep up.
As for handling the issue, I wasn't involved in the configuration of the
systems on which I've used actual VT100s, so I don't have stuff lying
around. And I still haven't figured out where I put my WS 4.0 documents.
--
roger ivie
ri...@ridgenet.net
Peter Dassow
>
>> One issue to be aware of when taking to a real VT100 is that
>> the only handshaking that a VT100 understands is XON/XOFF ...
>> and as far as I remember, sending an XOFF to the terminal means
>> that it will stop transmitting within 32 bytes - it's not an
>> instant command.
>
> The problem is actually the other way 'round. The VT100 likes to
> send XOFF and it likes to send it a lot. And XOFF is a WordStar
> command. The good news is that when it sends an XOFF, it doesn't
Usually you can choose between software (XON/XOFF) and hardware (RTS/DTR
and CTS/DSR) handshake, when using a RS232 interface.
So is there no possibility to set up a VTxxx terminal to use hardware
handshake (and then XON/XOFF will not be used anymore) ??
Regards
Peter
s100fan
Sadly, the VT100 (1976 design) has no hardware handshaking capability,
only XON/XOFF.
I will experiment with baud rates for the buffer overflow problem.
Let's face it, nobody runs CP/M text applications on ancient hardware
with expectation of blazing speed! I hope I can avoid putting an XON/
XOFF routine on the CP/M serial port.
For the WordStar control code conflict, I'm thinking about how an
application IO routine could step around it - possibly by having any
^S or ^Q translated into alternative bytes (maybe 1CH and IDH) spook
the terminal? The application commands would also have to be patched
for the alternative bytes, but WordStar allows for this I think.
If the buffer overflow issue is solved by baud rate, then the control
code issue may disappear as well, since any XON/XOFF issued by the
VT100 will be ignored. I think WordStar will not send XOFF (13H) by
itself to the terminal - it echoes "^S" as the two readable ASCII
character codes, not the control code.
Rick
PC Pete
>
>I've been searching this group and other forums for help to get
>maximum compatibility between WordStar (3.0) and a VT100 terminal on
>CP/M 2.2.
This isn't probably going to be directly helpful, but I do know it's quite possible to patch WS 3.x to work perfectly with a genuine VT100 terminal, because I spent a day
and a half doing just that for one of our bigger (government, i.e. "fussy") customers. It was on a TurboDOS system (CP/M workalike), which already used XON/XOFF for
master/slave attention sequences, on top of running WS on the slave.
I do remember that I couldn't get WS to work while running on the master, due to the way TDOS intercepted the sequences, but I also remember that patching WS.COM was all
that was needed. From memory, I used one of the many VT100 patches from the various bulletin boards, but I also remember that the final patch used more than the basic
patch provided. I'm very sorry, I can't remember exactly what was changed (too old/too early in the morning/too stupid)...
I've been trying to find my notes for that time, but they're still out of my grasp (but not lost). If all else fails, post an update and I'll get the missus to unpack my
old system and I'll see what I can turn up.
Best of luck with your search, and please post back here if you do manage to find a workable answer!
Cheers,
PCPete
PC Pete
>I will experiment with baud rates for the buffer overflow problem.
>Let's face it, nobody runs CP/M text applications on ancient hardware
>with expectation of blazing speed! I hope I can avoid putting an XON/
>XOFF routine on the CP/M serial port.
The "worst case" scenario was scrolling a full page of text. If you can arrange the baud rate so the buffer doesn't overflow THEN, you should (ha!) be safe... You *could*
patch your display line width to be less than the terminal's buffer size wide, then use an end-of-line delay to give it time to catch up. I'm sure other folks will have
much better ideas!
>For the WordStar control code conflict, I'm thinking about how an
>application IO routine could step around it - possibly by having any
>^S or ^Q translated into alternative bytes (maybe 1CH and IDH) spook
>the terminal? The application commands would also have to be patched
>for the alternative bytes, but WordStar allows for this I think.
I spent half of my first day disassembling the VT100 ROM (who used soldered MASK ROMs that early in the production sequence, for Pete's sake? :), but while I could
identify the XON/XOFF chars as data, they appeared in the firmware so many times as immediate data, that I decided to do it from the WS end instead. But changing a ROM
(even a mask ROM) in such an old terminal would be a minefield, I'm afraid.
>If the buffer overflow issue is solved by baud rate, then the control
>code issue may disappear as well, since any XON/XOFF issued by the
>VT100 will be ignored. I think WordStar will not send XOFF (13H) by
>itself to the terminal - it echoes "^S" as the two readable ASCII
>character codes, not the control code.
One of the VT100 "patches" I tried did just that - it only changed the "caret,S" characters echoed by WS! Not so much of a patch as a band-aid...
Hope some of this gives you some ideas.
-PCP
Fred J. Scipione
"s100fan" <s10...@gmail.com> wrote in message
news:f30316ff-1e62-4ba8...@d26g2000prn.googlegroups.com...
The Conkey BIOS has 2 interfaces to the terminal. One catches
XON/XOFF characters and lets them throttle flow from the computer
to the terminal. That interface also looks for an escape character
(which was not the ASCII <ESC>) that tells it to transform the next
character into a control code equivalent (i.e. C -> ^C). The
transformed character is just passed-on through the BIOS, without
being acted upon. The other interface did no character processing.
You chose the desired interface with the I/O-Byte through the
STAT command.
With the 'smart' interface active you need to type the escape
character, followed by a 'Q' or 'S', to send <^Q> or <^S> to
WordStar. I'm sure that if you were trying to send a control
character from the keyboard via the escape prefix while the screen
was actively scrolling, there was a chance that one of the VT100's
flow control characters might have been 'escaped' instead. But,
I'm also sure that most users would only be trying to send such
codes when the display had stabilized.
Roger Ivie
>
> The "worst case" scenario was scrolling a full page of text.
I would expect the worst case to be something like clearing the screen,
then moving the cursor to the bottom (i.e., into the region being cleared).
Wait; the VT100 has smooth scroll, right? That'd be pretty nasty.
--
roger ivie
ri...@ridgenet.net
glen herrmannsfeldt
>> The "worst case" scenario was scrolling a full page of text.
> I would expect the worst case to be something like clearing the screen,
> then moving the cursor to the bottom (i.e., into the region being cleared).
The clear can be done in a simple store loop.
> Wait; the VT100 has smooth scroll, right? That'd be pretty nasty.
Text only terminals with smooth scroll usually have the ability to
initialize the character row counter. That is, not like scrolling
a bit map. It should also be able to use that for full page scroll,
though that depends a little on the hardware.
-- glen
Roger Ivie
> Text only terminals with smooth scroll usually have the ability to
> initialize the character row counter. That is, not like scrolling
> a bit map. It should also be able to use that for full page scroll,
> though that depends a little on the hardware.
Yes, but it's still scrolling slowly; it can't put new stuff into the
screen until it's scrolled the old stuff off. At some point it's going
to have to say "wait a minute! I'm still scrolling here!"
--
roger ivie
ri...@ridgenet.net
PC Pete
>On 2011-03-20, PC Pete <PCP...@audiography.com.au> wrote:
>>
>> The "worst case" scenario was scrolling a full page of text.
>
>I would expect the worst case to be something like clearing the screen,
>then moving the cursor to the bottom (i.e., into the region being cleared).
And a new, blank WS document page would also stress out the video interface part : all that highlight/lowlight and blank fills to the full width of the screen, plus as
many rows as it could deal with.
For some reason, I recall the scroll _direction_ was important; can't remember why. It made sense at the time...
-Pete
Jeff Jonas
> all that highlight/lowlight and blank fills to the full width of the screen,
> plus as many rows as it could deal with.
I agree that it would stress the data transfer
since it MIGHT fill the entire screen.
But if it's painted from top to bottom in order,
then it's just filling the memory, not doing block moves
like character or line insertion or deletion.
Even a "dumb terminal" like the ADM3A could do that with ease.
> For some reason, I recall the scroll _direction_ was important;
> can't remember why. It made sense at the time...
My guess: scrolling UP was fast and easy
for terminals that supported line ERASE
since that moved up all lines below,
and then just append the new line at bottom of the screen.
It looked good since the line immediately disappeared
and the terminal locally moved up the subsequent text.
Scrolling DOWN required the terminal to insert a blank line
and then fill in the line one character (and attribute) at a time.
It didn't look as graceful
since you usually saw the new line as it was filled in.
That's why I stayed away from having to write such low level things.
Even with Unix's termcap and terminfo,
an emulation layer is required for terminals that do not support
all the required commands (usually repainting the entire screen).
s100fan
one of you might locate WS patch code that worked for you, in the
past, on a VT100.
Meantime, I'm working on a CP/M utility to modify console baud rates
for test purposes.
In V.1 I made the mistake of making it progressively interactive -
forgetting that when the routine sends its first configuration byte to
the UART, the console freezes!
Next version will put the whole set of option bytes together (select
port, select baudrate LSB+MSB), warn the user he is about to lose his
console access, then fire the kamikaze string at the console port.
VT100 baud rate can then only be programmed to match from the VT100
SETUP options - the VT100 has no option to be programmed externally.
For those interested in scroll rates, I did some tests using my semi-
patched WordStar commands for continuous scroll.
If the VT100 is set for smooth scroll, WordStar scroll crashes
completely.
If the VT100 is set for jump scroll (whole line at a time), the
WordStar fastest continuous scroll rates are:
Scroll up - 2.5 lines per second (whole page refresh)
Scroll down - .8 lines per second (whole page refresh)
There is minor speed variation according to length of lines, and of
course about .4sec pauses for each FDD access.
Remember, this is a terminal on 8080, CPU on 4Mhz Z80.
For these tests, terminal and computer port were still on 9600 baud.
The main problem remains the VT100's interpolations of XON and XOFF
that WordStar interprets as command strings ^S and ^Q.
Any known working code from a similar environment would be most
welcome!
Rick
s100fan
is interested in the Z80 Assembler source code, "reply to author" - I
think code is better exchanged off-line. It's hardware-specific but
could be adapted easily).
I was able to test WordStar/VT100 at 9600, 4800, 2400, 1200 and 600
baud.
NO difference in the error rate at any port speed - just a pretty-well
linear relationship between screen refresh speed and baud rate.
The display corruption and eventual crashing comes only when Ctrl and
ESC commands are entered.
At WordStar's intial "non-file menu", commands with straight ASCII
letters function correctly.
None of the Ctrl-prefixed commands work. With 2 presses of Ctrl key,
the ^Q menu appears even with no press of Q. When a ^Q menu command is
activated with a second key (eg Z for continuous scroll), it can be
stopped as intended with ESC. But when any further commands are
entered, parts of strings, that should be VT100 escape sequences for
terminal control functions, start appearing on the screen as ASCII
characters. Then the end is nigh for that session and I reach for the
hardware reboot and terminal reset.
If I wasn't getting clean ASCII display in other programs, I would be
thinking something might be off the rails at bit level. I have the WS
Customization Guide so I'm going to have to check command dispatch
tables against VT100 control sequences. Unless Pete or other veterans
can solve all my problems from their historical documents.
BTW I have searched the Walnut Creek archive for old BBS material but
not found anything for WS on VT100.
Rick
David Griffith
> Further update: I've got the baud-adjusting utility going (If anyone
> is interested in the Z80 Assembler source code, "reply to author" - I
> think code is better exchanged off-line. It's hardware-specific but
> could be adapted easily).
I'd very much like to see this packaged up and added to the appropriate
archives and mirrors. Something like this should not be lost again.
--
David Griffith
davidmy...@acm.org <--- Put my last name where it belongs
s100fan
hours with the VT100 Programmers guide and the WordStar Customization
Guide (RTFM!). These are available online.
VT100 has to avoid 2 different buffer overflows - a 64char input
buffer and 7char keyboard output buffer. The symptoms that I have been
seen may have been caused by either or both kinds of overflow.
VT100 will interpret any ^S as XOFF, so should never receive 13H from
WS.
VT100 will interpret any ESC as a command string prefix, so should
never receive 1BH unless part of a programmed control command.
WS provides patch space for User-provided console input and output
routines.
What I propose is console i/o routines to:
1. Filter input to drop IBH and have 13H set XOFF flag, 11H reset
flag.
2. Output routine to poll XOFF flag, filter out 13H.
WS does not really need ESC or ^S commands - standard uses have built-
in alternatives or can be patched to a different key combo. Menus can
be patched to reflect that.
Fred Scipione referred helpfully to relevant BIOS patches. I'd prefer
to keep the patches within WS, if I can make it work. It's more of a
hassle to propagate BIOS revisions over a whole library of disks.
My system has now developed a hardware problem in the FDD controller,
so I can't test any further till that is fixed.
But I'm still keen to get any further advice!
Rick
Bill Pechter
The DEC VT180 ZCPR2/3 bios had a routine to handle Wordstar built in.
I'm trying to find the information they used... It's been a long time.
I think they translated ^S to ^[[D (Left Arrow).
You may want to try to find a source copy of Bernie Eiben's ZCPR bios
for the VT180 somewhere online for how he did it. It used standard
cp/m calls for I/O -- but you'd have to adapt it to your hardware.
The vt180 used interrupt driven I/O on cp/m so it's pretty slick
for a 64k box.
I found my Mex 114 overlay code which had the following in it:
; Title - Overlay file for MEXxx
;
REV EQU 36 ; V 3.6
;
;
;This Overlay File supports the DEC Micro VT180 with CP/M.
;
;We use the COMM-Port of the Micro's. Baud-rates are "parallel"
;to the console Baud-rates - no need for a "special" baud-rate
;routine. Since the COMM-port is I/O-wise Reader/Punch, we use
;the BDOS calls.
;
;To test for COMM-status , we use I/O byte redirection in
;conjunction with direct BIOS-CONSTAT call.
;
;This technique although a little bit slower than direct I/O
;using Interrupt on INPUT is general enough to be system
;independent.
;
; - B. Eiben DEC Large System Marketing Marlboro Mass
;
; And more or less bios version independant.--Bill Pechter
;
;***********************************************************************
;
; 5-Jun-1984 Adapted from M7VT-2.ASM by Bernie Eiben.
; Rev 1.0
; Stu Fuller
;
; 17-Mar-86 Version 3.4 removed ZCPR2/3 bit manipulation. That will
; Bill Pechter now be done by poke commands in Mex/Mexplus Ini.Mex.
;
; 22-Aug-86 Version 3.5 test to fix sendout. Added test for status
; Bill Pechter and RETJNK to avoid hanging.
;
; 29-Aug-86 Final Version 3.6 supports full Remote operation.
; Bill Pechter Support for future versions from me not available
; as they will be made specifically for my modified Robin.
;
;______________________________________________________________________________
;
; ZCPR2 ZCPR3 ZCPR3 with RCP
;______________________________________________________________________________
;
; change contents EA3CH EAFEH E240H
; at this address
; to 64H from 74H to
; disable wordstar
; ^x^s cursor key
; translation.
;______________________________________________________________________________
;
; change contents EA60H EB1CH E31CH
; at this address to
; 01 from 05H to
; disable the
; automatic xoff-xon
; transmission.
;
;------------------------------------------------------------------------------
;
;bios code looks like this--example using ZCPR3 without RCP
;
; Port# Port control data
; block
;
;contents: 41H 74H 00
;address eafdH eafeH eaff
;
; QMRCVFL EQU 01H ; Mask to allow me to send XON/XOFF
; QMXOFFD EQU 02H ; Mask indicating I sent an XOFF
; QMXMTFL EQU 04H ; Mask to allow other end to stop me
; QMSUSP EQU 08H ; Mask indicating I got an XOFF
; QMARROW EQU 10H ; Mask for arrow xlate bit
; QMBIT7 EQU 20H ; Mask for "use only 7 bits"
; QMCCFLS EQU 40H ; Mask for "flush buffer if 2 ^C's seen"
; QM1STCC EQU 80H ; Mask for "first ^C seen"
;
;NOTE: DO NOT poke any bits with CP/M80 (STANDARD DEC DISTRIBUTION) or
; MultiSystem 180 (by Ken Heyda)...poking of random bits would
; be disasterous.
;
;****************************************************************************
--
Digital had it then. Don't you wish you could buy it now!
pechter-at-pechter.dyndns.org