Earliest known copies of 86-DOS...

[PorkyPiggy]

I managed to get in touch with Rich and Lucas and now we are working on a disassembly of 86-DOS 0.11's kernel; will post updates once we make progress.

Meanwhile, I have updated the 86-DOS 0.11 port and ported 86-DOS 0.34 to the IBM PC. Again, I didn't put too much effort into speed enhancements, so they are still very slow. The biggest difference between the updated ports and the original port lies in the disk layout. According to Lucas's research, early pre-releases of PC-DOS from the same era stored the BIOS and kernel in a 'reserved system area' similar to that of CP/M. I feel like it is more appropriate to use the same disk layout IBM used in late 1980/early 1981, so I have modified the boot sector and BIOS accordingly.

86-DOS 0.11 IBM PC Port - v2
I have cleaned the BIOS and boot sector code up, and switched to the period-correct disk layout. Please download "86-dos_0.11_ibm_pc.zip" to test the newest port.



86-DOS 0.11 allows multiple files to use the same name. Not sure if this is a bug or the intended behavior, but it is kind of annoying. Once you have multiple files named the same thing, deleting one of them will delete all of them. You can use the undocumented internal command "CREATE <filename>" test this. I have not tested this under 0.34 yet, because its command interpreter does not have the CREATE command.

86-DOS 0.34 IBM PC Port
Here is my first attempt at porting 0.34 to the IBM PC. Just like the 0.11 port, it uses the early PC-DOS disk layout and runs like sh*t. All utilities should work too, including RDCPM, INIT and SYS. Please download "86-dos_0.34_ibm_pc.zip" to test the newest port.



There is an interesting bug in DEBUG . When you enter in an invalid command, the text becomes garbled like this:



This is caused by the improper printing of MSB-terminated strings. The code looks roughly like this:

CS:0198:
        LODS    BYTE PTR CS:[SI]
        CALL    CS:021C ;Output char
        SHL     AL,1
        JNC     CS:0198
        RET

String termination is checked for after the character is sent to the console. This makes it output the wrong thing for the last character, and in this case, LF gets printed as 0x8A instead of 0x0A. According to Rich, this issue happened to him before and he had to set HyperTerm to strip the high bit. It works fine under SIMH, however:



We suspect that this bug only started to show up when 86-DOS was officially ported to the IBM PC by IBM in late 1980/early 1981, as according to Rich, only a handful of video cards existed for the S-100. It also matches with the fact that 86-DOS 1.00's DEBUG does not have this issue.

Tests
@retrogear Thanks for testing! And yes, I would like you to test my newest ports (see attachments). In addition, if possible, could you please also test RDCPM by copying the 4 text files from the sample CP/M-86 disk ("test_cpm86_disk.zip") onto an 86-DOS disk? I also want to make sure that RDCPM works. Once again, thank you for testing my port .

Sincerely,
Pig

 

[retrogear]

RDCPM is working fine for both v.11 and v.34. More disk back/forth with v.11 clickety clackety head loads.
It took me a while to figure out ERASE deletes files, not DEL or ERA. Is there a wildcard for RDCPM? I tried
*.* and it put the empty file named *.* on my destination A: It's kind of fatal to try and erase a file named *.*

Larry G

 

[mkstabd]

Hi guys:

If you're looking for a full Seattle Computer Products 8086 system, I am ready to part with mine. It's in excellent condition with all documentation. After browsing this thread, it looks like some SCP boards might help your effort.

Also, I have copies of DOS 1.25 and DOS 2.00, along with an assembler and other compilers (all on 8" floppy).

Any interest?

 

[PorkyPiggy]

86-DOS 1.00 IBM PC Port
The first widespread release of 86-DOS. Michal Necasek ported this version to the PC a few years ago, but his port involved copying PC-DOS binaries, and had a pretty serious BIOS bug. My port is a full port with everything working. Like the 0.x ports, it uses the same disk layout as development versions of PC-DOS, so it can also be read using PC-DOS 0.9's CONVERT command. Download "86-dos_1.00_ibm_pc.zip" to test this port.



86-DOS 1.10 IBM PC Port
Yesterday, Lucas shared with Rich and I two copies of 86-DOS 1.10. The earlier internal version was given to him by his friend Ryan, who got it from a former SCP employee. The later released copy came from @geneb's collection. The internal version predates the released version by about a month, and has an internal version (2.33) of the ASM assembler. The released version has the well-known ASM version 2.40 and an extra READTHIS.DOC. Both have been ported to PC compatible hardware. Download "86-dos_1.10_ibm_pc.zip" to test the released version, and "86-dos_1.10_internal_ibm_pc.zip" to test the internal version.



Tests
Again, thank you @retrogear for testing my ports. It's nice to see that RDCPM works, and no, there is no wildcard for 0.11 and 0.34's RDCPM. 86-DOS 1.00+'s RDCPM can handle wildcards and do directory listings of CP/M(-86) disks. You can run "RDCPM DIR B:" to do a directory listing of the CP/M disk in drive B and run "RDCPM B:*.*" to copy all files from B: to the current drive. Could you please test the RDCPM of my 86-DOS 1.00 or 1.10 port? I patched (recompiled) the program to simulate 128-byte sectors using physical 512-byte sectors, so there is a higher chance of f*cking up. Lastly, regarding the file-called-*.* thing, it only happens under 0.11, which does not have wildcard support at all; it is perfectly safe to run "ERASE *.*" (under 0.11 only) to delete the file.

Sincerely,
Pig

 

[roytam1]

[snip]
I have written about the problem in my 86-DOS 1.14 port writeup before, and my solution to it for 1.14 was to patch the kernel. This time I decided to work around it by switching to an internal stack for every DOS BIOS call, so you get this stack switch latency for every single I/O (like printing a character to the screen). I need someone to figure out a way to safely switch SS:SP without having to mess with interrupts and/or flags (you can take a look at IO.ASM to see what I'm talking about).
[snip]

Sincerely,
Pig

alright thanks for your work! and there is some similar efforts by others like http://www.os2museum.com/wp/pc-86-dos/
and I tried to do same for 86-DOS 1.10 and your 1.14 port helped me for io.sys part and I just need patching 86dos.sys for this:

 

[roytam1]

@PorkyPiggy I wonder if you can fix 86-DOS/PC DOS 0.x/1.x doesn't boot on QEMU?
it seems that it runs in a tight loop:

 

[retrogear]

@PorkyPiggy RDCPM worked fine transferring all 4 docs from the cpm86 disk with both 86dos 1.00 and 1.10. I typed all the files received and they were intact.
Did you do a y2k patch? When it prompted for date I see if I enter 4 digits it will take 2024, it rejects just 24.

 

[RichCini]

Hi guys:

If you're looking for a full Seattle Computer Products 8086 system, I am ready to part with mine. It's in excellent condition with all documentation. After browsing this thread, it looks like some SCP boards might help your effort.

Also, I have copies of DOS 1.25 and DOS 2.00, along with an assembler and other compilers (all on 8" floppy).

Any interest?

I have two systems, but it would be good to archive the disks before you part with your system. There's a big storehouse of images being developed.

Rich

 

[roytam1]

@PorkyPiggy RDCPM worked fine transferring all 4 docs from the cpm86 disk with both 86dos 1.00 and 1.10. I typed all the files received and they were intact.
Did you do a y2k patch? When it prompted for date I see if I enter 4 digits it will take 2024, it rejects just 24.View attachment 1271487

oh, RDCPM works on CP/M-86 disks?
I wonder if @PorkyPiggy 's 86-DOS 1.44MB version can work with CP/M-86 1.44MB hack (i.e. 144FEAT2 in http://cpmarchives.classiccmp.org/cpm/mirrors/www.seanet.com/~klaw/files.htm)
see also: https://forum.vcfed.org/index.php?t...m86-boot-sector-contents.1238637/post-1257928

 

[PorkyPiggy]

alright thanks for your work! and there is some similar efforts by others like http://www.os2museum.com/wp/pc-86-dos/
and I tried to do same for 86-DOS 1.10 and your 1.14 port helped me for io.sys part and I just need patching 86dos.sys for this:

I've seen Michal's port before, it is partly why I decided to do 1.14 for the challenge. Looking at it again, my 1.14 port isn't quite up to the standard now; I'm doing a new one. For the port I did in 2022, I bumped the I/O and disk stack up to the save level as MS-DOS 1.25 via kernel patches. It's definitely not the cleanest way of solving stack overflows.

Does your 1.10 port lock up after doing a directory listing (or after running programs)? If it does, you're better off using my 1.10 port for now. Once I publish my new 1.14 port, you can then simply replace its 86DOS.SYS with your own patched 86DOS.SYS.

@PorkyPiggy I wonder if you can fix 86-DOS/PC DOS 0.x/1.x doesn't boot on QEMU?
it seems that it runs in a tight loop:
View attachment 1271464
View attachment 1271463
View attachment 1271465

Bruh, it's the AT&T syntax... I have a few questions. 1. Is the address (0x00006xxx) in the segmented xxxx:yyyy format or the linear format (I think it is in the segmented format, but is CS simply 0 or some other value)? 2. Are you even disassembling valid x86 instructions (I can't really tell what the code is doing, perhaps ROM code?). 3. Does the unmodified IBM PC-DOS 1.00 boot?

If you want me to debug it, could you please send me the QEMU binaries you used to take these screenshots, so that I can reproduce the issue?

@PorkyPiggy RDCPM worked fine transferring all 4 docs from the cpm86 disk with both 86dos 1.00 and 1.10. I typed all the files received and they were intact.
Did you do a y2k patch? When it prompted for date I see if I enter 4 digits it will take 2024, it rejects just 24.View attachment 1271487

Yay! Thanks ! No, I did not do Y2K patches (nor do I think they are necessary). I've only changed the special editing commands to match that of PC-DOS 1.0, as the original ones were designed for dumb terminals. If it rejects 24, then it probably treated it as 1924 instead of 2024.

Sincerely,
Pig

 

[roytam1]

@PorkyPiggy and regarding 250KB 8" disk image, there is a program DiskExplorer can be used to extracting contents with custom profiles: https://www.betaarchive.com/forum/viewtopic.php?p=453761#p453761
one for 86-DOS and another one for MS-DOS.
(but of course it can't deal with 16bytes DIR entry struct)

 

[roytam1]

I've seen Michal's port before, it is partly why I decided to do 1.14 for the challenge. Looking at it again, my 1.14 port isn't quite up to the standard now; I'm doing a new one. For the port I did in 2022, I bumped the I/O and disk stack up to the save level as MS-DOS 1.25 via kernel patches. It's definitely not the cleanest way of solving stack overflows.

Does your 1.10 port lock up after doing a directory listing (or after running programs)? If it does, you're better off using my 1.10 port for now. Once I publish my new 1.14 port, you can then simply replace its 86DOS.SYS with your own patched 86DOS.SYS.



Bruh, it's the AT&T syntax... I have a few questions. 1. Is the address (0x00006xxx) in the segmented xxxx:yyyy format or the linear format (I think it is in the segmented format, but is CS simply 0 or some other value)? 2. Are you even disassembling valid x86 instructions (I can't really tell what the code is doing, perhaps ROM code?). 3. Does the unmodified IBM PC-DOS 1.00 boot?

If you want me to debug it, could you please send me the QEMU binaries you used to take these screenshots, so that I can reproduce the issue?



Yay! Thanks ! No, I did not do Y2K patches (nor do I think they are necessary). I've only changed the special editing commands to match that of PC-DOS 1.0, as the original ones were designed for dumb terminals. If it rejects 24, then it probably treated it as 1924 instead of 2024.

Sincerely,
Pig

I haven't test my patched 86dos.sys 1.10 further, may do it later.

and for QEMU's monitor output, I think it is linear format (since I'm using $pc, not $cs:$ip)
and I think it is valid x86 code
for no.3, PC DOS 1.00 doesn't boot, but it doesn't have a tight loop in low address, it stalls at PC=0x000fff53 which is BIOS area. Compaq DOS 1.12 boots but it stalls after date prompt with PC=0x000fff53 as well.
QEMU binary I used is attached.

 

[PorkyPiggy]

@PorkyPiggy and regarding 250KB 8" disk image, there is a program DiskExplorer can be used to extracting contents with custom profiles: https://www.betaarchive.com/forum/viewtopic.php?p=453761#p453761
one for 86-DOS and another one for MS-DOS.
(but of course it can't deal with 16bytes DIR entry struct)

Thanks, and I have seen that thread before. I have also written a C program to convert 16-byte directory entry disks to normal ones and vice versa (that's how I created those 0.x ports), will throw the source on GitHub later. 86-DOS 1.x can also read/write 16-byte directory entry disks, so you can use them to copy files out too.

There is another tool - Lucas (the same person from that BetaArchive thread) has a modified version of TotalImage for reading disks with 16-byte directory entries, and he shared it with Rich and I in DMs. I'm going to ask him to publish it somewhere, as I don't feel like it is appropriate to upload his work without his permission.

I haven't test my patched 86dos.sys 1.10 further, may do it later.

and for QEMU's monitor output, I think it is linear format (since I'm using $pc, not $cs:$ip)
and I think it is valid x86 code
for no.3, PC DOS 1.00 doesn't boot, but it doesn't have a tight loop in low address, it stalls at PC=0x000fff53 which is BIOS area. Compaq DOS 1.12 boots but it stalls after date prompt with PC=0x000fff53 as well.
QEMU binary I used is attached.

If it is linear address, then something weird is going on. I have no idea what is at that address. DOS BIOS is at 0060:0000 (0x600) and occupies about 3K (if I recall correctly), DOS comes right after the DOS BIOS at 01xx:0000 and occupies about 6K, ROM BIOS is very high up. 0x6B01 would roughly be 0060:6501 and 01xx:5xxx, so not in any known range. If it stalls in the BIOS area or at some random address, it could be stack overflow; you should probably display the bytes around CS:IP to see if they're valid code, not just random bytes/text decoded as instructions.

What command line arguments did you pass to QEMU? I tried using just "-fda path/to/img", it printed "Division overflow" and exited with " Trying to execute code outside RAM or ROM at 0x000a0000".

Pig

 

[mkstabd]

I have two systems, but it would be good to archive the disks before you part with your system. There's a big storehouse of images being developed.

Rich

I was chatting with "wperko" on another thread under MarketPlace about this exact thing. I'm going to try to get the docs cleaned up and scanned, plus dump the ROMs to bin files (e.g. SCP 1.9 BIOS) and upload it to archive.org. Let me know if you think there is another place I should upload it to as well. I'll post something when I have some files in hand.

Apologies to the other posters in this thread. If anyone else reads this who's interested in my SCP system, please PM me about the system so we can keep this thread on point!

 

[roytam1]

Thanks, and I have seen that thread before. I have also written a C program to convert 16-byte directory entry disks to normal ones and vice versa (that's how I created those 0.x ports), will throw the source on GitHub later. 86-DOS 1.x can also read/write 16-byte directory entry disks, so you can use them to copy files out too.

There is another tool - Lucas (the same person from that BetaArchive thread) has a modified version of TotalImage for reading disks with 16-byte directory entries, and he shared it with Rich and I in DMs. I'm going to ask him to publish it somewhere, as I don't feel like it is appropriate to upload his work without his permission.

View attachment 1271491


If it is linear address, then something weird is going on. I have no idea what is at that address. DOS BIOS is at 0060:0000 (0x600) and occupies about 3K (if I recall correctly), DOS comes right after the DOS BIOS at 01xx:0000 and occupies about 6K, ROM BIOS is very high up. 0x6B01 would roughly be 0060:6501 and 01xx:5xxx, so not in any known range. If it stalls in the BIOS area or at some random address, it could be stack overflow; you should probably display the bytes around CS:IP to see if they're valid code, not just random bytes/text decoded as instructions.

What command line arguments did you pass to QEMU? I tried using just "-fda path/to/img", it printed "Division overflow" and exited with " Trying to execute code outside RAM or ROM at 0x000a0000".

Pig

I'm using your "86-DOS 1.14.img" from "86-DOS 1.14 for IBM PC.zip" and command line 'qemu -fda "86-DOS 1.14.img"'

EDIT: with later version of seabios, it stalls in famous 0x000fff53.

 

[maxtherabbit]

Bruh, it's the AT&T syntax...

DISGUSTING

 

[PorkyPiggy]

I have ported 86-DOS 1.14 to the PC and discovered a bug in my 0.11 and 0.34 port. Please download the 86-DOS 1.14 port attached here instead of the 2022 one from my blog, that one has a ton of issues.

86-DOS 0.11 IBM PC Port - v3
Fixed a bug in the BIOS DPT. The last field of the table for 86-DOS 0.x should be the total number of usable clusters, floor(sectors after root directory / sectors per cluster), instead of the disk size in clusters, floor(sectors in disk / sectors per cluster). Please download "86-dos_0.11_ibm_pc.zip" from this post for the latest version.

86-DOS 0.34 IBM PC Port - v2
Fixed the aforementioned BIOS DPT bug. Please download "86-dos_0.34_ibm_pc.zip" from this post for the latest version.

86-DOS 1.14 IBM PC Port - v2
A much better and more reliable port of 86-DOS 1.14. Bugs in INIT, boot sector and BIOS have now been fixed. All unnecessary modifications to the kernel have been undone. It now uses the same disk layout as the original 86-DOS 1.14 and early internal versions of PC-DOS. Please download "86-dos_1.14_ibm_pc.zip" from this post for the latest version.



86-DOS IBM PC Port Package
I have thrown the PC ports of all 6 different available versions of 86-DOS (0.11, 0.34, 1.00, 1.10 internal, 1.10 and 1.14) into a single archive, along with a CP/M-86 disk for RDCPM testing. Please download "86-dos_ibm_pc_port_all_versions_v1.zip" for the latest version of all ports. This is version 1 of the package, new copy will be uploaded if I update any of the disks in the future.

Tests
Special thanks to @retrogear for testing these ports on physical PCs! I am relatively confident that the latest version of these ports are now free of serious bugs, so no more testing is required. Everyone can of course still test these, report bugs and send bugfixes.

Sincerely,
Pig

 

[ajacocks]

Nice work @PorkyPiggy !

- Alex

 

[PorkyPiggy]

I'm using your "86-DOS 1.14.img" from "86-DOS 1.14 for IBM PC.zip" and command line 'qemu -fda "86-DOS 1.14.img"'
View attachment 1271497
EDIT: with later version of seabios, it stalls in famous 0x000fff53.

The lock up in segment 60H looks like a stack overflow overwriting the return address or SS:SP save.

Tried it with my latest 1.14 port (from the previous post) and it displays "Bad or missing Operating System", which is very strange, as that happens only when 86DOS.SYS is missing. Debugging the issue using the built-in monitor reveals that it loaded the first sector of COMMAND.COM instead of the first sector of the root directory, hence it compared the first 11 chars of COMMAND.COM against the string "86DOS SYS".



Why did it do that? I have no idea. Maybe because your QEMU compile is 12 years out of date ? Maybe because your BIOS is 13 years out of date? Seriously though, if all DOS 0.x and 1.x versions (my port and official releases) f*ck up and hang somewhere in the Fxxx:xxxx range, I'd say it's either an emulator issue or a BIOS issue or both.

It works fine under DOSBox too:



So, try a different (version of the) emulator and see if you can get it to boot.

Sincerely,
Pig

 

[krebizfan]

I would expect problems with Fxxx:xxxx because DOS expects something else there. 960K should suffice for testing.
From the beginning of DOSIO.ASM in v0.34

I/O System for 86-DOS.

; Assumes a CPU Support card at F0 hex for character I/O,
; with disk drivers for Tarbell or Cromemco controllers.