3 ms·

This all kinda obvious if you're familiar with the 386 hardware and early PC history. The OG 8086 was a chip from a different world than what a modern develope

by csense 2y ago

This all kinda obvious if you're familiar with the 386 hardware and early PC history. The OG 8086 was a chip from a different world than what a modern developer is used to (even a modern PC developer). The 8086 is definitely rooted in the tradition of earlier CPU's of the first days of home computing in the 1970's. While it had segments instead of banks, the 8086 was a near-contemporary and near-peer of classical bank-switched 16-bit CPU's of the 1970's, like the Zilog Z80, Motorola 68000, or MOS 6502. After the IBM PC had already gotten popular, people wanted to bring protected mode OS's and software to the PC (especially as these were standard features on the "big boy computers," i.e. time-shared multiuser systems like mainframes and VAX's). So Intel made the 286 and IBM put it in the PC/AT and its successor, the PS/2. The 286 suffered from a number of design issues. It was still 16-bit. And critically, you couldn't easily mix protected mode and real mode. This meant anyone who wanted to run a fancy new protected-mode OS had to sacrifice their entire existing userspace of DOS software. Interest in the feature was extremely tepid; most people simply used their 286 as a faster 8086. For the next chip, the 386, Intel learned from those mistakes. They added all the infrastructure needed to virtualize a complete 16-bit real-mode system (I/O ports, memory ranges, interrupts). The 386 has three operating modes: Real mode, protected mode, and virtual 8086 mode. The latter is what they use for DOS emulation in OS/2 and Windows 95. The OS/2 2.x DOS emulator was pretty amazing technology back in 1992. Equally amazing is that there was little technical reason it couldn't have been released much earlier; the 386 debuted in 1985! It was around this time that OS developers basically decided "Segments were a mistake. Let's just give every process a flat address space and use the MMU to manage memory with pages rather than segments," a design decision doubtlessly helped along by the fact that the 386 MMU could manage memory with pages rather than segments. (This was, in hindsight, a solid design decision that has stood the test of time. C programmers these days have no idea what a far pointer even is, and it's probably better that way.) Unfortunately the 386's protected mode had its own fatal flaw: It was only designed with the necessary traps to emulate a real-mode guest. Hardware support for emulating a protected-mode guest didn't appear until well after the turn of the millenium, with Intel Vanderpool and AMD Pacifica. (Not coincidentally, modern cloud computing and VPS hosting -- which we all take for granted today -- started to appear not long after. Before this time, "hosting" was understood to mean "rent a whole server" or "rent a UNIX / Linux shell account on a shared server.")

tom_ 2y ago
Surely 6800 rather than 68000. You can't put the 68000 in the same category as the 6502 and 8086! It just isn't fast enough! (Also: the 24-bit address bus meant not much need for bank switching. The 16 MB limit wasn't a problem until well after 68000 systems had become outdated, or superseded by equivalents based on the (fully 32-bit) 68020 or later.)
anyfoo 2y ago
From hands-on experience, I've learned that v86 initially had some severe, ugly warts, which made writing a v86 "hypervisor" way more tedious, and make it run slower, than what seemed reasonable. These limitations were addressed in much later CPUs in the so called "VME" extensions, for which there was apparently quite some drama related to NDAs, and subsequent reverse engineering: https://www.rcollins.org/articles/vme1/ https://www.rcollins.org/articles/vme1/ My (long abandoned) toy OS used virtual 8086 to provide "DOS services" support. The idea was that I could focus on the interesting parts of the OS, and outsource everything that I either hadn't gotten to yet, or that I didn't want to get to, to DOS. That included several devices, the filesystem, an entire shell (command.com isn't great, but better than nothing), even networking through packet drivers if needed. The OS was a "modern" and full protected mode true multitasking OS, but one of its task was the DOS instance you started it from, transplanted as a v86 task, and my OS could just call into that (and vice versa, so you could run DOS programs that call into my OS). Initially, even allocating memory would just ask DOS to do the bookkeeping! (I never got to implement VME since I made v86 work on itself, and I dropped this toy project once my work fully shifted to working on real OSes at that level anyway.)
- lproven 2y ago
  > outsource everything that I either hadn't gotten to yet, or that I didn't want to get to, to DOS. Good plan. I think I wrote, circa 2000, that BeOS was the best PC OS I'd ever seen by far -- but the critical lack of apps was a deal-breaker. But if it had a DOS shell, I could still in 1999-2000 have done all my actual work in DOS apps, and just used native BeOS for Internet stuff. But it never got a DOSbox.
jamesfinlayson 2y ago

by csense 2y ago

tom_ 2y ago

Surely 6800 rather than 68000. You can't put the 68000 in the same category as the 6502 and 8086! It just isn't fast enough! (Also: the 24-bit address bus meant not much need for bank switching. The 16 MB limit wasn't a problem until well after 68000 systems had become outdated, or superseded by equivalents based on the (fully 32-bit) 68020 or later.)

anyfoo 2y ago

From hands-on experience, I've learned that v86 initially had some severe, ugly warts, which made writing a v86 "hypervisor" way more tedious, and make it run slower, than what seemed reasonable. These limitations were addressed in much later CPUs in the so called "VME" extensions, for which there was apparently quite some drama related to NDAs, and subsequent reverse engineering: https://www.rcollins.org/articles/vme1/ https://www.rcollins.org/articles/vme1/ My (long abandoned) toy OS used virtual 8086 to provide "DOS services" support. The idea was that I could focus on the interesting parts of the OS, and outsource everything that I either hadn't gotten to yet, or that I didn't want to get to, to DOS. That included several devices, the filesystem, an entire shell (command.com isn't great, but better than nothing), even networking through packet drivers if needed. The OS was a "modern" and full protected mode true multitasking OS, but one of its task was the DOS instance you started it from, transplanted as a v86 task, and my OS could just call into that (and vice versa, so you could run DOS programs that call into my OS). Initially, even allocating memory would just ask DOS to do the bookkeeping! (I never got to implement VME since I made v86 work on itself, and I dropped this toy project once my work fully shifted to working on real OSes at that level anyway.)

lproven 2y ago
> outsource everything that I either hadn't gotten to yet, or that I didn't want to get to, to DOS. Good plan. I think I wrote, circa 2000, that BeOS was the best PC OS I'd ever seen by far -- but the critical lack of apps was a deal-breaker. But if it had a DOS shell, I could still in 1999-2000 have done all my actual work in DOS apps, and just used native BeOS for Internet stuff. But it never got a DOSbox.

jamesfinlayson 2y ago