Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!wuarchive!decwrl!waikato.ac.nz!comp.vuw.ac.nz!actrix!ping!ping From: ping@ping.actrix.gen.nz (Peter Ingham) Newsgroups: comp.sys.amiga.advocacy Subject: Re: 8-bit death Message-ID: <170.tnews@ping.actrix.gen.nz> Date: 4 May 91 14:47:20 GMT Organization: Who needs organizations? I'm a person!! Lines: 93 Quoted from <...unknown> by daveh@cbmvax.commodore.com (Dave Haynie): > Scars acquired over years of working "in the business" are a reasonable > assurance. Providing the scars have induced knowledge and insight, rather than being the result of repeated incompetence!!!! > > >>As far as the programming model (the only one that counts) is concerned, > >>the 8088 is an 8-bit processor with 4 bank-select registers built in. > > >In _every_ respect, the 8088/8086 is a _16_ bit CPU. > > No, the 8088 is, of course, an 8 bit CPU from the hardware viewpoint. Every 8088 is only 8-bit from the EXTERNAL hardware veiwpoint. As is the 68008. > >I'm sure that in the late 1970's this seemed to be the reasonable thing to > >do, however hindsight shows it in a different light. > > It was obviously not reasonable to anyone but Intel. They felt it was > reasonable because it made the 8086/8 assembly code very similar to 8080/5 > assembly code. > From a commercial perspective I'd say they were absolutely right. > CP/M was specific to any Z-80 computer it had been ported to. MS-DOS is > specific to any 8088 computer, as long as that computer is an exact clone of > the IBM PC. See the difference? CP/M was processor dependent, but not Not quite right Dave. In the early days, MS-dos was made available on several non-clones. MS-dos was implemented to operate on top of a System-dependant BIOS. The intention was that USER programs would NOT use BIOS calls, nor access the hardware directly. I know of at least two MS-Dos implementations (both more than 6 years since release) where the "BIOS" is in fact a multi-tasking, interrupt-driven O/S, more powerfull in it's own right than MS-DOS (which it views as a task). PC-DOS, on the other hand, _IS_ clone specific. PC-DOS (as released by IBM) contained IBM additions. IBM also encouraged (through detailed documentation) the direct calling of BIOS routines, and direct access to hardware. Due to the commercial realities of 3rd-Party developers going after every last ounce of performance etc etc, they have bypassed the O/S in many cases. This was not helped by the severe lack of features and future-direction compatibility considerations in the O/S. So what happens? Everyone goes their own way, the O/S slowly becomes almost irrelevant and you end up with a marketplace based around a Hardware Interface (the "Clone") rather than a software model of a virtual hardware environment. Some user software (eg: Multiplan 3.0) has been released as both MS-DOS *AND* PC-DOS compatible. (ie: avoids System-specifics). > system dependent. MS-DOS, for all intents and purposes, is system dependent, > as the owners of Tandy 1200s or Mindsets could well attest to. As above, don't confuse MS-DOS, with PC-DOS/ PC-Clone requirements. Imagine what the Amiga environment would be like in 5 years time if Commodore had a generally incompetent O/S, had/did not provide for future expansion, etc etc. We would be just like the PC marketplace is today: Fragmented with many incompatible, 3rd-party, proprietary add-ons Both Microsoft & IBM admitted this with the OS/2 strategy. Here they tried to get the world to follow them into a better non-hardware specific environment. But it has a cost, memory and performance. It seems the world is not prepared to pay that price ... Remember, today IBM is the largest Clone builder around. They are now trapped the same as everyone else. They tried to change direction and the world ignored them ... Wait 'till Commodore are forced to change the underlying hardware definition of the Amiga range (ie: the chipset). Then we'll see how many developers have been listening!!! -- Cheers Peter S. Ingham ping@ping.actrix.gen.nz Lower Hutt, New Zealand