21 Apr
2010
21 Apr
'10
3:35 p.m.
Chuck Guzis wrote:
On 21 Apr 2010 at 7:49, allison wrote:
On some it's not there and others not present and that applies
to PRN:, PUN:, RDR:.
On systems I build and play with the BDOS is often a fresh assembly
rather than an old image and the first fix is to make punch and reader
call table handle them as NUL (move data to A and return no error).
That prevents hangs needing reset or a timeout loop in the driver
that takes forever.
By null I meant if you read RDR: or wrote to PUN:
the data would go
to the bit bucket and not to any device.
Exactly so. If you have, for example, an Amstrad Joyce, there's
nowhere to send or receive the data, as there is no (standard) extra
port. There's a printer, but that's a horse of a different color and
not serial at all.
But I've also seem (and been guilty of one or two)
CP/M
implementations that completely ignore implementing IOBYTE, so that
any attempt at redirection using STAT fails. If all you have is a
memory-mapped console display and integrated keyboard and printer,
IOBYTE makes little sense for most applications. I suppose one could
implicitly redirect RDR to the keyboard, again, it makes little
sense.
I've also done that. That means all devices are console
or null.
However I find implement the console portion of IObyte
is handy as that can easily make the console redirectable
at both input and output level. That works well on NS as
there are two SIO and printer(or some parallel thingie.
PIP has a couple of device names that most CP/M
implementations are
meaningless (INP: and OUT:) and many others (e.g. UC1:, CRT:) that
are known only to PIP.
IN and OUT are devices internal to a patch area of pip
and makes it easy to create "pipmodem". The others
the BIOS can work with if IObyte is implmented.
Why do IObyte? Because it makes CP/M IO programatically easy
and sidesteps all of the problems of IO hangs.
Simple file printer:
Get command line
Open file(s) to print
set IObyte console to point to printer device for OUTPUT
transfer file
on EOF reset IObyte to previous setting.
exit.
simple terminal program:
DO
test constat and fetch conin byte if present
flip IO byte
output char to conout
test constat and fetch conin byte if present
flip IO byte and output char to conout
while conin not "CTRL-C"
exit.
The drivers for logical conin, conout and constat can be pointed to the
logical
devices enumerated in the IObyte field bits and an point to one of 4
devices or device combinations, same for Punch, Reader, and LIST
bit fields. This can be controlled from user via STAT. It's easy enough
to create an ASSIGN tool to modify IO byte as well as we are talking
about a single byte at 0003H and maybe in the BIOS if user want it to
remain across boots.
Likely overkill answer but it's often annoying to see CP/M
implementations that
leave out very useful bells and whistles.
Allison
--Chuck