Interesting to see the author shipping a DOS binary instead of something web based with Javascript.
I had a relative do exactly the same a while ago for a standalone program, which made me curious about such a choice.
In a nutshell: DOS can be seen as a lightweight runtime, it's reasonably secure (easy to isolate from the web), has low requirements, doesn't require updates, and the tools to build the program are small, free and reproducible (ex: Turbo C) so he can come back to it in a few years and be confident everything will build the same.
So he treats DOS as an autonomous, lightweight container with graphic capabilities. A bonus is that it can run on basically anything, with stellar efficiency if baremetal. The main disadvantage is that programs look dated.
I was considering making my current game in DOS for these reasons. Basically you get a graphics-capable VM that runs on virtually any platform with stable tools. I wanted multiplayer/networking to be a big part and seamless though, so I went a different direction.
I think this is sometimes missed when considering why Flash was so popular.
The rich all in one tooling is one part, but the packaging, and sandboxed nature of them is what spawned the ecosystem.
An author could just focus on their experience, without getting bogged down in any Web complications (or indeed requiring any web specific knowledge at all), compile out an .swf, and share a simple file. Those hosting could then easily embed them knowing they were completely confined to their little box, and couldn't escape.
You can treat Web browsers themselves the same way—the "Web" part is optional. They run single-file programs quite capably.
(What's nuts is that all the Web developers don't get this. They end up writing all their tooling against NodeJS, instead of the JS runtime everyone already has and that, for that reason, is the entire basis for how their field is actually able to produce things that users can actually use.)
I ended up using js/html5. For stylistic purposes, I created my own VGA-esque framebuffer and drawing functions. I'm looking into packaging for native downloads for when people don't have access to the website. The lack of typing in javascript is really annoying, but otherwise it's been fine.
I think 8-bit CPUs are great for introducing computer technology, and they also lend themselves to discussing computing history from the 70s. Though a little more expensive than the author's target of $100, the fellow who designed this educational CPU board (https://kswichit.net/6502/6502.html) sells them (assembled) on eBay for a very modest amount of money. I have used these with students, and we had a great time with them. There is even a crude online simulator of the board that emulates the LED outputs (https://tiggerntatie.github.io/kswichit-6502/).
I've never considered assembling projects the fun part. that's the "ok whew done, I hope I didn't screw it up," part. it's not even an educational part of the project, unless you are educating on soldering somehow.
Related, LMC is a great simulator to learn basic CPU instructions on (I encountered it both at school and at university [UK]): https://peterhigginson.co.uk/lmc/
Back in my CS 101 class, we, too, had a simple CPU simulator.
Nothing like this. It was a simple assembly language with, perhaps, 16 or so instructions. The simulator was written in BASIC PLUS on the RSTS/E PDP 11/70.
I only mention it anecdotally to comment on, perhaps, how little early CS education has changed over the years.
The other fun anecdote was a friend of mine also took the class. The assignment was to multiply two numbers. We’re talking a very simple loop, not even binary multiplication with shifts and what not.
Rather than writing the simple loop, my friend changed the simulator and added a multiply instruction.
The instructor was not amused by his out of box problem solving.
Now that is some dream machine... Hardware has become so standardized and dull with x86 and ARM "cattle" boxes running Windows or Linux, there's hardly any pleasure or emotional attachment to the hardware anymore. I own a PiDP-11 but that doesn't cut it.
Very nice. Projects like this are why I have a couple working 386s at my disposal. It's a blast to play around with projects like this on original hardware.
I had a relative do exactly the same a while ago for a standalone program, which made me curious about such a choice.
In a nutshell: DOS can be seen as a lightweight runtime, it's reasonably secure (easy to isolate from the web), has low requirements, doesn't require updates, and the tools to build the program are small, free and reproducible (ex: Turbo C) so he can come back to it in a few years and be confident everything will build the same.
So he treats DOS as an autonomous, lightweight container with graphic capabilities. A bonus is that it can run on basically anything, with stellar efficiency if baremetal. The main disadvantage is that programs look dated.