The Heath H-11 was using some boards bought from DEC, though maybe the memory board was from Hrathkit. the real “assembly” worke wad putting the cabinet togethwr, and bolting the boards in place.They weren’t cloning an LSI-11, so DEC had less leverage.
They may have figured it served a different market, so it wouldn’t canibaliize the existing market. Motorola was rumored to do that sort of thing with handie talkies in the early seventies, listed as “defective” or cosmetic defects, they were sold cheaper to the ham market and I maybe required proof of a ham license so they wouldn’t see commercial service. But that’s just rumor, based on there being so many available to hams.
The LSI-11 was considered a potential “home computer” early on. It was sixteen bit, but also people fgured DECUS would be a source of cheap and available software . So a few months after Byte started in the fall of 1975, the Southern Califirnia Computer Society organized a group buy, just some boards, the user needed to supply a case and power supply, and mayne a sevond buy later. It reduced the cost somewhat, but obviously more for people with a profesdional use. Byte ran an article or two about the LSI-11.
There was no universal standard for 5-1/4 disks, but DEC’s decision to create a standard compatible with no others was curious. I once wrote a utility to translate between Cromemco and Morrow disk formats and gave my code to someone who had a Rainbow, he was unable to adapt it to work there.
In 1979, Neil Colvin formed what was then called Phoenix Software Associates after his prior employer, Xitan, went out of business. Neil hired Dave Hirschman, a former Xitan employee. During 1980–1981, they rented office space for the first official Phoenix location at 151 Franklin Street, Boston, Massachusetts.
In this same time period Phoenix purchased a non-exclusive license for Seattle Computer Products 86-DOS. Phoenix developed customized versions of 86-DOS (or sometimes called PDOS for Phoenix DOS) for various microprocessor platforms.
Assumming that the wikipedia is accurate, 86-DOS, and Phoenix’s porting of it to various platforms predated the IBM-PC. If you’re going to draw historical lessons (however broad) from early computer systems, it’s important to be accurate, so that future generations, who won’t have access to the same primary source material, can learn the right lessons.
Sure, but 86-DOS wasn’t MS-DOS, even if MS-DOS was built on it. It is still true that CP/M was the most widely used OS before MS-DOS, and popular systems like the Apple II, Commodore PET, and TRS-80, used their own.
The fact is that there were some almost-compatible PC, like the Olivetti M24. It used an 8086 at 8 MHz and as you could see the video card was integral part of the system, the expansion board was almost XT compatible (notice the extra connector) and had a patented system to detect XT or Olivetti propietary boards. It also had as option to have 720 k 5 1/4 floppies. Another thing: you had to use the Olivetti-supplied MS DOS to achieve compatibility, using generic MS DOS from Micosoft mase some programs stopping to run and some keys on the keyboard not working.
But lest you think that Microsoft’s software contribution was minimal:
Around 1980, Microsoft was the premier supplier of microcomputer language products. First and foremost, that was Microsoft’s BASIC, which IBM decided to build into the ROMs of nearly all of its PC and PS/2 machines built before 1990. IBM also contracted Microsoft to supply an assembler, linker, plus Pascal, FORTRAN, and COBOL compilers.
…
On September 28th, 1980 Microsoft (Bill Gates, Paul Allen, and Microsoft VP Kay Nishi) decided to supply an operating system to IBM as well. The thinking was that the tools they already signed up to deliver would total about 400KB of (binary) code, and an OS would only add at most another 20KB. Microsoft already had Paterson’s QDOS in mind, now sold under the name 86-DOS. Microsoft was also worried that if it took IBM much longer to find a suitable operating system, it would make Microsoft’s job of porting its language products to the PC much harder and perhaps impossible to complete on time.
My memory is a bit hazy, but wasn’t the mid-1980ies (?) benchmark to test whether an “IBM PC compatible” PC really was compatible to try and run MS Flight Simulator on it?
Compatibility difficulty included the unusual use of the x86 assembly DIV command, where a “DIVIDE BY ZERO” command would be issued every time a screen refresh was needed.
That doesn’t make a lot of sense to me, more detail would be interesting.
I don’t know directly. But the 68000 had traps to deal wirh certain code, so if it hit an odd instruction, it would run some user supplied code. An example is floating point instructions, if a math coprocessor was there, the instruction would pass to it. But if not, this would jump to some user software to do floating point in software. My memory is hazy.
If the 8088 had a similar feature, then it could be used to invoke a screen refresh routine. A fast way to invoke the routine. But this is speculation.
Early software was like that. Every CPU had unused opcodes, and they weren’t fully decoded, so they might offer some odd combination of instructions or address modes. People would try to find useful combinations, for curiosiry or to find something useful. It might speed things up, or make software shorter.
The problem was that the CPU might change, and the function no longer there. The manufacturers warned about this.
Doing software tricks is similar. It works fine, except when something changes. And incompatibilty changes things.
maybe this stack exchange answer is close to the truth.
Some 8086/8088 software ends up calling interrupt 0, the divide-by-zero trap, during normal execution, either through programmer error, or intentionally. (Even when this happens through programmer error, there is some level of intent involved since the programmer would have to install a handler to avoid having the program exit.) On the 8086 and 8088, this acted like a “standard” interrupt, with a return address pushed to the stack containing the address of the instruction following the divide instruction. Examples of software which do this include The Seven Cities of Gold’s World Maker and of course Flight Simulator 1.
Thanks for the reminiscences, Cory. I was the designer of one of those ancient early PC clones, and although my (our) implementation used different logic we made certain that it ran cycle-by-cycle identically to IBM’s. Even the tiniest variation was enough to kill your access to the market, because there were popular software products that genuinely depended not only on being as fast as IBM’s, but also not one nanosecond faster as well.
Which, by the way, meant that your reference to using the 8086 is inaccurate. Some of the bigger players did offer 8086-based machines but they din’t do well at all for the reasons above. Flight Simulator, for instance, got unstable. I never did find out why.
