31 Jan
2008
31 Jan
'08
12:53 a.m.
Allison schrieb:
Termcap was very needed, but not present. Net result was that almost any
software that required terminal control beyond backspace and CRLF had to
be tweaked manually. I remember having written code to fit in the
Wordstar patch area to adapt to some obscure or not so obscure terminal
dozens of times. Termcap and terminfo under the various Unixes of the
time was god-sent then even if some entries were plainly buggy - maybe
just estimated from some hear-say information.
The print string BDOS function was indeed an example that was almost
immediately replaced by do-it-yourself routines, often by using the '\0'
delimiter (which then caused trouble with slow terminals that require
some delaying NUL bytes after a CRLF).
The great
thing about CP/M (and I'm talking about the 8-bit version
here) was that it imposed a file system and made disk I/O uniform--
128 byte sectors, regardless of how the information was actually
formatted onto a drive. CP/M was really primitive when it came to
console I/O, giving only about 3 functions for output and input each.
No cursor positioning or screen control; basic TTY style I/O. And,
while there was an IOBYTE facility to redirect I/O, implementation
was very nonuniform between vendors.
Things like Termcap and the lise were not needed. However the console
IO was not so good. Try printing a string containing $ using the print
string call. The other was passing 8bit data when needed.
IObyte was mostly uniform, the problem was often it
wasnt even
implemented. This was a problem of allowing the BIOS spec to be
minimal and it usually was.
IO byte, besides as you correctly remarked not being implemented at all,
was outdated soon after CP/M was released for the Altair. I haven't seen
many paper tape readers and punches connected to CP/M systems for
serious business work. IObyte did not take care of additional devices
beyond the 4 standard devices; it did not deal well with additional
serial or parallel ports for more terminals and printers. This resulted
in unofficial BIOS extensions to get such available hardware into the
boat, and again unportable programs to swap vectors in to BIOS to write
output to a second printer, for instance. Needless to say that
"well-written" software to use the IOByte failed to use these additional
devices - there was even software that insisted that PTP is dumb and AUX
is intelligent, so abusing these pseudo devices for two printers
resulted in different behaviour.
Ignorant, I think no, they gave the hooks and basic
requirements. It
was up to the BIOS developer to do a good job or just enough. I've
repeatedly posted that if anything CP/M prevents little and you can
do a great deal at the bios level to really deliver a better system.
The best way to illustrate this is try a system with basic IO and one
with a full interrupt drive IO. The first thing you notice is the
ability to type ahead and the system feels more responsive.
Since the BIOS reduced the available space for BDOS and TPA - which
admittedly improved with CP/M+, which, however, IMHO came too late -
many vendors came up with a not so elaborate BIOS but rather tweaked the
sample code from DRI. It was plainly easier to add some custom program
to directly hack the non standard hardware than extend the BIOS with
useful, clever and portable features. What has been the GHz mania of the
processor later was at that time the "xxK TPA available" selling argument.
> Likewise, it wasn't MS-DOS that was the great
advance for the IBM PC
> platform, but rather the well-documented BIOS and I/O interfaces.
> Heck, PC-DOS 1.0 wasn't that different from CP/M-86--you still had to
> do your disk I/O through FCBs, just like CP/M. I believe, to this
> day, you can still issue your DOS calls by loading (CL) with the
> request number and calling TPA:0005.
>
CP/M-86 and MS DOS were initially designed to allow a simple 8080->8086
cross translator to run the whole set of already existing CP/M
applications without reinventing the wheel. Later DOS versions added
Xenix compatible calls (equivalents of Unix raw I/O: open, close, read,
write, lseek, unlink) but often still the well-understood FCB crap was
used. The call to TPA:0005 is still present in contemporary MS-DOS
versions, as well as INT21h calls;
however today the "DOS box" under Windows just prepares the environment
for such old DOS programs and uses virtualization to fake an existing
DOS. You can't trace an INT21h call any longer into an MSDOS.SYS or IO.SYS.
--
Holger