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