"CP/M compatible" vs. "MS-DOS Compatible" machines?
cclist at sydex.com
Tue Feb 5 03:08:19 CST 2008
> Date: Tue, 05 Feb 2008 02:20:29 -0500
> From: "Roy J. Tellason"
> > I'd already done it for DX-85M
> What's that?
Proprietary multitasking operating system, based on the 8085;
basically the other end of the spectrum from CP/M. Included built-in-
interrupt-driven I/O (including 4 channels of async), file types
(i.e. differentiated between executable, data, index, etc.), built-in
ISAM files and a bunch of other stuff. One of these days I'll chat
about it if anyone's curious.
Sometimes interrupt-driven I/O wasn't very good. We used an Intel
8275 CRTC in the CPU and some enterprising engineer decided to
hardwire it to DMA channel 1, not 0. On the 8257 DMAC that meant
that we couldn't use auto-initialize to keep the display going and
basically had to re-initialize the DMA transfer between screens,
using an end-of-screen interrupt. Servicing that interrupt 60 times
per second was a big drag on the CPU--and if you missed it, the
screen would flicker.
Re: passing arguments on the stack. It's an interesting exercise on
the 8085 using the "undocumented" instructions. For example, opcode
38H, which is a two-byte instruction would take SP, add the second
instruction byte and stick the result in DE. Opcode 28H would do the
same, but use HL instead of SP.
Another 8085 16-bit operation, opcode D9H, would store HL in the
address pointed to by DE. Opcode EDh would load HL from the address
pointed to by DE.
There were a couple of other 16-bit operations in 8085 not
documented. 08H would subtract BC from HL, 10H shifted HL right one
place with sign extension. 18H rotated DE left one place through the
carry flag (i.e. 17 bit rotate).
There were a few other instructions of less interest: a couple of
jumps that tested for unsigned overflow and a conditional restart to
location 40H (RST 8) if the overflow flag was set.
With the exception of the double-precision subtract, none of these
instructions have close analogues in the Z80 instruction set. Nor,
AFAIK, did any commercial products exploit them.
It was kind of unfortunate that Intel simply didn't leave blanks in
the 8080 documentation for the "do nothing" moves; (e.g. MOV A,A; MOV
B,B, etc.). It might have freed up a few more spare opcodes for
More information about the cctalk