• Please review our updated Terms and Rules here

Earliest known copies of 86-DOS...

geneb

geneb

Veteran Member
Joined
Aug 19, 2003
Messages
525
Location
Graham, WA USA
This past week I've been imaging disks in my 8" disk collection and I came across two awesome artifacts:

archive.org

86 DOS Version 0.1 C Serial # 11 ( ORIGINAL DISK) : Seattle Computer Products : Free Download, Borrow, and Streaming : Internet Archive

86-DOS Version 0.1-CSerial #11Copyright 1980 by Seattle Computer ProductsThis is the precursor to MS-DOS and is likely the oldest known version to survive. ...
archive.org
archive.org

86 DOS Version 0.34 C Serial # 221 ( ORIGINAL DISK) : Seattle Computer Products : Free Download, Borrow, and Streaming : Internet Archive

86-DOS Version 0.34-CSerial #221Copyright 1980 by Seattle Computer ProductsThis is the precursor to MS-DOS and is likely the 2nd oldest known version to...
archive.org

Both are bootable in simh.

g.
 
Hi,

Neat, but does the 86 DOS require an 8086 to BOOT? or, can it BOOT on an 8080 or Z80?

.
 
wperko said:
Neat, but does the 86 DOS require an 8086 to BOOT? or, can it BOOT on an 8080 or Z80?
Click to expand...

If you want to run 86-DOS on "real hardware" and not a simulator then yes - you need an 8086. To be more specific, I believe these earliest versions require a Seattle Computer Product's 8086 CPU board and Support Board, and the Tarbell floppy controller, for the S100 bus.
 
I wonder if the C after the version indicates it was assembled for Cromemco. Both do boot on the Cromemco controller.
The source code has flags for Cromemco, Tarbell and Northstar.

Larry G
 
retrogear said:
I wonder if the C after the version indicates it was assembled for Cromemco. Both do boot on the Cromemco controller.
The source code has flags for Cromemco, Tarbell and Northstar.

Larry G
Click to expand...
Thanks Larry - I should have said you need a Cromemco 4FDC floppy controller to boot the specific disks images Gene uploaded. One could also use the Tarbell or Northstar controllers, but that would require a reassembly of the source code provided.
 
It's interesting there was a directory change with 86DOS V1.00. It can read the earlier versions V.1 and V.34 but trying from the earlier ones to read V1.00 get filenames but garbage characters added. I see it was claimed 86DOS was all FAT-12 but something changed.

Larry G
 
retrogear said:
It's interesting there was a directory change with 86DOS V1.00. It can read the earlier versions V.1 and V.34 but trying from the earlier ones to read V1.00 get filenames but garbage characters added. I see it was claimed 86DOS was all FAT-12 but something changed.

Larry G
Click to expand...
The directory entry doubled in size from 16 bytes to 32 bytes. You should see garbage characters for every other filename when reading a v1.0 disk under v.34 since the second filename isn't a filename at all.
 
wperko said:
Neat, but does the 86 DOS require an 8086 to BOOT? or, can it BOOT on an 8080 or Z80?
Click to expand...
The first couple of bytes of the boot sector answers that. Do take a few minutes and download the image and browse the data. :) This also will answer the directory entry size.
 
I have made an in-depth video showing how 86-DOS was used in context, in this case, to port a piece of Z80 code to 8086, and getting it from CP/M into 86-DOS to run.

It shows the compatible API choices that allow this to happen with nothing more than an instruction translation, and spends a bit of time at the end of the video addressing and demonstrating the elephant in the room:

"Implementing a published API is not the same as stealing code."


-Thom
 
krebizfan said:
The directory entry doubled in size from 16 bytes to 32 bytes. You should see garbage characters for every other filename when reading a v1.0 disk under v.34 since the second filename isn't a filename at all.
Click to expand...
I should have addressed this in the video. darn :)
-Thom
 
I thought that the CP/M 2.2 API compatibility was common knowledge, right down to the far call in PSP+5, continued on through 16-bit Windows DOS implementation in XP. I was aware of it in PC-DOS 1. Why else make 100h the default load location for .COM files?
 
Chuck(G) said:
I thought that the CP/M 2.2 API compatibility was common knowledge, right down to the far call in PSP+5, continued on through 16-bit Windows DOS implementation in XP. I was aware of it in PC-DOS 1. Why else make 100h the default load location for .COM files?
Click to expand...
For us, it definitely is. But there is this persistent (like herpes) anecdote that 86-DOS stole code from CP/M.

Even after being cited in multiple reverse engineering court cases over the last 40+ years...
...even after having BOTH 86-DOS _AND_ CP/M 2.2 ON #@(%$#@)% GITHUB...
...where you can literally look at BOTH sides...
...this idiotic rumor still persists because "THE FUNCTION CALLS ARE THE SAME"

All the people with smooth noodle maps, I swear to god...

-Thom
 
As to "why MS and 86-DOS and not CP/M-86?", the question to me is pretty simple. It's easy to do automated conversion of 8080 assembly-code applications to PC-DOS; not quite as easy with CP/M-86.
 
That would be something to test: does the CALL 5 interface exist in the earliest version of SCP-DOS?

One other difference between CP/M-86 and MS-DOS is that CP/M-86 uses CL to pass arguments while DOS did it with AH. CL is what one gets with automatic 8080 to 8086 conversion so it always seemed a bit odd that DRI forced the code to be rewritten to use interrupt E0. DOS's code for CALL 5 was complex as the stack gets reordered and the function is moved from CL to AH before going into the standard INT 21 handler.
 
krebizfan said:
That would be something to test: does the CALL 5 interface exist in the earliest version of SCP-DOS?

One other difference between CP/M-86 and MS-DOS is that CP/M-86 uses CL to pass arguments while DOS did it with AH. CL is what one gets with automatic 8080 to 8086 conversion so it always seemed a bit odd that DRI forced the code to be rewritten to use interrupt E0. DOS's code for CALL 5 was complex as the stack gets reordered and the function is moved from CL to AH before going into the standard INT 21 handler.
Click to expand...
K,
How do you know that? (lol)

Only a deep programmer would know something like thaaaaaaaaat!
 
Last edited:
You must log in or register to reply here.
Back
Top