Dec Rainbow prehistory

From: Tom Jennings <tomj_at_wps.com>
Date: Mon Nov 17 18:53:11 2003

> Did you mean "could" if there weren't legal obstacles, or were you
> just waiting for us to ask?
>
> If the latter, please do.

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.
Received on Mon Nov 17 2003 - 18:53:11 GMT