Q: Do any CP/M machines use interrupt driven I/O?
dawa
I am also writing an overview of the architecture of CP/M for a web site and I
would like to know if any CP/M machines use interrupt driven I/O.
As far as I understand it the BDOS does not expect or demand any use of
interrupts. The BDOS assumes that I/O only takes place when it makes a call
to the BIOS and it assumes that when the call returns all the I/O has
finished. The BDOS is free to make a BIOS call at any time.
However, I can picture a scheme where the BIOS does use interrupts to capture
unsolicited input and to buffer output to slow devices. I think this would be
particularly useful with serial devices such as modems, printers, and
real-time clocks.
Are there any real CP/M machines that use interrupts in this or any other way?
Thanks, and again please reply to the newsgroup, that is not a real email
address up the top.
dawa
timo...@cyberramp.net
>Hello again,
>I am also writing an overview of the architecture of CP/M for a web site and I
>would like to know if any CP/M machines use interrupt driven I/O.
>As far as I understand it the BDOS does not expect or demand any use of
>interrupts. The BDOS assumes that I/O only takes place when it makes a call
>to the BIOS and it assumes that when the call returns all the I/O has
>finished. The BDOS is free to make a BIOS call at any time.
>However, I can picture a scheme where the BIOS does use interrupts to capture
>unsolicited input and to buffer output to slow devices. I think this would be
>particularly useful with serial devices such as modems, printers, and
>real-time clocks.
>Are there any real CP/M machines that use interrupts in this or any other way?
Sure. I believe that the Big Board used interrupts fro the keyboard,
and some of the STD bus bds used interrupts. Interrupts are especialy
easy to do when the system used the Z80 family parts.
Tim Olmstead
email : timo...@cyberramp.net
Visit the unofficial CP/M web site.
MAIN SITE AT : http://cdl.uta.edu/cpm
MIRROR AT : http://www.mathcs.emory.edu/~cfs/cpm
Clarence Wilkerson
so an OEM could possibly have written an interrupt free BIOS,
but I doubt it.
So, yes, the serial drivers on most BIOS's used interrupts.
BDOS call 11 allowed one to do a non-blocking check for
an incoming console byte, so were useful.
that was a cutout on the BDOS console
The floppy disk routines almost used interrupts or DMA to
handle double dnesity floppies on 2 or 4 mhz cpus.
Parallel ports might or might not have used interrupts.
--
Clarence Wilkerson \ HomePage: http://www.math.purdue.edu/~wilker
Prof. of Math. \ Internet: wil...@NOspam.math.purdue.edu
Dept. of Mathematics \ Messages: (765) 494-1903, FAX 494-0548
Purdue University, \
W. L. Ind
Greg Holdren
: Hello again,
:
: I am also writing an overview of the architecture of CP/M for a web site and I
: would like to know if any CP/M machines use interrupt driven I/O.
:
: As far as I understand it the BDOS does not expect or demand any use of
: interrupts. The BDOS assumes that I/O only takes place when it makes a call
: to the BIOS and it assumes that when the call returns all the I/O has
: finished. The BDOS is free to make a BIOS call at any time.
:
: However, I can picture a scheme where the BIOS does use interrupts to capture
: unsolicited input and to buffer output to slow devices. I think this would be
The BIOS has the interrupt code and enables the intrrupt at boot up.
ie enables the chip involved. It doesnt matter where the current place the
uP is at, it could be executing user code, BDOS code or BIOS code
when the hardware interrupt occurs. Transfer will go to the inptrrupt
code and to it duty. The uP will then resume where it leftoff before
the interrupt.
: particularly useful with serial devices such as modems, printers, and
: real-time clocks.
:
: Are there any real CP/M machines that use interrupts in this or any other way?
:
: Thanks, and again please reply to the newsgroup, that is not a real email
: address up the top.
:
Almost all CP/M machine use interrupts. The BDOS doesnt know or care.
The interrupt routines are in the BIOS which of corse is machine dependant.
--
Greg Holdren
gr...@wx.rose.hp.com
Edmund Cramp
> I am also writing an overview of the architecture of CP/M for a web site and I
> would like to know if any CP/M machines use interrupt driven I/O.
Yes but it was not common since writing interrupt drive code requires
that the programmer think "multi-user." The majority of the group of
people that I knew at the time were far happier using code than writing
it. Once they had the systems running they tended to avoid re-writing
the BIOS if possible...
> As far as I understand it the BDOS does not expect or demand any use of
> interrupts. The BDOS assumes that I/O only takes place when it makes a call
> to the BIOS and it assumes that when the call returns all the I/O has
> finished. The BDOS is free to make a BIOS call at any time.
Correct - the BDOS makes no assumptions about the existence or otherwise
of any interrupt driven events. The entire thing is polled I/o.
> However, I can picture a scheme where the BIOS does use interrupts to capture
> unsolicited input and to buffer output to slow devices. I think this would be
> particularly useful with serial devices such as modems, printers, and
> real-time clocks.
Correct.
> Are there any real CP/M machines that use interrupts in this or any other way?
Well I wrote a banked IOP for the ZCPR that used interrupts and xon/xoff
handshaking to get a VT100 to work with CP/M. I'm sure that there were
plenty of other people writing interrupt drivers for specific stuff - but
the bulk of the I/o code in CP/M-land was polled.
--
Regards
Edmund Cramp
e...@emgsrus.com
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Radioactive cats have 18 half-lives
Allison
>BDOS call 11 allowed one to do a non-blocking check for
>an incoming console byte, so were useful.
> that was a cutout on the BDOS console
No it was not a NON-blocked check. It was a replacement for the older
calls that would filter control codes like ^S and ^Q .
>The floppy disk routines almost used interrupts or DMA to
>handle double dnesity floppies on 2 or 4 mhz cpus.
Really, name one that could? Most weren't fast enough to process an
interrupt in the required 16us (DD 8"). There were a few that used
interrupt signal to escape from a halt state but the opcode inserted
was either a NOP or EI.
>Parallel ports might or might not have used interrupts.
Some did, some didn't. generally there was no requirement to do so.
Allison
Real address is: Allisonp @ world DOT std DOT com
++++BULK Email severely not wanted+++
Allison
>would like to know if any CP/M machines use interrupt driven I/O.
Many did and many didn't. It was a design feature that early on was
not well understood and not implemented. Later machines would
capitalize on it.
>As far as I understand it the BDOS does not expect or demand any use of
>interrupts. The BDOS assumes that I/O only takes place when it makes a call
>to the BIOS and it assumes that when the call returns all the I/O has
>finished. The BDOS is free to make a BIOS call at any time.
Correct but an interrupt can occur at any time. It's the interrupt
service routines responseability to preserve the current context
and restor it on exit.
>However, I can picture a scheme where the BIOS does use interrupts to capture
>unsolicited input and to buffer output to slow devices. I think this would be
>particularly useful with serial devices such as modems, printers, and
>real-time clocks.
Widely done.
>Are there any real CP/M machines that use interrupts in this or any other way?
Non exhaustive list:
DEC vt180
Kaypros
VISUAL 1050
Epson PX-8
AmproLB
SB180
and many more...
Allison
>ie enables the chip involved. It doesnt matter where the current place the
>uP is at, it could be executing user code, BDOS code or BIOS code
>when the hardware interrupt occurs. Transfer will go to the inptrrupt
>code and to it duty. The uP will then resume where it leftoff before
>the interrupt.
Some do. Not all.
>Almost all CP/M machine use interrupts. The BDOS doesnt know or care.
>The interrupt routines are in the BIOS which of corse is machine dependant.
many didn't, Namely LIFEBOAT for NS* horizon, CCS2200, Netronics
Explorer8085 and a slew of others.
Interrupts were a later addition not to cp/m itself but to the systems
many of which were capable however, lacked programming.
Allison
>that the programmer think "multi-user." The majority of the group of
>people that I knew at the time were far happier using code than writing
>it. Once they had the systems running they tended to avoid re-writing
>the BIOS if possible...
there is some truth there until people started writing articles on how
to do it and demystified it with simple examples. Truth was most
people wanted to be able to type without losing characters due to the
disk IO or other things like printing.
>Well I wrote a banked IOP for the ZCPR that used interrupts and xon/xoff
>handshaking to get a VT100 to work with CP/M. I'm sure that there were
>plenty of other people writing interrupt drivers for specific stuff - but
>the bulk of the I/o code in CP/M-land was polled.
I did it as well without resorting to a ZCPR IOP as it was a simple
flow control addition to the BIOS CONOUT, CONST and CONIN.
If they were interrupt driven it was far easier to do.
the key event was around 1980(not a date more like a time frame) when
system started showing up that tried to satisfy the demand from some
users for more performance and some of the basic features seen on
minicomputers. One step toward this was the use of interrupts and
DMA. This freed the CPU to tackle background tasks such as keyboard
type ahead, printer spooling and modem programs that could display to
the terminal and take data seemingly concurrently.
timo...@cyberramp.net
>Non exhaustive list:
>DEC vt180
>Kaypros
>VISUAL 1050
>Epson PX-8
>AmproLB
>SB180
My LOBO MAX-80 does too. A real nice machine.
Clarence Wilkerson
I realize this is tough or impossible for 8". However,
I believe that Gil Schultz at
Detroit Motorola once showed me an S100 with a 765 board he had
designed when he was working for NEC that
would manage it.
--
Clarence Wilkerson \ HomePage: http://www.math.purdue.edu/~wilker
Prof. of Math. \ Internet: wil...@NOspam.math.purdue.edu
Dept. of Mathematics \ Messages: (765) 494-1903, FAX 494-0548
Purdue University, \
W. Lafayette, IN 47907-1395 \
Allison
>The H89 did 5.25" DD at 2 mhz.
You have 32uS for DD 5.25! I believe it used processor stall and the
H89 I had ran at 4mhz.
> I realize this is tough or impossible for 8". However,
>I believe that Gil Schultz at Detroit Motorola once showed me an S100
>with a 765 board he had designed when he was working for NEC that
>would manage it.
I worked with Gil and have one of those and it uses processor stall.
By not using interrupts and not running a loop to test for data ready
you can run a slower processor as the read or write loop is real tight
even on 8080. FYI: it was memory mapped to gain speed as well.
The DEC vt180 uses z80 at 4mhz with Dram as do the AMPROLB and
they do a test bit loop and take advantage of Z80 instruction set
(INI).
Alex Plantema
>I would like to know if any CP/M machines use interrupt driven I/O.
I have a Bondwell 14, which does not use interrupts at all, and it is almost
impossible to use them with its weird combination of chips.
My other machine is an MSC-ICO. It uses the nonmaskable interrupt for disk
I/O, and interrupt mode 2 for character I/O: keyboard input, serial I/O, and
printer output. I added a periodic interrupt to implement the media byte.
The banked CP/M 3 BDOS has an undocumented feature for interrupt driven
keyboard I/O. When it calls the BIOS keyboard status routine to check for ^S
or ^C during console output, it sets bit 6 or 7 of a byte in the system
control block. Then the BIOS knows that the last, not the first, character
in the keyboard buffer should be tested, and returns true only if the
corresponding character is found. The BIOS keyboard input routine, when
called with one of these bits set, should return the last character and
empty the buffer.
With this scheme, it is possible to stop and abort console output, even
after typing ahead. Even in a DOS-box in Windows 98 this is impossible!
Peter Heitzer
> wil...@math.purdue.edu (Clarence Wilkerson) wrote:
>
> >The H89 did 5.25" DD at 2 mhz.
>
> You have 32uS for DD 5.25! I believe it used processor stall and the
> H89 I had ran at 4mhz.
than the normal interrupt.
LOOP:
HALT ; 16 T
LD A,B ; 4 T
OR A ; 4 T
JR NZ,LOOP ; 12/7 T
; NMI isr
L_066:
INI ; 16 T for writing an OTI instruction must be used
RETN ; 14 T
This makes 83 T states (assuming NMI takes 17 T as call does)
At 2MHz this is more than 32 uS but at 4 Mhz this should be no problem.
Using the -WAIT pin of the Z80 would be the more elegant way. Then
a simple OTIR or INIR would do the job!
--
Dipl.-Inform. Peter Heitzer, phone +49 941 943 4850, fax +49 941 943 4857
Allison
>LOOP:
> HALT ; 16 T (4t, corrected)
> LD A,B ; 4 T
> OR A ; 4 T
> JR NZ,LOOP ; 12/7 T
>; NMI isr ; 11 t
>L_066: INI ; 16 T for writing an OTI instruction must be used
> RETN ; 14 T
>This makes 83 T states (assuming NMI takes 17 T as call does)
NMI requires 11t states as do all the RSTn. halt is 4 Tstates.
That takes the loop down to 65t
The waste in that loop is NMI (internal RST)
and the RETN as those eat 27t.
>At 2MHz this is more than 32 uS but at 4 Mhz this should be no problem.
At 2mhz it's 32.5uS and at 4mhz it's 16.25us. if there memory or IO
wait states this gets really nasty.
That loop looks fast but...
>LOOP: IN statport ;data requrest is in bit 0 (11t)
RRC ; ; (4t)
JP NC,LOOP ; (7/10t)
INI ; (16t)
DEC D ; (4)
JP NZ ,LOOP ; 10/7 T
This loop run in 77t if the top loop misses the first pass and 52 if
it's a hit the first pass.
It will support DD 5.25, if the cpu is 2.5mhz or faster. to support
DD 8" or 1.44mb 3.5 floppy worst case is 13 us and you either need to
be around 5mhz or greater cpu clock or resort to hardware tricks(or
DMA). One must be able to handle the worst case timings and that can
be 27(13) uS and that means the loop must have a bit more speed.
Those cases mean the CPU at 4mhz must execute the whole loop in
108(52) t states or it fails. Interrupts work but they really rely on
processor speed as there are a large number of memory operations.
Both software cases given cannot service interrutps during a sector
transfer as ther eis not enough CPU to do it (unless it's a 8mhz z80).
What I feel is a handicap is that the cpu is spinning in a tight loop
and cannot do anything else. CP/M is percieved as slow when most of
the time it's waiting on disk IO. In reality if the IO can be defered
or done as DMA cycles the apparent performance is generally
significantly higher and taking interupts for keyboards and modems
are a far easier.
Also loc 66h is a reserved location in CP/M that must be saved before
every disk operaton and restored after. It's by the default FCB used
by the CCP.
>Using the -WAIT pin of the Z80 would be the more elegant way. Then
>a simple OTIR or INIR would do the job!
If the CPU is refreshing dram... crash.
timo...@cyberramp.net
>If the CPU is refreshing dram... crash.
Not if the dram ckt is very carefuly designed. My old CP/M system was
an 8 mhz Z80 w/128K of dram. I used the wait state trick, and it
worked well. You have to have a dram refresh ckt that keeps refresh
going while you're being held in wait. It can be done, and is much
cleaner than other solutions for a Z80 CPU.
Tom Kirk
> If the CPU is refreshing dram... crash.
>
> Allison
>
Back in the good 'ol days, I worked for TDL. We had a disk controller board
that ran double density. The driver used INIR and OUTIR instructions. If
you look at the Z80 hardware manual, you will find that the xxIR
instructions stall the program counter until the count goes to zero. This
has the effect of re-reading the OP code for each cycle. This is done so
that the M1 cycle can refresh dynamic memory. Also if you were going to
read 512 byte sectors, you just stacked INIR or OUTIR instructions on top of
each other.
Frank Zsitvay
> an 8 mhz Z80 w/128K of dram. I used the wait state trick, and it
> worked well. You have to have a dram refresh ckt that keeps refresh
> going while you're being held in wait.
Sounds like in that case the CPU isn't refreshing dram...
-Frank
timo...@cyberramp.net
>Back in the good 'ol days, I worked for TDL. We had a disk controller board
>that ran double density. The driver used INIR and OUTIR instructions. If
>you look at the Z80 hardware manual, you will find that the xxIR
>instructions stall the program counter until the count goes to zero. This
>has the effect of re-reading the OP code for each cycle. This is done so
>that the M1 cycle can refresh dynamic memory. Also if you were going to
>read 512 byte sectors, you just stacked INIR or OUTIR instructions on top of
>each other.
Yes, but.... If you're using wait states for synchronization with the
FDC, then the DRAM controller h/w must take over the refresh as the
Z80 cpu is stalled and can't be doing the refreshes.
Allison
>>that ran double density. The driver used INIR and OUTIR instructions. If
>>you look at the Z80 hardware manual, you will find that the xxIR
>>instructions stall the program counter until the count goes to zero. This
>>has the effect of re-reading the OP code for each cycle. This is done so
>>that the M1 cycle can refresh dynamic memory. Also if you were going to
>>read 512 byte sectors, you just stacked INIR or OUTIR instructions on top of
>>each other.
On systems like the TRS80 where the cpu was responsible for the Dram
refresh stalling the CPU in that case would crash the system
everytime. Part of the problems is you enter the loop and wait, if
the disk door is open or you need to wait for a full revolution to get
the deisired sector it's far to long.
In the S100 world most Dram cards were self refreshing so the CPu
stall was not an issue. there were some cards like the Vector 48k
Dram that were z80 cpu dependant for refresh and would crash in
ALTAIR/IMSAI front pannel machine and those that used stall for disk
IO.
john r pierce
>
>
>>Back in the good 'ol days, I worked for TDL. We had a disk controller board
>>that ran double density. The driver used INIR and OUTIR instructions. If
>>you look at the Z80 hardware manual, you will find that the xxIR
>>instructions stall the program counter until the count goes to zero. This
>>has the effect of re-reading the OP code for each cycle. This is done so
>>that the M1 cycle can refresh dynamic memory. Also if you were going to
>>read 512 byte sectors, you just stacked INIR or OUTIR instructions on top of
>>each other.
>
>Yes, but.... If you're using wait states for synchronization with the
>FDC, then the DRAM controller h/w must take over the refresh as the
>Z80 cpu is stalled and can't be doing the refreshes.
ah, as I remember, the 'trick' to avoiding the nasty really long block on reads
was to poll til the FIRST byte transfers, or, do ReadID's til you get the sector
in front of the one you want, THEN fall into the WAIT blocked transfer loop.
This way you will only stall the CPU for a few microseconds at a time instead of
potentially a full turn of the 360RPM floppy. (thats around 16mS, WAY longer
than a full refresh cycle!).
-jrp
----------------------------------------------------------------------
This posting has a invalid email address to discourage bulk emailers
Due to the ever increasing volumes of spam, I do not mix mail and news
----------------------------------------------------------------------
bill_h (Tucson)
quoted a message without leaving who wrote it attached:
> >Back in the good 'ol days, I worked for TDL. We had a disk controller board
> >that ran double density. The driver used INIR and OUTIR instructions. If
> >you look at the Z80 hardware manual, you will find that the xxIR
> >instructions stall the program counter until the count goes to zero. This
> >has the effect of re-reading the OP code for each cycle. This is done so
> >that the M1 cycle can refresh dynamic memory. Also if you were going to
> >read 512 byte sectors, you just stacked INIR or OUTIR instructions on top of
> >each other.
And my news server is acting flakey again. I didn't get to see the
original.
Who was it?
john r pierce
>timo...@cyberramp.net
> quoted a message without leaving who wrote it attached:
>
>> >Back in the good 'ol days, I worked for TDL. We had a disk controller board
...
>
>And my news server is acting flakey again. I didn't get to see the
>original.
>
>Who was it?
>
Tom Kirk, tom...@compuserve.com was the "From" on the original.