All that's left now is SDL for UEFI, and then all our games can run in a pre-OS environment.
What's the latest with Intel's Management Engine / Minix that runs on every Intel chipset? Is that still a thing? Did they harden it? Or can you still get access?<p><a href="https://www.zdnet.com/article/minix-intels-hidden-in-chip-operating-system/" rel="nofollow">https://www.zdnet.com/article/minix-intels-hidden-in-chip-op...</a>
Well… UEFI is kind of modern DOS.
That... Shouldn’t be terribly difficult? Though I don’t believe UEFI has sound drivers (you’ll have problems writing one yourself because even frickin’ sound-codec chips have NDA-only datasheets these days), and the stupidest thing is that the “graphics output protocol” doesn’t indicate vsync so you can’t do tear-free blitting, which is literally worse than VGA.
Most support Intel HDA.<p>The problem is that people don't use onboard audio anymore (because its incredibly and audibly noisy). They use USB or Bluetooth.<p>Bluetooth absolutely isn't standardized and is a mess, and USB miiiiiiight be okay if you limit to a subset of EHCI and USB Audio Class 1.0 devices.<p>At this point, its easier to just use Linux and run your game as pid 1.
That honestly sounds amazing. Imagine booting into something like a grub menu that's just a list of classic games.
I basically had this setup back in the day. I don't really know how I ended up with it, I was 7 at the time and none of it was intentional - but my bootloader had two entries: I could boot into Windows 98, or I could boot into Worms.
It's a similar idea, but that's a DOS menu. At the point when the menu appears, MS-DOS 7.1 has already been loaded.
Probably your parents setting it up?<p>As far as I know, Worms is a normal DOS game, so the only way for that to happen should be a DOS install configured to just auto-start Worms on boot. Which makes sense as a way to keep a kid away from anything that could cause trouble.<p>I very vaguely recall that there used to be a very few PC games that worked as boot floppies and possibly didn't use DOS at all, but it was a rarity and Worms definitely wasn't one.
I bet it wasn't actually the bootloader but something with autoexec.bat - you could setup choices in it and windows was just one launch option.
No, I set it up. My parents were non-technical. I had a CD-ROM re-release of Worms for DOS from one gaming magazine or another. I guess the installer set it up somewhere somehow but I remember it wasn't easy to get it installed and there were further problems trying to launch it. It's possible the installer itself was a DOS program, not a Windows program.
I would guess a modern BIOS chip is as powerful as an NES, right?
You can do substantially more in UEFI than NES-level games. (See <a href="https://uefi.org/specs/UEFI/2.9_A/12_Protocols_Console_Support.html#graphics-output-protocol" rel="nofollow">https://uefi.org/specs/UEFI/2.9_A/12_Protocols_Console_Suppo...</a>)
What do you mean by "BIOS chip"? Like, the flash memory that stores the motherboard's firmware? I don't think that contains any processing elements.
Welcome to Amiga games, in many cases the floppy would contain the boot loader that would directly jump into the game.<p>At least on the Amiga 500 you would not go through the trouble to start Workbench, only to load the game, unless you were a lucky owner of an external hard drive.
This is an especially funny screenshot as DosBOX itself is built on SDL.
Perfect! I was just doing some Turbo C development inside DOSBox-X inside Debian GNU/Linux inside VMware Fusion inside macOS this morning.
Awesome. I wonder how this would work with a 386+ targeted MS-DOS executable from FreeBASIC, which supports binding to SDL.<p>[1] - <a href="https://github.com/freebasic/fbc" rel="nofollow">https://github.com/freebasic/fbc</a>
For a open source project like SDL is, for something like this, it's usually a matter of how invasive it is, and how likely the contributors seem to stick around and maintain it.<p>Different projects have different policies, and I don't know what SDLs is.<p>But they already have a lot of ports, so I trust they know what they're getting themselves into.
Awesome. Why? But awesome. There does not need to be a reason why
SDL getting back to its Loki roots
Wait, it didn’t already or am I confusing it with the VESA support on Linux?
Technically this already worked with HXDOS, which emulated DirectDraw well enough that SDL could use it.
> Input: ... gameport joystick via BIOS INT 15h with auto-calibration<p>Joystick calibration: what a blast from the past! Blast from the past I encountered recently...<p>Joysticks had to be "calibrated" and it was something you had to do for each game that supported joysticks. These would give back analog values and they'd depend on the phases of the moon or the room temperature or both. I'm not making this up: this was a serious pain point both for players and coders.<p>FWIW in that DOS game of mine from 1991 or so for which I still had the .ASM source code files (about 30 000 lines of assembly code, 15 000 of which were auto-generated code to do very fast sprites drawing in the VGA 320x200 "tweaked" mode) and which I managed, at long last, to get to compile again a few days ago thanks to UASM (and quite some LLM help), I found lines like these:<p><pre><code> ul_corner_ch:
db 63,"PUT YOUR JOYSTICK IN THE UPPER LEFT CORNER AND PRESS A BUTTON "
lr_corner_ch:
db 63,"PUT YOUR JOYSTICK IN THE LOWER RIGHT CORNER AND PRESS A BUTTON "
p1_choose:
dw 1 ;1 keyboard 2 joystick
p2_choose:
dw 0 ;0 none 1 keyboard 2 joystick
</code></pre>
And basically a 350 lines assembly file <i>only for joystick calibration</i>.<p>So you can understand that "auto-calibration" as in TFA is quite a selling point!
I'm more impressed by the fact they accepted it upstream, specially for an OS target that is long gone from the market and has virtually no users.<p>Usually upstream projects would reject such PRs under the reason they just increase maintenance cost with little to no benefit to the userbase.
Love it! Now, let's port it to CP/M (via GSX, maybe?)
Good - now we can play more DOS games again!
Well I guess Allegra was a bit old already /s
Uhm... excuse me? Why? Is there anyone even using DOS for anything serious these days?
Perhaps not serious, but I think people gravitate towards older systems these days because they are easier to conceptualize. It's not unrealistic for a single person to have a complete grasp of e.g. the C64 and it's programming environment. DOS is similarly constraint, but also easier for you to form a more or less complete mental model around.<p>Some people love computers and making them do weird stuff, older computers make certain tasks feel more manageable.
Most computers in Turkey come with FreeDOS preinstalled because there's a law that states all computers must be sold with an operating system. FreeDOS turns out to be the cheapest and easiest.<p>That's why you don't let people who have never touched a computer write tech laws. You get results like this.
The really weird case is where the computer isn't actually compatible with DOS, so they put in a locked-down Linux distro that emulates FreeDOS.
Those types of laws aren't all that bad.. they got us this: <a href="https://segaretro.org/Dottori_Kun" rel="nofollow">https://segaretro.org/Dottori_Kun</a>
I wish that was the case where I live. I'm looking for a new laptop and the mainstream ones <i>still</i> come with the Windows Tax.
Is there a reason they don't go with Ubuntu or something like that instead?
Linux drivers and certification is a whole lot of extra work and complexity compared to FreeDOS. Years ago, Nettops were sold with FreeDOS where the components didn't support Linux that well.
I guess they don't want to get support's call. DOS looks like firmware for non techies.
Who said anything about "serious"?<p>(FWIW: I suspect there are more than a few old industrial control systems and such out there that are still running DOS, just because of an "if it ain't broke, don't fix it" attitude)
My brother is in manufacturing. DOS is <i>everywhere</i>. Older things too (PDP-11? DG Nova? Seen both, semi-recently). Not just because "ain't broke, don't fix", but because when you have a cloth dying machine or brick forming machine you spent >US$5M for, that is often a bespoke install for your plant, you don't replace it because some guy who prolly slings Javascript all day sez "DOS is oooold, boomer".
These DOS machines for industrial control could probably be replaced by an Arduino or a far more reliable MCU, whereas running an actual legacy PC as a business-critical component in manufacturing has to be a bit of a nightmare by now. AI could probably do a good enough job of working out how the legacy DOS executables were intended to work.
Given the implications, I guess nobody is going to touch those setups to put an SDL-based program on them, though...
<i>Hacker</i> News
The real question is "why not?" :)
I think this PR is awesome, and I can totally see myself playing around with this at some point. Being able to create DOS executables of SDL projects is just ... cool!<p>But I do wonder about the practicality. This would, I presume (never done DOS development, never touched a memory extender) only run on 386+ CPUs, and maybe more importantly, probably require a newer CPU than that to run anything non-trivial at acceptable performance. So I wonder how many "real DOS machines" this can <i>practically</i> target.<p>Still, it is massively cool.
Because it's fun, at least for certain folks? Crazy, right?
It's a simple enough implementation that implicitly helps document how SDL is supposed to work (DOS being a well understood platform by now). Plenty of reasons to maintain it based on that alone.
There used to be stock exchanges running happily on DOS. Maybe there still are.
Worked at an exchange in 2007/2008 and... we had systems still running from the 80s. Mostly tape audit stuff.
Most use Linux now, and specifically RHEL. I did see some IBM z, but that was specifically for one old DB that handled oil pipeline stuff.
There's a lot of interesting projects and even innovation going on making new games for old PCs/consoles. James Lambert and Kaze are doing fantastic work in the N64 space as one example (watch their videos on Youtube)
SDL is written in C. So it can support it without too much trouble. And some people are compiling stuff to run on DOS. So it makes sense. And your objection doesn't hold any water.
<i>Uhm... excuse me? Why? Is there anyone even using DOS for anything serious these days?</i><p>Translation: "Stop liking things I don't like!"
I suppose it's an issue of ignorance; even IT veterans often don't know that DOS was, and still is, the driver of many highly specialized industry applications, or an OS running the software of individuals as well as small business owners around the world.
because you can