Why MS-DOS wasn't never released on Z80-CP/M Machines?

[MotorolaFLARE]

Why didn't Microsoft ever release a MS-DOS version for CP/M machines?
Did someone ever did a port of MS-DOS to the Zilog 80?

I think porting MS-DOS 1.x or 2.x to the Osborne 1 (for example) would be possible because Microsoft released source code for them.

[louisw3]

why would they?

the 8080 CP/M were entirely last generation. It was time for the rise of 16bit micros.

There was a lot of people clamoring for that 1MB of addressable space.

[Overdoze]

why would they?

the 8080 CP/M were entirely last generation. It was time for the rise of 16bit micros.

There was a lot of people clamoring for that 1MB of addressable space.

Indeed. CP/M already dominated the 8-bit market, but failed to make an early claim on the emerging 16-bit one. In a way, this decision defined decades of computing history, imagine if DR became what Microsoft is today.

[xelloss]

Why didn't Microsoft ever release a MS-DOS version for CP/M machines?

Unlike modern operating systems, the MS-DOS source code is heavily architecture dependent, and a port wouldn't have been trivial.
But even then, who would have bought DOS to replace CP/M? The whole reason for the success of MS-DOS was the lack of competition in the x86 market.

[John Elliott]

MSX-DOS is probably the closest you'll get.

[os2fan2]

CP/M and such are eight-bit computers. MS-DOS was written for a 16-bit processor, but soon had to overcome the 640 kB barrier. (This for what it's worth, is like the 3 GB barrier in Win32 systems.) In both, they had to write processes like himem.sys etc, to get around the barriers.

MS-DOS did borrow a lot from CP/M, and a 16-bit CP/M does exist.

8-bit machines were more the domain of pre-operating systems, where one might load basic directly and program that. The tandy 1000 laptop was a 8-bit machine, with 24k of gross memory (storage + working memory), you could by extra ram at $1000 for 8 kilobytes, to max it out. It is most notable, in that it had a fat that allowed 32 files of 5.2 names, along with an operating system (a pruned version of basica: no DEFFN routines), an editor, a coms proggie, and you could write to the CAS: device.

[nar002]

How much more advanced was MS-DOS compared to CP/M anyway? Could you do the same things with these, or were there big differences functionality-wise?

[os2fan2]

Much of DOS 1.x is pretty much at the same level as CP/M. But where CP/M was at the end of its tether, DOS was just beginning.

An 8080 can access 64K of ram. A good number of programs at that era were made available as type-in code. The proggie i wrote was entered by paper tape on each boot. However, I did not use an OS, instead the proggie and data shared the same 2K of memory. The data array was 512 bytes or 1024 bytes.

Even DOS 1.x can not handle hard drives. Its last version is 1.5, an OEM thing used to run word-processors (actual typewritters that edit a line at a time) and other things of that nature.

[dfawcus]

Well, CP/M did grow up a bit, even on the Z80.

At one point I had a couple of second hand Morrow MD-11 machines, 128k RAM, 10 MB Full Height 5 1/4" Hard Disk, and I CP/M 3. Somewhat better than the RM 380Z I remember paying with at school, but the 380Z did have good pixel graphics, for which we managed to write a few games (Missile Command, Joust).

After playing for a while, I scavenged the disks to use on a self build 286 PC clone.

[xelloss]

How much more advanced was MS-DOS compared to CP/M anyway? Could you do the same things with these, or were there big differences functionality-wise?

The main advantage of DOS 1.x over CP/M was its file system: FAT was so much more efficient than whatever CP/M used at the time.
Come think of it, we are still using FAT derivatives in 2019: that's quite an accomplishment.

[d3vi1]

Mainly because MS-DOS requires an IBM Compatible BIOS. It depends on it and it extends it. Everything is implemented as a software interrupt. The IBM PC BIOS and the card Option ROMS provide some of the software interrupts (generally hardware access) and MS-DOS provides the rest. If you want, the OS part of MS-DOS is a disk based BIOS extension that also provides filesystem and memory management. Futhermore, the OS is entirely written in ASM, so porting it would require rewriting it and reimplementing the IBM BIOS as well. It just makes no sense. It's the same reason for which FreeDOS is not ported to UEFI.

[Battler]

That's false. If this was true, MS-DOS would never exist for RM Nimbus PC-186, NEC PC-98, or Fujitsu FM-Towns. But it did.

[Overdoze]

That's false. If this was true, MS-DOS would never exist for RM Nimbus PC-186, NEC PC-98, or Fujitsu FM-Towns. But it did.

And for many other x86 computers that didn't have a fully IBM compatible BIOS as well. The whole point of IBMBIO.COM/IO.SYS is that it was adapted by the OEMs to work with their hardware.

[dfawcus]

That's false. If this was true, MS-DOS would never exist for RM Nimbus PC-186, NEC PC-98, or Fujitsu FM-Towns. But it did.

And for many other x86 computers that didn't have a fully IBM compatible BIOS as well. The whole point of IBMBIO.COM/IO.SYS is that it was adapted by the OEMs to work with their hardware.

Quite. The original Apricot XEN was 286 based, an with completely different chips sets for almost every part, and different Monitor calls - it didn't have much of a BIOS. Yet MS-DOS and Windows 1.0 ran on it.

[d3vi1]

Off the top of my head, the following software interrupts would need to exist for any reasonably software:
int10h for video card access
int13h for disk access (partitioning software and such)
int14h for serial port access
Int17h for parallel port access
int1Ah for RTC access

I'm not saying that they couldn't be implemented as long as you had an x86 CPU, but without them MS-DOS wouldn't even work. They had to be implemented in the ibmbio.sys/io.sys. You would have to implement most of what the IBM BIOS and the VGA Option ROM do in order to have a functioning DOS. It's actually why old DOS versions needed to be customized by the OEM and were not available in retail. So basically DOS assumed IBM compatible unless you added the missing bits. And if you did, software that depended on those software interrupts would fail to work anyway.

Regarding the other examples, they were x86 computers and my initial point of it being basically X86-ONLY still stands. You needed x86 since you didn't have an official OS SDK with standard libraries.

Porting software to a Z80 version of MS-DOS would require rewriting the software, not just a recompile since you weren't using libraries but calling direct software interrupts with x86 style registers for parameters and return values.

The BIOS was the worst part of X86. As an example: on non-AT computers by IBM (such as the early PS/1 series), although they all had a very standard IDE (I/O ports and IRQ), since the FDPT was not at the 40h address most protected mode OSs would fail to detect the disks, including Linux. I remember that on Linux, I had to use: ide0=0x1f0,0x3f6,1 hda=3884,16,63 hda=noprobe in order to boot, because the probing would blindly look for the FDPT expecting the same address for it as an AT system, but the PS/1 was not AT. Microsoft actually expected the BIOS to die very soon and in Windows NT expected the kernel to be loaded by an ARC firmware (conceptually very similar to the modern EFI). NTLDR/NTDETECT were precisely that, an ARC firmware emulator with osloader.exe ARC binary padded at the end of the binary and it used boot.ini to deduce the firmware variables that OSLoader should get (SYSTEM PARTITION, OS LOADER PARTITION, etc.).

Anyway, I've diverged from the original thread.

[dfawcus]

I suggest you investigate the MS-DOS OAK, there is at least one version floating around out there.
See here - summary and here - readme.txt for an intro.

MS-DOS came in two parts, MSDOS.SYS and IO.SYS; MSDOS.SYS made no BIOS calls, it had all hardware dependent logic handled by IO.SYS. It is IO.SYS which makes BIOS calls. The OAK included complete source for IO.SYS, and the tunable bits for system startup / bootstrap.

This what the likes of Apricot used for port MS-DOS.

Hence real useful DOS programs, which only used console output could be run - e.g. various compilers and development tools, even on non PC compatible systems.

Yes later software made use of PC BIOS calls, and even assumed PC clone hardware, but there were some programs supplied with drivers for non PC compatible MS-DOS machines, and some even just used the likes of ANSI.SYS for screen output.

[os2fan2]

A really useful DOS in 64K. You're kidding, i suppose.

[Battler]

Off the top of my head, the following software interrupts would need to exist for any reasonably software:
int10h for video card access
int13h for disk access (partitioning software and such)
int14h for serial port access
Int17h for parallel port access
int1Ah for RTC access

I'm not saying that they couldn't be implemented as long as you had an x86 CPU, but without them MS-DOS wouldn't even work. They had to be implemented in the ibmbio.sys/io.sys.

Well, MS-DOS worked fine on the PC-98 with video access on INT 18h, for example. Now yes, a lot of DOS software for IBM compatibles did not work on PC-98, but anything that only used the DOS API, did (eg. LHA/LHARC, PKZIP/PKUNZIP, PKLITE, etc.).