Hi,
Post by GiraffeHi! I apologize, it only just occurred to me I never replied
to your very detailed post. Thanks a lot for sharing your thoughts!
It's okay. I'm no engineer, just an amateur. Still, I try.
Post by GiraffeI've made some progress with my retro rig in the meantime.
I asked my mom if she still has that AMD 386DX-40 system
at work I remember from childhood, and turns out she did,
and it's already been written off the inventory so I just
came and grabbed it. This PC has a sentimental value to
me since it's the very first computer I used as a kid.
I know nothing about cpu architecture nor design. But how
much RAM does it have? I presume it has no cpu cache at
all (neither external nor internal). Technically, slow
graphics card could also be a bottleneck, but you're
probably worrying more about RAM and slow disk. (Use
a RAM disk ... if you can afford the waste.)
I don't really recommend self-hosted builds, but I
did use DJGPP (C only) back in 1997 on a 486.
Actually, you can rebuild old 2.7.2.3 in pure DOS.
I think it took ten minutes on my Pentium 166.
I also had a one-floppy DJGPP install I made in 2012,
but it was "newer" GCC 2.95.3 + BinUtils 2.16.1 (and
old DJGPP 2.03p2), compressed with .7z. So it fits
on a 3.5" 1.44 MB floppy, but ... I already know
it's much slower than 2.7.2.x on old machines.
I know you don't care, but older versions really
are preferred. (C++ support was much worse, though.)
Then again, you might honestly be better off using
Forth, QBASIC, Turbo Pascal, assembly, AWK, REXX,
or who knows what else. Cross-compiling is fine,
but I'm just thinking out loud here!
Post by GiraffeI've learned a bit about DOS graphics modes and written
a simple test, and I continued having great success with
DJGPP throughout my first experiences. Everything just works!
Allegro is what I would recommend (although I never utilized
that much either). Granted, it doesn't do literally everything,
but it's still good. Of course, there are other things.
mGRX was just updated (also for DJGPP) and allegedly has an
optional GUI nowadays.
* http://na.mirror.garr.it/mirrors/djgpp/current/v2tk/allegro/
* https://www.ibiblio.org/pub/micro/pc-stuff/freedos/files/devel/libs/allegro/
It's been a few years since I played any Doom ports, even with FreeBoom,
but you can try "updated" MBF. (Almost all Doom ports for DOS used
DJGPP and Allegro.)
* https://www.vogons.org/viewtopic.php?f=24&t=40857
Just in case that helps inspire you, graphically, for DOS. (It's
not C++, but obviously we never got a port of Doom 3! One guy did
back-port Hexen 2, though [Quake 1-based], but that's also only C.)
Post by GiraffeAs for C++ vs. other programming languages. For me personally,
C++ is the language I love the most and know the best so it only
makes sense that I would choose it whenever possible.
Use what you know. Use what works best. Use whatever's reasonable.
Post by GiraffeBut modern C++ has some interesting features that other languages
simply can't offer.
To co-opt an old saying: "The programming language graveyard is
full of features that nobody could live without!"
No offense, seriously, but saying "C++ is my favorite" and then
*only* preferring C++17 means that C++ isn't really your favorite.
It means your favorite is some kind of non-existent, future
version. Again, don't take this the wrong way, but if you can't
appreciate C++98, you probably are barking up the wrong tree.
(I don't expect much sympathy for pre-standard versions. Even
I bought a pre-standard [1995, DOS-era] book in 1998 but only
half read it and never truly learned it. I still have my copy
of Turbo C++ 1.01, but it's AT&T 2.0, pre-exceptions,
pre-standard, quite old. Still, I'm sure it's good for what
it supports.)
Post by GiraffeFeatures that let you write high-level, abstract,
easy to understand and maintain source code that compiles
to very minimal binary code with no overhead.
Nothing's smaller than assembly. Of course, Turbo Pascal 5.5
has a smartlinker, unlike TCPP101. Even DJGPP only partially??
(barely, experimentally) has support for -fdata-sections
-ffunction-sections -Wl,--gc-sections or whatever. It seemed to
work (barely), but I wouldn't rely on it! FPC is better in that
regard.
DJGPP was never meant for small size, so most people never cared.
CWSDPMI does swap to hard disk, if extra RAM needed, but obviously
that's quite slow and should be mostly avoided.
I also still sympathize with interpreters. Hey, I'm no genius,
but AWK still seems pretty useful. So does Sed, even! You
don't necessarily need raw, compiled, binary code for everything.
(We have an older Python 2.4.2 port for DJGPP, too. And Ruby 1.8.4,
but anything after 1.8.7 won't build easily.)
Post by GiraffeJason Turner is my favorite C++ person right now, and he did
an incredible talk 3 years ago that really highlights what
makes C++ great for computed of limited power. I can't recommend
this talk highly enough and I urge anyone with at least basic
knowledge of C++ to watch it. It's a very relaxed talk that I'm
sure will be entertaining even for non-C++ programmers.
I believe you, and I definitely believe that C++ has many virtues.
People love it, and clearly it's expressive. Still, I've not
really tried (yet). I enjoy videos like this sometimes, so
maybe I'll watch it. But I still have little interest in C++17.
(Given enough spare energy, I'm willing to learn anything and
everything, but so far, nope. I'm mostly content with Pascal,
Oberon, etc.)
Post by GiraffeA Simple Commodore 64 Game in C++17"
http://youtu.be/zBkNBP00wJE
The Paku Paku dude did his C64 version in C although he prefers
Pascal. The DOS version was TP7 with tons of inline asm (mostly
to keep RAM down since he wanted to work on literally all IBM
PCs, even the original.)
Post by GiraffeAs for my personal journey into programming for DOS,
I have a couple ideas for a few simple programs that will
be fun to implement for learning purposes, but I no longer
find it enjoyable writing code in a generic text editor and
invoking the compiler manually. I want to, and to some extent
need to set up a more or less proper IDE to use DJGPP, but so
far it proves more problematic than I expected it to be
(and really, than it should be).
GNU Emacs seems like an obvious choice (although I haven't
used it in years). "M-x compile" should work.
Post by GiraffeVisual Studio Code with the C++ should be able to do this
easily, but I've found that the documentation is lacking,
and pretty much nothing works as soon as you try to tie it
to your own non-standard compiler.
Code::Blocks, maybe?? I dunno, never used many IDEs. Something
like JED would probably also work. Oh, OpenWatcom has a simple
(Windows) IDE, too. But ....
Post by GiraffeThen I looked at Qt Creator, it has bare metal support and
should also be able to work with any C++ compiler, but the
setup procedure also has a few not-so-obvious quirks, and
it looks like there's no choice but to use CMake build system.
There is only one thing I can say about CMake: "Ugh."
Modules will helps C++ a lot. Honestly, I hope it works out
because Makefiles are too brittle. (However, even some Modula-2
and Oberon compilers often made you do it manually, which is
unnecessarily frustrating.) Then again, if you just "keep it
simple", you won't have that many problems. Easier said than
done! Don't let yourself overly complicate everything!
Post by GiraffeIt really saddens me that I got all the difficult things
working quickly, but lost A LOT of time on the IDE - and
still didn't get to work yet. It's not strictly required,
but it would really make all the further programming that
much simpler and more convenient...
Ask on news://comp.os.msdos.djgpp for advice. But I halfway
imagine they'll suggest GNU Emacs or VIM.
BTW, I sympathize with you wisely using an 8-core machine
for builds. Saving time is good. However, for small projects,
it's really not *that* bad to build in raw DOS. (Use a RAM
disk, software cache, enable Ultra DMA ... works for me!)
Feel free to get on any of the FreeDOS mailing lists (or
similar forums, e.g. BTTR). Granted, most people there
don't prefer C++, but they are quite savvy. I feel like
you could have fun benchmarking some stuff on that 386.
But who knows what your ultimate future plans are.
Oh, before I forget, I have no idea what is optimal for 386.
I read once that 386 prefers smallest code, but 486 shuns
that (e.g. string instructions) in favor of more RISC-y
code (plus is *very* sensitive to alignment). Being AMD
might also affect things. A 486 is twice as fast as a
386 at the same clock speed. Maybe OpenWatcom -3 helps,
but I don't know. (Higher than that is only "tuning".)
Yeah, I'm not sure if most compilers really optimize
well for a literal 386.
Anyways, good luck!