PC DOS 1.1 from Scratch | Hacker News Reader

PC DOS 1.1 from Scratch

os2museum.com

99 pointskencausey28 comments

The detailed, loving description of the baroque boot process takes me back to my days, shortly after that period, of cracking and making "boot only" floppies that either wouldn't show files if read normally, or showed different files; while having something else happen if you booted from it.

Twitch and shudder

"Pinball Construction Kit" was a commercial game that used their own floppy format.

Microsoft Flight Simulator (before version 3) was another. The DOS view of the disk contained a single file, FS.COM, 60 bytes long.

I returned two copies of Pirates! thinking the disk was not working until I realized you had to boot from the game disk and not DOS.

> "Pinball Construction Kit" was a commercial game that used their own floppy format.

Software (IME, mostly games, but then my experience with software at the time was game-heavy) that worked that way was quite common.

One of my gigs was for someone selling essentially locked down spreadsheets. to their tiny niche markets, that was effective DRM and an appreciated convenience.

> my experience with software at the time was game-heavy

Well put. min too :)

Also Sega Zaxxon iirc, the only original PC game I had back in the 80s. (I guess the copy protection scheme kinda worked?)

"Cracked" copy:

https://archive.org/details/msdos_Zaxxon_1984 (it's kinda hard)

What's interesting about this is I feel I could write DOS from scratch with little effort these days. But it would have no value today.

The software I write today is far more complex than what was available in the early 80's.

I've had similar thoughts about this development. (Not about myself being able to rewrite DOS without much effort - but I don't doubt that you could!)

The sophistication of some individual projects today rivals major industry efforts back in the early 80s.

I think it boils down to mostly these things:

a) back then the number of software developers was perhaps 100x-500x smaller than today - so there was simply a much smaller pool of smart people. (But also: Today we have a much, much larger pool of kinda meh people.)

b) there was no widespread internet access, so developers learned new concepts very slowly, often re-inventing them on their own. also, smart people often gut stuck in places where they had no chance of excelling.

c) better tools now: much better screens, windowing systems, mice, better editors (edit: not necessarily IDEs), source code version control tools, SSDs instead of floppies, VMs, trivial networking, pdf readers, archive.org/etc, web browsers/services/sites, etc etc.

I don't understand it, myself. The small size of DOS and its utilities make it look, in a word, trivial to me. I've read about the early days of Microsoft and how they struggled to get DOS finished, and from the perspective of today am more or less baffled.

A part of the problem was they wrote in assembler. Today, I would not write it in assembler. I'd write it in C (or DasBetterC!) and get it all complete and debugged. Then, I'd hand translate it to asm. I expect this would go 10x faster.

I'd also develop it on a Unix computer, using an emulator to debug it, much like how Gates/Alan developed Basic. (That was a really smart move by those two.)

I don't use IDEs myself, but git is an absolute game changer.

You have the advantage, in this case, of knowing what the end result is. I can re-write any of my own existing applications in a fraction of the time it took to develop them initially.

But I agree that it all looks trivial. I'm developing an OS for a custom 8bit system and it's pretty slow going even though it's trivial. Of course, if I was cloning an existing OS it would go a lot faster but obsessing over the fine details is part of the fun.

Simply look at the size of the files. There just isn't much code there.

You're quite right about obsessing over the details. But the idea is to work out the details on a more powerful machine in a high level language. Only convert the final configuration in the target assembler.

For example, back in the 1970s (many years before DOS) I developed a handheld LED game for Mattel, it was Hockey. Handheld LED games were cutting edge at the time. The prototype was developed to run on a 6502 8 bit microprocessor. The dev tools for the 6502 were developed in a high level language and ran on a PDP-11, the resulting binaries were downloaded to an EPROM programmer, blown into an EPROM, then put on the 6502 for testing.

Once everything worked to Mattel's satisfaction, the code and the prototype was given to Mattel. Mattel took this, and gave it to their engineers to implement on a 4 bit microprocessor, to behave exactly the same way.

So this was 3 levels of development: PDP-11 => 6502 => 4 bit microprocessor.

Trying to prototype on a 4 bit machine would have been a horribly costly experience.

Remember that the DOS assembler at the time was terrible. Having a competent cross assembler on a mature machine like the -11 was the way to go.

(I also used a 6502 debugger that actually ran on the -11, again making life a lot easier to develop the code for the 6502 where only very primitive bug-ridden software was available.)

By the way, once DOS extenders became available, I ceased all native development under DOS. The reason was simple - the DOS extenders would give a seg fault on memory errors rather than scrambling the operating system.

My dev process hence became much faster. The real mode DOS port was always the last step. Later on, I switched to 386 DOS extenders, then OS/2, then WinNT for development, as always relegating the real mode DOS port to dead last.

Using PDP-11 to build 6502 makes a lot of sense but using that 6502 to prototype for a even simpler processer is very clever. I'm just getting into electronics as something to do over COVID; I feel I'm re-visiting a bit of that era.

The 8-bit computer I'm working on 6502-based. One of the first things I did after "Hello World" on the hardware was write an emulator/debugger for the whole system in C#. I also get to use a pretty nice macro assembler compared to what you would have had back in the day.

You may have encouraged me to go back to a project I've put on hold: I started writing a high-level language that compiles to 6502 assembly. I could use C but it's not very 8-bit friendly and I want to go higher level than that but still keep the 8-bit-ness in mind. I've created a lot of macros but that only gets you so far.

If I had to do a lot of 6502 work today, I'd develop a custom language for it. Much like C is a custom language for the PDP-11 instruction set. C doesn't map very well onto the 6502, but customizing it would.

Good luck on your 6502 endeavor!

A custom language for the 6502 reminds me of the Action! language for the Atari computers. Wikipedia describes it as an ALGOL like language that included an editor, compiler, monitor, and runtime on a bank switching 16k cartridge. It was open sourced in 2015.

Have a look at PLASMA: https://github.com/dschmenk/PLASMA

Nit: Gates/Allen developed their basic on an 8080 emulator running on a PDP-10 (1966), so it wasn't running Unix. The PDP-11 (1970) was the first computer to run Unix. I agree that it was a pretty smart move to emulate the 8080 micro on a (very expensive) mainframe computer.

Source: https://en.wikipedia.org/wiki/Microsoft_BASIC + https://www.inwap.com/pdp10/xkleten.txt

I know it was a -10, I made the mistake of writing that I'd have used Unix and then conflating that with Gates/Allen using a -10.

I imagine you may know a lot about this, but what OS/machine were they using to develop it? PDP-11?, CPM? What editors did they use? Line editors? Which machines did they use to test on? Most drives and even RAM was unreliable back then and everything was small. I imagine there were plenty of obstacles back then. I remember using CPM where floppy disks had to be swapped between the editor and compiler, and your program may fit on another floppy disk.

There are clues they may have used Unix at some point, but the books I've read were vague about that. As the blog post points out, apparently they used MASM that ran on DOS, meaning they were using the IBM PC as the development machine.

The machine description files in GCC and LLVM are probably enough lines to fit a C compiler from the early days in them.

The sophistication is a good thing but for god's sake give me my latency back.

For a minute I thought it was PC DOS 1.1 rewritten in the Scratch language, and I was ready to be impressed. Still a good article. I actually used DOS 1.1, when it came out. I'm old.

Ah, but did you have to program it? Have you known the horror of the FCB? https://en.wikipedia.org/wiki/File_Control_Block

I think my fingers still know edlin.

In high school when we got introduced to text processing, it was on MS-DOS 3.3, using edlin, and those wonderful 8" dual sided floppies.

I share the same sentiment.

> The extra bytes in IBM’s file are mostly zeros, but there’s also a hundred bytes or so of what appears to be junk, more or less random data copied from a buffer that hadn’t been zeroed.

Decades-old junk accidentally pulled from uninitialized RAM, saved to disk and now immortalized? That's curiously poetic, if true.

"To compile PC-DOS from scratch, first you must invent the universe." - Carl Sagan

Apropos of nothing, I had a friend who always pronounced DOS like the Spanish for "two" (like DOHS). Most everyone else I ever met pronounced it like "DAWHS". One day this friend meets my boss at dinner. My boss, though a nice guy, was pretty strictly conservative about certain things. Apparently the pronunciation of "DOS" was one of those things. They went back and forth with "DOHS" / "DAWHS" for a while. When I left the table they were still at it. I stayed at the bar for a half hour 'cause I didn't want to know how long that was going to go on.

Reply on news.ycombinator.com