I worked at Digital Research from 1984 to 1990. CP/M-68K was the first operating system I used there, but only for a brief period. It's unfortunate that the source for FlexOS is not available; it would be a better choice for a hobby project like this.
It was a protected mode OS for the 286 that had a real-time kernel, TCP/IP stack, DOS compatibility box, and more. It was a clean break from CP/M. IBM used it in their point-of-sale terminals for quite a few years, and I worked on porting it to 32-bit architectures like the NEC V60. It died after Novell bought DRI, aside from its use inside IBM.
One thing that sticks in my mind was that the system call API was well-designed (by Frank Holsworth). Everything involved getting or setting tables (structures). The documentation for this was really quite good.
I'm pretty sure CP/M 86 was already a thing. I believe there was even Concurrent CP/M 86, which let you run up to 4 (or more?) virtual sessions concurrently. Light years ahead of MS-DOS but nobody wanted it, so DRI dumbed it down and added MS-DOS compatibility and re-released as DR-DOS (still superior to MS-DOS though).
CP/M-86 was definitely a thing, but CP/M-386 was not. By the time the 386 existed, DRI had dropped the CP/M name in favour of Concurrent DOS - though they had MS-DOS compatibility in Concurrent CP/M - and, as you say, eventually renamed it to DR-DOS.
Much as I loved DR-DOS, it did have occasional compatibility hiccups.
Also, it was super common practice to just go direct to undocumented internals. You didn't have a clean API to duplicate, you had all the untamed glory of a CPU with no MMU to deal with, and all the programs that did shonky things because they worked.
> which let you run up to 4 (or more?) virtual sessions concurrently
On the console -- but the selling point was that you could also attach dumb terminals to the serial ports and they could run DOS apps too. So you had a cheap multiuser box, where adding 3 or 4 or 8 more users cost about 10% as much as a network with 3 or 4 or 8 more client PCs.
> Light years ahead of MS-DOS but nobody wanted it,
No, not at all. One descendant is still supported today, some 45 years later.
> so DRI dumbed it down and added MS-DOS compatibility
No, not even slightly.
> and re-released as DR-DOS (still superior to MS-DOS though).
Not a fair description at all.
Here's how it went:
MS-DOS beat it to market.
So, DR brought multitasking and multiuser from MP/M to turn CP/M-86 into Concurrent CP/M: CCP/M-86
MS-DOS did great. So, lots of apps.
So, DR added DOS compatibility to CCP/M.
It also did a single-user OS, called DR DOS Plus. Oversimplification: this was a single-user non-multitasking CP/M-86 that read/wrote FAT and could run DOS apps.
Intel did a new chip, the 80286.
DR ported to it. A native protect-mode 286 OS, which used new 286 features to pre-emptively multitask DOS apps.
Intel removed those features before it launched the 286. This killed DR's new OS.
So, it refocused: it temporarily dropped DOS compatibility, and sold it as an RTOS instead, with a multitasking version of GEM as its GUI.
Intel put the features back and Concurrent DOS 286 became a product but it was too late. This was a better OS/2 before OS/2 1.0 launched.
Intel put DOS multitasking into hardware in the 386. DR rewrote CDOS286 in C creating CDOS386.
This had really good DOS compatibility.
So DR updated DOS Plus to make DR-DOS: a superset of MS-DOS 3.3, with FAT16 for big hard disk, and it could run DOS device drivers.
This did OK.
IBM did DOS 4. Bigger, but with big disk support, and a GUI app launcher/file manager.
DR leapfrogged with DR-DOS 5: all that, but smaller, with built-in memory management.
A brief arms race ended with Win95 which bundled MS-DOS and so killed the DOS market.
Meantime, DR took the better DOS compatibility and made Multiuser DOS, which did well and throve for decades.
cp/m-86 targets 8086, which is no more useful or relevant to 386 protected mode than the original z80 version. Did you think they just picked the 68k version at random?
> cp/m-86 targets 8086, which is no more useful or relevant to 386 protected mode than the original z80 version. Did you think they just picked the 68k version at random?
The big reason for picking the 68K version is it was mainly written in C (initially in Pascal, but they later switched to C.) By contrast, the more famous 8080 versions were largely written in assembly, as was the 8086 version.
Well, CP/M-80 1.x was mostly written in PL/M, a dialect of PL/I developed by Gary Kildall, but CP/M-80 2.x+ was rewritten in assembly for speed; PL/M was still used for some of the utilities. Obviously, C compilers are much easier to come by nowadays than PL/M compilers are.
One of my first jobs, back in the 1980s, was a project for a government department that the supplier (Wang Computers) had bet on MS-DOS being multi-process.
Of course, it wasn't but there was MP/M-86/CCP/M/CDOS/DR-DOS which allowed you to have 4 "users"/virtual TTYs.
So we ended up using that along with some tweaks to the software (including an IBM 3270 emulator, MS-Word/Excel (the DOS versions), and a custom software app) that ended up getting deployed to a few hundred government offices.
Mostly worked except some of the software really didn't like the fact that it was being swapped out of keyboard/screen access.
Just as some off-the-top history, MS-DOS was clearly obsolete, but it hung around for like 10 years too long because people couldn't quit it. It was a DOSSY DOS world.
"Protected Mode DOS" went through the IBM/MS gristmill and became OS/2, which was a compromised product in a lot of ways. Then Windows (still mostly a DOS program) got a little traction, and Microsoft had hired Dave Cutler to write a real OS. And David overthrew Goliath and the rest is history. On topic, nobody really wanted protected-mode DOS or CP/M etc.
Windows 3.0 becoming a hit was something unplanned by Microsoft originally - even the NT team was working with the assumption of using OS/2 API for applications. Win3.0 started out as skunkworks project initially hiding from management under smokescreen of just being one last release of "windows as application library" that some products (including 3rd party ones) were using
> I remember wandering over to the Windows group over in Building 3 to talk to Aaron Reynolds about something to do with the MS-DOS redirector (I was working on DOS Lan Manager at the time). I ran into David, and he called me into his office "Hey, look at what I've got working!".
> He showed me existing windows apps running in protected mode on the 286. UNMODIFIED Windows 1.0 applications running in protected mode. He then ran me around the rest of the group, and they showed me the other stuff they were working on. Ralph had written a new driver architecture called VxD. Aaron had done something astonishing (I'm not sure what). They had display drivers that could display 256 color bitmaps on the screen (the best OS/2 could do at the time was 16 colors).
> My jaw was dropping lower and lower as I moved from office to office. "Oh my goodness, you can't let Steve see this, he's going to pitch a fit" (those aren't quite the words I used, but this is a family blog). You see, at this time, Microsoft's systems division was 100% focused on OS/2 1.1. All of the efforts of the systems division were totally invested in OS/2 development. We had invested literally tens of millions of dollars on OS/2, because we knew that it was the future for Microsoft. OS/2 at the time just ran a single DOS application at a time, and it had only just recently gotten a GUI (in 1989). It didn't have support for many printers (only about 5, all made by IBM, and (I believe) the HP Laserjet).
> And here was this little skunkworks project in building three that was sitting on what was clearly the most explosive product Microsoft had ever produced. It was blindingly obvious, even at that early date - Windows 3.0 ran multiple DOS applications in virtual x86 machines. It ran Windows applications in protected mode, breaking the 640K memory barrier. It had a device driver model that allowed for development of true 32bit device drivers. It supported modern displays with color depths greater than had been available on PC operating systems. There was just no comparison between the two platforms - if they had to compete head-to-head, Windows 3.0 would win hands down.
MS-DOS became obsolete only at the launch of Windows 95.
Until then, all the applications that could be found for Windows 3.0 or Windows 3.1 looked like worthless toys in comparison with the professional applications that were available for MS-DOS, despite the fact that the latter had to struggle with extended memory or expanded memory in order to use more than 640 kB of memory.
From 1990 to 1995, I had Windows 3.0, then 3.1, then 3.11 and I launched them from time to time, for fun, but to accomplish real work I always had to go back to MS-DOS.
> MS-DOS became obsolete only at the launch of Windows 95.
Not even. The genius of Windows 95 was you could still run most of your DOS crap. (Maybe not games, but business apps.) Novell shops for example had a huge pile of DOS drivers and all that just worked underneath 95. DOS only faded away afterwards.
When I started playing with Windows 95 I worked in a Novell shop, and was really impressed with the effort MS put into implementing the Netware networking stack. I had expected strong LANMan drivers and indifferent Netware drivers, but MS obviously knew where the market lay.
At first Windows 95 was not great for games, so at least through 1996-97 many games were still released for MS-DOS and often only for MS-DOS, or only had Windows ports later.
Looking back from now, I wish that era could have continued much longer, as running MS-DOS games in emulators is so much easier and more stable than to run old Windows games.
Additionally, Microsoft had a first attempt to a gaming API for Windows, which mostly one those of us that were alive back then remember it, given how hard it is to search for it on the Internet.
Really, how come anyone find something about WinG, if they don't know what they are actually searching for?
Wasn't that abbreviation from "pipe"? As in - this is a pipe that you can use to connect terminal to a file, file to a printer... and yes, file to a file (that's cp/copy).
My assumption on the reason that it requires 2M or more is all the memory mapped I/O devices in the first 1M of PC memory. They just wanted to avoid the whole page and set the origin at 2MB.
Hi there, this is my project. And yes, you are essentially correct. It can actually work in a little less than 2MB, but this was done this way for simplicity, and to avoid, for now, what would be a more complicated memory map and paging requirements.
CP/M‑386 is currently in the very early development stages.
Full 32‑bit protected mode implementation with Ring‑3 TPA.
Bootable via 3.5" 1.44MB floppy disk MBR or GRUB Multiboot kernel.
Supports VGA text (0xB8000) and/or COM1 serial (9600/N/8/1, 0x3F8) consoles.
No floppy/hard disk/CD/USB/network/sound/other drivers (yet).
So it boots from a floppy, but has no floppy disk support?
That's not surprising. The page says the kernel is multiboot compliant, which means it can be loaded by existing boot loaders. Whether the kernel later provides a floppy driver is a separate story.
This is also pretty common even if you don't use multiboot. The I/O services exposed by the BIOS or firmware during boot may not be usable once the kernel has started, and thus the kernel has to provide its own drivers.
Yes, currently the system boots from a floppy disk (stage1 -> stage2 loader), which then loads the OS (CBIOS/BDOS/CCP) and an (384K) initial ramdisk, and currently runs out of memory, so once the OS is booted the disk can actually be removed from the system.
Once there is more proper disk support, the initial ramdisk can become optional, though a more proper ramdisk implementation is planned, which will make supporting floppy-disk-only systems easier.
Thank you, as this is my project. As I said in the README, it's as much of a learning experience as it is a "practical" project. Using AI would eliminate the fun.
Yeah, I was a bit shocked to run across the "no AI generated code is in this code base yet", although the project doesn't have an anti-AI contribution policy.
ingesting....but not was like "Star trek project" something like this. DR-DOS evolved from CP/M-86 and they added. And "Star Trek" added to DR DOS a multitasker named "Vladivar" (and a port of System 7 GUI). If I remember it correctly, there is these multitasker in DR-DOS 7 that allow pre-emptive tasking in 32 bits protected mode.
The question is understandable because EMM/EMS use protected mode in a limited way.
In fact, 386 protected mode could still make use of memory segmentation, with 32-bit segment registers being an upgrade from the 286 protected mode.
But there has been no production OS that continued to use segmentation once 386 mode made 32-bit addressing so easy. In large part because Unix could be ported from flat memory models such as VAX, and m68k.
Therefore, since CP/M-386 is derived from CP/M-68K, it seems straightforward that a flat 32-bit memory model is employed.
"by definition you can have flat memory, if you want, but you don't have to."
But everybody wanted to.
In x86-32 you can absolutely have segments if you want. In practice, for an easier but far more insecure life, everyone opted for "one big segment pls kthxbye".
I worked at Digital Research from 1984 to 1990. CP/M-68K was the first operating system I used there, but only for a brief period. It's unfortunate that the source for FlexOS is not available; it would be a better choice for a hobby project like this. It was a protected mode OS for the 286 that had a real-time kernel, TCP/IP stack, DOS compatibility box, and more. It was a clean break from CP/M. IBM used it in their point-of-sale terminals for quite a few years, and I worked on porting it to 32-bit architectures like the NEC V60. It died after Novell bought DRI, aside from its use inside IBM.
The documentation for FlexOS 1.2/1.3 is available on Bitsavers. So someone could re-implement it.
The build kit for CDOS-68k 1.2 (aka FlexOS 68k) is available ob Gaby's site.
I worked for an OEM in the 90s, and we used FlexOS 286 (and 386) ver 2.2/2.3 on some custom systems, including an ePOS system.
That's interesting. I left DRI just before Novell bought it, and wasn't aware of anybody besides IBM using it.
> It's unfortunate that the source for FlexOS is not available
So very true. 100x this.
Looking back on the project, what do you think could be some interesting things one can learn from it?
One thing that sticks in my mind was that the system call API was well-designed (by Frank Holsworth). Everything involved getting or setting tables (structures). The documentation for this was really quite good.
I'm pretty sure CP/M 86 was already a thing. I believe there was even Concurrent CP/M 86, which let you run up to 4 (or more?) virtual sessions concurrently. Light years ahead of MS-DOS but nobody wanted it, so DRI dumbed it down and added MS-DOS compatibility and re-released as DR-DOS (still superior to MS-DOS though).
CP/M-86 was definitely a thing, but CP/M-386 was not. By the time the 386 existed, DRI had dropped the CP/M name in favour of Concurrent DOS - though they had MS-DOS compatibility in Concurrent CP/M - and, as you say, eventually renamed it to DR-DOS.
Much as I loved DR-DOS, it did have occasional compatibility hiccups.
> Much as I loved DR-DOS, it did have occasional compatibility hiccups.
Because MS carefully built them. This was proved in court.
The developers who built the incompatibilities signed their work with their initials: AARD.
https://en.wikipedia.org/wiki/AARD_code
How it was found:
https://www.geoffchappell.com/notes/windows/archive/aard/ind...
Chances are those hiccups weren't without a reason!
https://en.wikipedia.org/wiki/Jim_Allchin#Controversies
Also, it was super common practice to just go direct to undocumented internals. You didn't have a clean API to duplicate, you had all the untamed glory of a CPU with no MMU to deal with, and all the programs that did shonky things because they worked.
MS-DOS truly beat CP/M-86 when it extended the APIs and features in PC/MS-DOS 2.0 (heavily inspired by Xenix), like hierarchical file system.
From then on, applications would target MS-DOS in addition to the curse of being too IBM PC specific
For a while Microsoft was betting their future with Xenix, what an alternative reality that could have been.
I somewhat suspect that if not for multiple materials (not from MS) promoting deep dependency on IBM PC specifics, it might have worked out.
Not 386 though.
I don't want to just quibble for the fun of it but so much more of this is wrong than right that it's downright misleading.
> I'm pretty sure CP/M 86 was already a thing.
Yes it was. Launched after the IBM PC, though, which is why SCP wrote QDOS which they licensed to MS and became MS-DOS.
How and why it was late:
https://nemanjatrifunovic.substack.com/p/the-late-arrival-of...
> I believe there was even Concurrent CP/M 86
There was. And then CCPM-286 and CCPM-386.
> which let you run up to 4 (or more?) virtual sessions concurrently
On the console -- but the selling point was that you could also attach dumb terminals to the serial ports and they could run DOS apps too. So you had a cheap multiuser box, where adding 3 or 4 or 8 more users cost about 10% as much as a network with 3 or 4 or 8 more client PCs.
> Light years ahead of MS-DOS but nobody wanted it,
No, not at all. One descendant is still supported today, some 45 years later.
https://tgcs04.toshibacommerce.com/cs/groups/internet/docume...
> so DRI dumbed it down and added MS-DOS compatibility
No, not even slightly.
> and re-released as DR-DOS (still superior to MS-DOS though).
Not a fair description at all.
Here's how it went:
MS-DOS beat it to market.
So, DR brought multitasking and multiuser from MP/M to turn CP/M-86 into Concurrent CP/M: CCP/M-86
MS-DOS did great. So, lots of apps.
So, DR added DOS compatibility to CCP/M.
It also did a single-user OS, called DR DOS Plus. Oversimplification: this was a single-user non-multitasking CP/M-86 that read/wrote FAT and could run DOS apps.
Intel did a new chip, the 80286.
DR ported to it. A native protect-mode 286 OS, which used new 286 features to pre-emptively multitask DOS apps.
Intel removed those features before it launched the 286. This killed DR's new OS.
So, it refocused: it temporarily dropped DOS compatibility, and sold it as an RTOS instead, with a multitasking version of GEM as its GUI.
Intel put the features back and Concurrent DOS 286 became a product but it was too late. This was a better OS/2 before OS/2 1.0 launched.
Intel put DOS multitasking into hardware in the 386. DR rewrote CDOS286 in C creating CDOS386.
This had really good DOS compatibility.
So DR updated DOS Plus to make DR-DOS: a superset of MS-DOS 3.3, with FAT16 for big hard disk, and it could run DOS device drivers.
This did OK.
IBM did DOS 4. Bigger, but with big disk support, and a GUI app launcher/file manager.
DR leapfrogged with DR-DOS 5: all that, but smaller, with built-in memory management.
A brief arms race ended with Win95 which bundled MS-DOS and so killed the DOS market.
Meantime, DR took the better DOS compatibility and made Multiuser DOS, which did well and throve for decades.
Here's a history I did 4Y ago:
https://www.theregister.com/software/2022/08/04/the-many-der...
Interesting. Thanks for clarifying!
cp/m-86 targets 8086, which is no more useful or relevant to 386 protected mode than the original z80 version. Did you think they just picked the 68k version at random?
> cp/m-86 targets 8086, which is no more useful or relevant to 386 protected mode than the original z80 version. Did you think they just picked the 68k version at random?
The big reason for picking the 68K version is it was mainly written in C (initially in Pascal, but they later switched to C.) By contrast, the more famous 8080 versions were largely written in assembly, as was the 8086 version.
Well, CP/M-80 1.x was mostly written in PL/M, a dialect of PL/I developed by Gary Kildall, but CP/M-80 2.x+ was rewritten in assembly for speed; PL/M was still used for some of the utilities. Obviously, C compilers are much easier to come by nowadays than PL/M compilers are.
One of my first jobs, back in the 1980s, was a project for a government department that the supplier (Wang Computers) had bet on MS-DOS being multi-process.
Of course, it wasn't but there was MP/M-86/CCP/M/CDOS/DR-DOS which allowed you to have 4 "users"/virtual TTYs.
So we ended up using that along with some tweaks to the software (including an IBM 3270 emulator, MS-Word/Excel (the DOS versions), and a custom software app) that ended up getting deployed to a few hundred government offices.
Mostly worked except some of the software really didn't like the fact that it was being swapped out of keyboard/screen access.
Just as some off-the-top history, MS-DOS was clearly obsolete, but it hung around for like 10 years too long because people couldn't quit it. It was a DOSSY DOS world.
"Protected Mode DOS" went through the IBM/MS gristmill and became OS/2, which was a compromised product in a lot of ways. Then Windows (still mostly a DOS program) got a little traction, and Microsoft had hired Dave Cutler to write a real OS. And David overthrew Goliath and the rest is history. On topic, nobody really wanted protected-mode DOS or CP/M etc.
Windows 3.0 becoming a hit was something unplanned by Microsoft originally - even the NT team was working with the assumption of using OS/2 API for applications. Win3.0 started out as skunkworks project initially hiding from management under smokescreen of just being one last release of "windows as application library" that some products (including 3rd party ones) were using
Here's a good anecdote about that: https://web.archive.org/web/20130806213426/http://blogs.msdn...
> I remember wandering over to the Windows group over in Building 3 to talk to Aaron Reynolds about something to do with the MS-DOS redirector (I was working on DOS Lan Manager at the time). I ran into David, and he called me into his office "Hey, look at what I've got working!".
> He showed me existing windows apps running in protected mode on the 286. UNMODIFIED Windows 1.0 applications running in protected mode. He then ran me around the rest of the group, and they showed me the other stuff they were working on. Ralph had written a new driver architecture called VxD. Aaron had done something astonishing (I'm not sure what). They had display drivers that could display 256 color bitmaps on the screen (the best OS/2 could do at the time was 16 colors).
> My jaw was dropping lower and lower as I moved from office to office. "Oh my goodness, you can't let Steve see this, he's going to pitch a fit" (those aren't quite the words I used, but this is a family blog). You see, at this time, Microsoft's systems division was 100% focused on OS/2 1.1. All of the efforts of the systems division were totally invested in OS/2 development. We had invested literally tens of millions of dollars on OS/2, because we knew that it was the future for Microsoft. OS/2 at the time just ran a single DOS application at a time, and it had only just recently gotten a GUI (in 1989). It didn't have support for many printers (only about 5, all made by IBM, and (I believe) the HP Laserjet).
> And here was this little skunkworks project in building three that was sitting on what was clearly the most explosive product Microsoft had ever produced. It was blindingly obvious, even at that early date - Windows 3.0 ran multiple DOS applications in virtual x86 machines. It ran Windows applications in protected mode, breaking the 640K memory barrier. It had a device driver model that allowed for development of true 32bit device drivers. It supported modern displays with color depths greater than had been available on PC operating systems. There was just no comparison between the two platforms - if they had to compete head-to-head, Windows 3.0 would win hands down.
MS-DOS became obsolete only at the launch of Windows 95.
Until then, all the applications that could be found for Windows 3.0 or Windows 3.1 looked like worthless toys in comparison with the professional applications that were available for MS-DOS, despite the fact that the latter had to struggle with extended memory or expanded memory in order to use more than 640 kB of memory.
From 1990 to 1995, I had Windows 3.0, then 3.1, then 3.11 and I launched them from time to time, for fun, but to accomplish real work I always had to go back to MS-DOS.
> MS-DOS became obsolete only at the launch of Windows 95.
Not even. The genius of Windows 95 was you could still run most of your DOS crap. (Maybe not games, but business apps.) Novell shops for example had a huge pile of DOS drivers and all that just worked underneath 95. DOS only faded away afterwards.
When I started playing with Windows 95 I worked in a Novell shop, and was really impressed with the effort MS put into implementing the Netware networking stack. I had expected strong LANMan drivers and indifferent Netware drivers, but MS obviously knew where the market lay.
At first Windows 95 was not great for games, so at least through 1996-97 many games were still released for MS-DOS and often only for MS-DOS, or only had Windows ports later.
Looking back from now, I wish that era could have continued much longer, as running MS-DOS games in emulators is so much easier and more stable than to run old Windows games.
Additionally, Microsoft had a first attempt to a gaming API for Windows, which mostly one those of us that were alive back then remember it, given how hard it is to search for it on the Internet.
Really, how come anyone find something about WinG, if they don't know what they are actually searching for?
https://www.gamedeveloper.com/programming/a-whirlwind-tour-o...
https://betawiki.net/wiki/WinG
https://en.wikipedia.org/wiki/WinG
Also it took until DirectX 5, to have it be usable for games.
Aldus PageMaker is a toy for you ? I remember clearly it working on Windows 3.0
CP/M - because pip just makes more sense than copy.
> pip just makes more sense than copy.
PIP was a stock tool on DEC OS-8 and other OSes of which CP/M was basically a cheapo cut-down Intel version.
https://en.wikipedia.org/wiki/Peripheral_Interchange_Program
It also has an “ed” that will make you miss UNIX’s “ed”. I’ve used it to write programs and it is not fun!
I was a kid at the time, so I only got as far as writing and modifying a few programs in MBASIC.
Anyone that got anything nontrivial to work on those systems deserves much respect.
When I started using it, standard advice was to use Wordstar in text mode.
edilin was in the same page
My computer skills typographic school exam was done with edlin, on MS-DOS 3.3
Never used it ever again.
Wasn't that abbreviation from "pipe"? As in - this is a pipe that you can use to connect terminal to a file, file to a printer... and yes, file to a file (that's cp/copy).
No.
https://en.wikipedia.org/wiki/Peripheral_Interchange_Program
>"Compatible with 386 (and later systems) with 2MB (or more) memory."
Looks good!
An order of magnitude (or two!) less code complexity and less memory hungry than most of 2026's bloated Operating Systems...
Well done!
My assumption on the reason that it requires 2M or more is all the memory mapped I/O devices in the first 1M of PC memory. They just wanted to avoid the whole page and set the origin at 2MB.
Hi there, this is my project. And yes, you are essentially correct. It can actually work in a little less than 2MB, but this was done this way for simplicity, and to avoid, for now, what would be a more complicated memory map and paging requirements.
CP/M‑386 is currently in the very early development stages.
So it boots from a floppy, but has no floppy disk support?That's not surprising. The page says the kernel is multiboot compliant, which means it can be loaded by existing boot loaders. Whether the kernel later provides a floppy driver is a separate story.
This is also pretty common even if you don't use multiboot. The I/O services exposed by the BIOS or firmware during boot may not be usable once the kernel has started, and thus the kernel has to provide its own drivers.
Yes, currently the system boots from a floppy disk (stage1 -> stage2 loader), which then loads the OS (CBIOS/BDOS/CCP) and an (384K) initial ramdisk, and currently runs out of memory, so once the OS is booted the disk can actually be removed from the system.
Once there is more proper disk support, the initial ramdisk can become optional, though a more proper ramdisk implementation is planned, which will make supporting floppy-disk-only systems easier.
First project of this kind on here in a long while that isn't complete AI slop. Well done, really happy to see some people still doing this!
Thank you, as this is my project. As I said in the README, it's as much of a learning experience as it is a "practical" project. Using AI would eliminate the fun.
Yeah, I was a bit shocked to run across the "no AI generated code is in this code base yet", although the project doesn't have an anti-AI contribution policy.
Makes it much more impressive.
While I'm not necessarily 100% anti-AI, it would completely eliminate all the potential for learning and any "fun" from this project.
Careful now. For some reason celebrating not using the slop machine attracts a lot of negative attention.
There's no room for dissent against the slop bot for some reason
ingesting....but not was like "Star trek project" something like this. DR-DOS evolved from CP/M-86 and they added. And "Star Trek" added to DR DOS a multitasker named "Vladivar" (and a port of System 7 GUI). If I remember it correctly, there is these multitasker in DR-DOS 7 that allow pre-emptive tasking in 32 bits protected mode.
Yes, DR-DOS/Novell DOS 7 has a full 386 preemptive multitasking kernel and a decent API, which was essentially unused, with a few exceptions.
See https://web.archive.org/web/20160809210402/http://www.drdos.... and https://web.archive.org/web/20170211175548/http://drdos.net/... for more details
https://lowendmac.com/2014/star-trek-apples-first-mac-os-on-...
Does it support flat memory model or its banked like DOS ?
if it runs in 32 bits protected mode, by definition you have flat memory.
The question is understandable because EMM/EMS use protected mode in a limited way.
In fact, 386 protected mode could still make use of memory segmentation, with 32-bit segment registers being an upgrade from the 286 protected mode.
But there has been no production OS that continued to use segmentation once 386 mode made 32-bit addressing so easy. In large part because Unix could be ported from flat memory models such as VAX, and m68k.
Therefore, since CP/M-386 is derived from CP/M-68K, it seems straightforward that a flat 32-bit memory model is employed.
Also, since CP/M 3.0 on Z80 supported more than 64 kB memory via bank switching, one might expect CP/M to do so on other platforms too.
You probably mean "more than 64KB" or "more than 64KiB", but you're not wrong that 65,536 > 64,000
> by definition you have flat memory.
No, not at all.
It would be more accurate to say:
"by definition you can have flat memory, if you want, but you don't have to."
But everybody wanted to.
In x86-32 you can absolutely have segments if you want. In practice, for an easier but far more insecure life, everyone opted for "one big segment pls kthxbye".
Actually, while the TPA is "flat", the OS model is using only segmentation for protection and not paging currently. Just the segment is quite large:)
[flagged]
Now if I can find those 8” wordstar floppies.