If anyone here is interested, a DOS game jam was announced recently for a streaming event called DOSember. https://itch.io/jam/dosember-game-jam Starts in a couple of weeks and lasts for three months.
keepamovin 8 hours ago [-]
DOS is an interesting platform because it can run on old hardware, and then basically anything else by way of emulation (such as in browsers) or via DOSBox.
If networking can be plumbed up, it's probably a legitimate and fun application platform for some uses that's worthy of investing time building on either for fun or for something real.
lelanthran 4 hours ago [-]
> If networking can be plumbed up, it's probably a legitimate and fun application platform for some uses that's worthy of investing time building on either for fun or for something real.
It's probably well suited to being a game console platform, too.
keepamovin 1 hours ago [-]
Heh, you might be onto something there :)
I've been playing around with raylib/raygui for cross-platform game/app development. It would be cool if it could target DOS. It probably could, but it sounds way beyond my current knowledge.
lelanthran 17 minutes ago [-]
Yeah, I think the hard part would be graphics libraries for anything 3D.
I've always had a bucket-list item along the lines of "constructing basic game playing graphics primitives from scratch using the SVGA address offset for output".
MS-DOS (and games for it) ran on 486s, at the end. Writing MS-DOS games for a computer running many hundreds/thousands of times faster would probably allow for many more different types of approaches that could not be done on slow machines.
3036e4 4 hours ago [-]
With some emulators (at least DOSBox-X) you can enable modern graphics modes that show up in SVGA in the emulated DOS and can be supported by DOS software just like any other modes. Anyone making DOS software today that isn't going explicitly for a retro look can try to detect and support a few modes like 1920x1080 and only fall back to more common old modes when necessary.
keepamovin 1 hours ago [-]
Yeah that's really cool how flexible the graphics are.
kev009 1 hours ago [-]
I grew up on 68k Macs so DOS was never something I thought much about aside from the occasional boot disk to run some firmware procedure later on when later Windows was well established.
Then later from a retrocomputing standpoint, I've come to see it is pretty fascinating:
1) The sheer volume of commercial software.. which is readily available on winworld, vetusware, and archive.org. A lot of it with sometimes awesome character-mode UIs (Borland's early IDEs are really spectacular, Lotus 1-2-3, and WordPerfect are still taken seriously by some users).
2) The memory model is quixotic and an interesting homage to the chaotic evolution of x86 that most later operating systems elide by requiring a 386. The 286 and 386 have drastically different protection schemes. EMS and XMS. The eventual DOS extenders and standards like VCPI, DPMI. It's honestly a mess but somehow interesting to see how people solved difficult problems.
zozbot234 15 minutes ago [-]
The Free Pascal software distribution includes a FLOSS look-alike of Borland's character-mode IDE for Pascal. If you can track down RHIDE, that's a similar look-alike IDE that runs in MS-DOS (it does require 386+ since it uses a DOS extender) and compiles C/C++ using gcc. (One version of it is distributed as part of the FreeDOS "development" packages.) It would be nice to recreate a broadly similar look and featureset starting from a modern text-mode editor such as the newly released MS-EDIT, aiming for modern IDE infrastructure like LSP and DAP. Such a project may find quite some use for, e.g. remote system administration tasks using ssh.
Grom_PE 1 hours ago [-]
Note that DOS development tools aren't strictly necessary to make DOS software,
as with help of HX DOS Extender [0], one may use any tooling that lets you produce Win32 PE exe files, of course, preferably with inline assembler to access hardware directly.
As someone old enough to have live through it, I always found TASM much better than MASM, in terms of tooling.
In both cases, still much better than traditional UNIX assemblers, desiged to massage C's output as another build stage, than to actually code by hand.
Anyway thanks for the heads up.
snvzz 6 hours ago [-]
For anything written from scratch, I would recommend fasm or nasm.
I prefer the latter, because the documentation is better and there's a way to specify target cpu (e.g. 8086) and get errors when instructions aren't compliant.
anta40 37 minutes ago [-]
Ah yes I forgot to mention both tools are also still under active development.
I mostly use JWASM to compile samples from old MASM books/tutorials.
bananaboy 4 hours ago [-]
I agree - nasm is excellent. I've used it for pretty much all my MS-DOS projects (games and demos).
For development it is convenient that PC-BASIC exists, that is a pure Python implementation of GW-BASIC that has its own partial 1999s PC emulator built in.
There is no source code, but at least the license makes it free to use and redistribute. The C compiler seems very close to supporting ANSI C89.
pwdisswordfishz 9 hours ago [-]
Not mentioned is the https://pcjs.org/ site which purports to let you emulate various machines in your browser, select from different disk images, and overall seems full-featured, though it is confusing and presents some difficulty when trying getting it to work on some configuration besides the pre-baked ones that you can come across.
Seems a bit obsessed with open source when abandonware like Borland C++ 3.1 and Pascal 7.0 are amazing.
Also, missing the very important, closer to primary sources, physical dead tree resources that are needed as reference to program things.
- Black Book of Graphics Programming (Special Edition) (now FOSS)
- Programmer's Guide To The EGA, VGA, And Super VGA Cards (3rd Edition)
- PC-Intern (where I learned how Central Point, Norton, and later FreeBSD made "GUI" with sub-character graphical pointers in text mode through custom fonts)
- Undocumented PC
- Undocumented DOS
- PC Interrupts (and) Uninterrupted Interrupts (Ralf Brown)
- Microsoft MS-DOS Programmer's Reference
- The Programmer's PC Sourcebook: Reference Tables for IBM PCs and Compatibles, PS/2 Systems, EISA-based Systems, MS-DOS Operating System Through Version 5
- (various hardware books by MindShare)
- Also useful would be real BIOS dumps and (dis)assembly, and MS-DOS source
- Emulators are no substitute for the real thing because the problem is that no emulator (commercial or otherwise) is faithful to the quirks, capabilities, and limitations of real hardware (in system, protected mode debuggers/profilers sure are nice though compared to triggering lockup, spontaneous reboot, or a beeping deadlock). If anyone remembers Bochs, its floppy behavior definitely doesn't act or look anything like a real FDC. (I submitted some patches for it many moons ago in college.)
(Yep, I own a "braindead" 286, 386DX, 486DX-100, Am5, and P5, P2, P Pro, and P4.)
Because if something can't work on real hardware and original OSes, then it's probably make believe. Prefer to make honest, real things wherever feasible.
https://www.phatcode.net/articles.php?id=247
If networking can be plumbed up, it's probably a legitimate and fun application platform for some uses that's worthy of investing time building on either for fun or for something real.
It's probably well suited to being a game console platform, too.
I've been playing around with raylib/raygui for cross-platform game/app development. It would be cool if it could target DOS. It probably could, but it sounds way beyond my current knowledge.
I've always had a bucket-list item along the lines of "constructing basic game playing graphics primitives from scratch using the SVGA address offset for output".
MS-DOS (and games for it) ran on 486s, at the end. Writing MS-DOS games for a computer running many hundreds/thousands of times faster would probably allow for many more different types of approaches that could not be done on slow machines.
Then later from a retrocomputing standpoint, I've come to see it is pretty fascinating:
1) The sheer volume of commercial software.. which is readily available on winworld, vetusware, and archive.org. A lot of it with sometimes awesome character-mode UIs (Borland's early IDEs are really spectacular, Lotus 1-2-3, and WordPerfect are still taken seriously by some users).
2) The memory model is quixotic and an interesting homage to the chaotic evolution of x86 that most later operating systems elide by requiring a 386. The 286 and 386 have drastically different protection schemes. EMS and XMS. The eventual DOS extenders and standards like VCPI, DPMI. It's honestly a mess but somehow interesting to see how people solved difficult problems.
[0] https://github.com/Baron-von-Riedesel/HX
It's a fork of OpenWatcom assembler.
In both cases, still much better than traditional UNIX assemblers, desiged to massage C's output as another build stage, than to actually code by hand.
Anyway thanks for the heads up.
I prefer the latter, because the documentation is better and there's a way to specify target cpu (e.g. 8086) and get errors when instructions aren't compliant.
https://codeberg.org/tkchia/GW-BASIC
For development it is convenient that PC-BASIC exists, that is a pure Python implementation of GW-BASIC that has its own partial 1999s PC emulator built in.
http://robhagemans.github.io/pcbasic/
I didn’t know there was an open source version of the Watcom compilers and a 16-bit library to support them.
There is no source code, but at least the license makes it free to use and redistribute. The C compiler seems very close to supporting ANSI C89.
8-bit Rust would be even better.
Also, missing the very important, closer to primary sources, physical dead tree resources that are needed as reference to program things.
- Black Book of Graphics Programming (Special Edition) (now FOSS)
- Programmer's Guide To The EGA, VGA, And Super VGA Cards (3rd Edition)
- PC-Intern (where I learned how Central Point, Norton, and later FreeBSD made "GUI" with sub-character graphical pointers in text mode through custom fonts)
- Undocumented PC
- Undocumented DOS
- PC Interrupts (and) Uninterrupted Interrupts (Ralf Brown)
- Microsoft MS-DOS Programmer's Reference
- The Programmer's PC Sourcebook: Reference Tables for IBM PCs and Compatibles, PS/2 Systems, EISA-based Systems, MS-DOS Operating System Through Version 5
- (various hardware books by MindShare)
- Also useful would be real BIOS dumps and (dis)assembly, and MS-DOS source
- Emulators are no substitute for the real thing because the problem is that no emulator (commercial or otherwise) is faithful to the quirks, capabilities, and limitations of real hardware (in system, protected mode debuggers/profilers sure are nice though compared to triggering lockup, spontaneous reboot, or a beeping deadlock). If anyone remembers Bochs, its floppy behavior definitely doesn't act or look anything like a real FDC. (I submitted some patches for it many moons ago in college.)
(Yep, I own a "braindead" 286, 386DX, 486DX-100, Am5, and P5, P2, P Pro, and P4.)
Because if something can't work on real hardware and original OSes, then it's probably make believe. Prefer to make honest, real things wherever feasible.