ORD-GROUP Newsletter, 1990/08
This document was the first and last newsletter ever produced
by the ORD-GROUP. It has been generated from the
original WordStar document NEWS9008.DOC.
By this time we had replaced the original spelling of
ORD-GROUP and ORDINATOR by the initial-caps, hyphenless
variants Ordgroup and Ordinator.
Ordgroup Newsletter August 1990
This is the first Ordgroup Newsletter. It's purpose is to keep
the users of Ordgroup systems (in particular the Ordinator)
informed about enhancements to and new features of those systems.
Since many people don't quite understand the intricacies of
Timesharing, this is also valuable material to cover.
In this newsletter:
* A more robust clock and timer subsystem for TS
* Standard CP/M 2.2 IOBYTE has been implemented
* A clarification of some of the syntaxes of SET
* Proposal for a character I/O speedup
I hope everybody will enjoy reading this. I hope to make new
newsletters every so often, when they are needed. If you want to
write something, you're welcome !
Luc Rooijakkers
-----------------------------------------------------------------
A more robust clock and timer subsystem for TS
A certain bad day, Maurits complained to Luc that Timesharing
disk I/O crashed. After some questioning, it became clear that
the problem was with the timer hardware of the Ordinator. You
see, TS bases a lot of it's internal housekeeping on the timer
interrupts that are supposed to occur 10 times every second. The
separate real-time clock, which gives an interrupt once a second,
was only used to keep the time. When the timer ceased to give
interrupts, the disk I/O did not work any more. And so did more
of TS. Since there had been some problems with the timer before,
I decided to implement redundant timing capabilities for TS, so
that it could continue to work if one of the clocks malfunctioned
or was absent.
In principle this was easy to implement. It sufficed to check on
every interrupt from any clock wether the other had recently
generated any interrupts. If not, TS concludes that the other one
is missing, and starts to simulate it. Also, it keeps resetting
and testing the hardware. This allows you to plug in the hardware
if it was missing, or recovers automatically in case of a
hardware glitch.
While I was working on it, I also implemented some additional
things you can SET. Previously it was not possible to set the
date, time or day, since this was supposed to come from the clock
chip always. Now, it is again possible to do SET DATE=dd/mm/yy or
SET TIME=hh:mm:ss or SET DAY=day. Before we got the clock chip on
the Ordinator, you could also set the time, but this had long
since been disabled. Of course, you need only SET these if they
are not coming from the clock chip every second. If they are, you
should change the values in the clock chip directly using SETUP.
But if TS is started without clock chip, you might need these
commands.
The new checks produce messages like
16:12:15 Timer stopped
16:12:15 Timer restarted
if something unexpected happens. Indeed, I have seen these
messages once, since the extra checks were implemented. During
testing, it was indeed possible to remove the clock or timer card
and re-insert it, and everything worked fine (if the system
didn't crash during the act of removing or re-inserting the
card).
While testing this, I also enhanced PS a little. The PS -T
command (show system timing) now displays more timing information.
These improvements appear in TS version 23/06/90 or newer.
Luc Rooijakkers
-----------------------------------------------------------------
IOBYTE finally implemented for Timesharing
People have often wondered why Ordinator Timesharing did not
support the standard CP/M IOBYTE scheme for re-directing
character input/output. The answers are that I was lazy, and it
did not seem easy to do. However, it has now been done, in a
restricted manner (mostly so we could run standard CP/M Kermit),
and took no more than a day to implement.
First, a short explanation. What is the CP/M IOBYTE ? Character
I/O in CP/M is usually done with one of four "logical" devices
called the console (CON:), the reader (RDR:), the punch (PUN:) or
the list device (LST:). In low memory there is a byte called the
IOBYTE which can optionally be used to redirect those logical
devices to physical ones. In particular, the standard "physical"
devices for CP/M 2.2 are
CRT: - Cathode Ray Tube, usually a video display
TTY: - Teletype
BAT: - Batch (input from RDR:, output to LST:)
PTR: - Paper Tape Reader
PTP: - Paper Tape Punch
LPT: - Line Printer
UC1: - User defined console 1
UR1: - User defined reader 1
UR2: - User defined reader 2
UP1: - User defined punch 1
UP2: - User defined punch 2
UL1: - User defined list device 1
Not all of the logical devices can be redirected to all of the
physical devices. In particular, the allowed combinations are
CON: to one of CRT:, TTY:, BAT:, UC1:
RDR: to one of PTR:, TTY:, UR1:, UR2:
PUN: to one of PTP:, TTY:, UP1:, UP2:
LST: to one of LPT:, TTY:, CRT:, UL1:
These can be set via BDOS calls number 7 and 8 (Get IOBYTE and
Set IOBYTE), directly in low memory or via the STAT command with
something like
STAT CON:=CRT:
Additionally, STAT DEV: lists the current redirections, while
STAT VAL: lists the possible redirections.
The PIP command allows both logical and physical devices as input
or output, and also some pseudo-devices like NUL: and PRN:.
All of the Ordgroup single-user systems implement the IOBYTE, but
until quite recently Timesharing did not. It did allow
redirection of the logical devices, but this was done outside
CP/M with the SET command (or the Sset system call), with
commands like
SET LST:=PRINTER
Of the possible physical devices only six have been implemented.
In particular, these are the CRT:, PTR:, PTP:, LPT:, TTY: and
BAT: devices. With SET you can now assign Timesharing devices to
the first five of them with commands like
SET LPT:=PRINTER
or
SET TTY:=SERIAL1
but not to BAT:, since this device always takes its input from
the current RDR: device and always sends its output to the
current LST: device.
In addition, at every reboot TS ensures that the CON: device is
redirected to either the CRT: or the BAT: device. If necessary,
it will redirect it to the CRT: device.
However, this implementation creates a backward compatibility
problem, since there are some programs (and lots of users) who
previously used the logical device names CON:, RDR:, PUN: and
LST: in SET commands or Sset system calls. To keep these working,
the default IOBYTE has been set to
CON: is CRT:
RDR: is PTR:
PUN: is PTP:
LST: is LPT:
and TS accepts the logical device names as synonyms for these
physical devices. However, these synonyms are hard-wired and do
NOT depend on the current IOBYTE. That is, a command like
SET CON:=VIDEO1
is EXACTLY the same as
SET CRT:=VIDEO1
and in fact the second form is to be preferred. Note that
commands
SET CON:=CRT:
and
STAT CON:=CRT:
look similar, but are completely different. The first one is
equivalent to
SET CRT:=CRT:
and hence does nothing. The second one redirects the logical CON:
device to the physical CRT: device, at the IOBYTE level.
The advantage of the new implementation is that there is now a
spare physical device (TTY:) for programs such as Kermit and
PSEND, which can permanently be assigned by the user and need not
be mentioned to the programs at each invocation. In order to
learn the new names to the users, SET has been changed to give a
warning if any of the logical device names is used in its
argument. By its very nature, SET works below the CP/M IOBYTE
level and hence deals only with physical devices.
In addition to SET, also STTY and PS have been enhanced. STTY now
allows a device name of TTY: and does not require super user
permission in this case. PS has been changed to display the CRT:
device instead of the CON: device.
Commands like PSEND and VTERM still have to be changed. One
problem common to VTERM and KERMIT is that they consume a lot of
processor time. Maybe this will change in the near future. See
the separate item on character I/O speedup.
You can now use CP/M Kermit by first redirecting the TTY: device
to a serial channel, setting its baudrate with STTY and then
invoking Kermit. Then use the Kermit command SET PORT TTY to
select the TTY device, and you are done.
The IOBYTE appears in TS version 13/07/90 or newer.
Luc Rooijakkers
-----------------------------------------------------------------
A clarification of SET
While explaining the new IOBYTE implementation to people, they
seemed to have difficulties to understand the role of physical
device names to the right of the equals sign in SET commands, in
commands like
SET LPT:=CRT:
but also
SET A:=D:
This is however very simple. On the left of the equal sign, only
physical devices are allowed (CRT:,PTR:,PTP:,LPT:,TTY: but also
A:,B:,C:,D:). On the right, volume names like VIDEO0 or TS_SYS
are allowed, but also physical devices. In the latter case, the
physical devices stand for the volumes they are currently
assigned to. So instead of typing
SET A:=MY_DISK,B:=MY_DISK,C:=MY_DISK
you can also use
SET A:=MY_DISK,B:=A:,C:=A:
and the same holds for character devices. Ie, instead of
SET CRT:=SERIAL1,LPT:=SERIAL1
you can use
SET CRT:=SERIAL1,LPT:=CRT:
With the backward compatibilty of the IOBYTE implementation, you
can even type
SET LST:=CRT:
but this is totally different from
STAT LST:=CRT:
although the effects are similar. The first command will set the
LPT: device to the volume currently assigned to the CRT: device
(your console). The second one will redirect the logical LST:
device to the physical CRT: device through the IOBYTE.
To make things more difficult, you can even use
SET B:=C: W/E
combining the assignment of the volume to B: with the assignment
of write enable to B: (not C:).
By the way, you have noticed that you can use several assignments
in one SET command ? This seems to be something a lot of people
don't know. Maybe we should write a Timesharing Users Manual...
Luc Rooijakkers
-----------------------------------------------------------------
Speeding up Timesharing character I/O
Recently, Geert-Jan came with an idea to speed up character I/O
under TS. Basically, his idea was to do less context-switches
(costing about a millisecond of time each) by keeping characters
output in a buffer, flushed on every context switch (of which
there are at least 10 every second anyway, due to the timer
interrupts). Then I also saw some other possibility to speed up a
lot of programs doing direct console I/O. There has always been a
problem with BDOS call 6, Direct Console I/O, when used for
input. The problem is that a program using this call consumes a
lot of processor time busy-waiting for keystrokes. For most
programs this can be fixed by doing direct BIOS calls, but this
is not really a nice solution. Also, for programs like KERMIT or
VTERM that really want to monitor two devices for input at the
same time, there has never been a solution. I do now know one,
but am not sure everyone will like it. Therefore I present it
here, inviting comments.
The idea is that TS will decide, after having gotten a certain
number of console status BIOS calls within a certain time, that
a program is indeed busy-waiting for input and will thus not need
to run again until some input arrives. The only disadvantage I
know of is that there might be programs which do some timing
during their input loops, and they would lose the CPU causing the
timeout to be postponed forever. In particular, this is the case
with KERMIT, but there manual recovery is possible by simply
pressing Return. But Wordstar and Mince might also do this. Does
anyone have any ideas on this ? Of couse, the parameters would be
set so that the detection would only be triggered if a program
has really done very little except calling console status for a
certain time (minimal 0.1 second for technical reasons, but this
might be more. However, setting it higher loses some of the
advantages). Thus, a program checking the keyboard now and then
or intermixed with output would not have any problem.
Luc Rooijakkers