Dec Rainbow prehistory

Wasn't sure anyone wanted to hear rantings. I'm not sure how much I can recollect. It was a painful port. At that time (1981-ish) I was doing MSDOS ports to all sorts of soon-to-be-killed-deader-than-dead MSDOS machines (the steamroller that was IBM as well as the foolishness of some of the ventures). I believe we (Phoenix Software later Phoenix Technologies) were the sole subcontractor for Microsoft, installing MSDOS on various boxen. Typically I'd get raw iron with an empty EPROM socket, and a scribble of I/O port assignments and I'd hack in my canned 8086 debugger, get the console to work, then get the floppy to work, etc. I had a standardized BIOS (IO.SYS) implementation -- the table driven part of MSDOS 1.x and 2.x that DOS called to read console, disk, etc. A device-independent part that did all the block to track:sector:head mappings and deblocking, DMA buffer crap, canonical clocks etc. There were only two floppy chips (WD and NEC), very few DMA controllers, Remex HDs etc those days, so I always had code to reuse, only had to write dumb low-level device drivers, the device-independent part did all the error checking and such. Once the EPROM debugger was up I could do a whole MSDOS install (dma, interrupt serial devices, floppy and hard disk formatters, in 3 - 5 days tops. The Rainbow was in this sort of realm, except DEC and M'soft had some legal battle, something like M'soft suing DEC over not providing it the data needed to port MSDOS to it. That sounds wrong to me now, but there was some legal hassle. Eventually it was 'permitted', and I had to go to DEC (I lived in Mass. at the time) to meet'n'greet. They basically refised to divulge things like IO port assingments and the operation of the thing I called the MHFU (Massive Hardware F**kup Unit, or something) that rebooted (CPM-86!) if you turned interupts off for more than a few tens of milliseconds. Bureaucracy in firmware. I forget, but the DEC Rainbow took months to make go right. I did MSDOS 1.25 or something, someone else, possibly DEC-internal, did MSDOS 2.2. (As an odd aside, one of the DEC bigwigs, I cannot recall his name, who was in on the nonsense, later got interested in Fido/FidoNet on the Rainbow, maybe Dave Mitton can recall his name... I think he was trying to see how it would be good for DEC, or something.) So I arrived with Neil Colvin and David and we get sent to this big meeting room. We were made to wait an obvious interval. Two DEC lackeys came in the room, left, close the door. A few minutes later, two different lackeys, then an engineer, and a bigwig or two, like some Sopranos episode. I forget the details of the meeting, but my peer nerds were of course fine. Basically I got shown some listings and port EQU's and such. I think they were embarrassed by the 100A's architecture: Some BOZO designer had, I assume arrogantly, put all the video interrupts (vert, horiz retrace, etc) starting at 00020h, which everyone knows is where MSDOS has it's software interrupts. They were in a PAL or something, and could not be moved. So the Rainbow is really a Z80-based CPM machine, with a "slave" 8088 in a bag on the side. THey have shared memory, maybe a bit more. There was some communications mechnism between them that was reasonably fast, but the 8086 could not read the floppy, for isntance. I could be way off on the details here. So MSDOS diskettes were really z80-side drivers that performed services for the MSDOS side (one side effect was a small 8088 I/O system and some I/O overlap). Booting was difficult due to the MHFU; I *had* to turn interrupts off for some short period, or it might have been the MSDOS.SYS code, over which I had no control, turned interrupts off. There was a watchdog timer reset by some ROMed routine that killed the boot process. I can't recall his name, but there was a very helpful software person at DEC that was quite helpful. From him I offically got *barely* enough data to disable the MHFU. This was a Big Deal. Everything was like pulling teeth with DEC. If I recall, even Msoft considered a patched MSDOS.SYS that did something to ameliorate the MHFU unit. INT 21h was the worst. It was the vertical retrace interrupt, I think, not many times a second (60) but it's of cuorse the MSDOS system call interrupt. I had to do a bunch of actual analysis and statistical crap to work out a solution, whichw as basically (don't quote me): interrupt_service_routine for 0021h: if (flag set) { # ends up here ONLY push psw; # on re-interrupted ISR longjump saved_vector; } saved_vector= stack[-2]; set flag; enable interrupts; # this is the nop; # heart of the test disable interrupts; # clear flag; enable interrupts; simulate MSDOS 0021h iret; Basically, this code was installed at boot time, and handed CPU interrupt 21h. Its job was to determine if the interrupt just received was a MSDOS system call, or a hardware vertical retrace. You can tell the difference because a HARDWARE interrupt remains asserted until cleared in the interrutp controller; the set flag/reenable interrupts allowed the ISR to be interrupted. (I ended up with a clever (monkeys are "clever") method of executing software interrupts that avoided the un-believeably slow INT/IRET pair, explicitly pushing/popping flags that makes no sense but was faster. I used it in the old FOSSIL drivers later.) There is of course a two-instruction window for a hardware interrupt to occur when servicing a software interrupt. The ratio is something like 60Hz vs. the two instruction execution times, so the 100A was guarenteed to crash every few dozens or hundreds of hours (I forget, and lost all the documentation). Basically the machine sucked. The floppies were stupid ("A" drive, the floppy went in one way, "B" the floppy had to be turned over). THe 100B was the same, I think, EXCEPT there was a way to programmatically move the display interrupts from 002xh to something else that didn't interfere with MSDOS.