"CP/M compatible" vs. "MS-DOS Compatible" machines?

[Chuck Guzis]

> 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 
later exploitation.

Cheers,
Chuck