Can two programmers who are accustomed to making games for modern computers with gigabytes of RAM and high-color HD displays port one of their games to MS-DOS? Neither of us had any experience developing on such old hardware, but since working within artificially limited systems is something of a Zachtronics game design specialty, we felt compelled to try!
I enjoy these kinds of articles, thanks!
To this day I still wish I had a debugger that worked as well as borland turbo debugger for dos did. GDB is powerful, but I also find the interface makes debugging considerably harder than it needs to be and I haven’t found a front end I’m totally happy with. Eclipse is bloated and slow, I prefer something simple like DDD but then I usually have the constraint that I have to debug remotely under a console session and that’s when I wish I had something like turbo debugger for linux.
Anyone have suggestions?
They also did not consider Pascal or C++, which were actually being used a lot across Europe, with enough Assembly of course.
Regarding debugging, Visual Studio with Linux remote debugging support.
https://blogs.msdn.microsoft.com/vcblog/2018/01/10/debugging-an-embe…
https://blogs.msdn.microsoft.com/vcblog/2016/03/30/visual-c-for-linu…
Or if you can stomach Electron apps, Visual Studio Code
https://code.visualstudio.com/docs/languages/cpp
moondevil,
I only have VS2015 at the moment. That is a neat feature though, thanks for the info! I find visual studio to be quite bloated (it’s the reason I upgraded my laptop’s ram from 4GB to 8GB, but at least it runs much better now).
Since they target 386 anyway I would choose a combination of: DJGPP (GCC DOS port with reasonably modern C++ support), VESA graphics (“normal” chunky graphics) and a DOS extender (protected mode, 32-bit code, flat addressing).
From what I’m reading, they made it harder on purpose. It looks to me like they deliberately challenged themselves, just to see if they could do it. This wasn’t about the efficiency, but rather purely for the experience of programming old-school DOS.
Old school MS-DOS would be real mode in Assembly, using either MASM or TASM, with minimal calls to MS-DOS, focusing on BIOS only.
Edited 2018-03-21 19:05 UTC
The part where the developer says they’d never tried to develop for such old hardware is a bit telling. We are in an age now where new programmers coming out of college have never worked with less than 1GB of RAM or less than 10GB of disk space. In fact, they may never have encountered a smart phone or laptop with specs as low as these, let alone developed for them.
I remember rewritting video functions in Assembly during the 90s to make it run fast/light enough to work smoothly on the computers of the time. It was a pain, but it gave me an appreciation for both how much work the compiler was doing and for how to consider my approach. It got me thinking about bottlenecks (ie. Is this slow because of CPU, disk, or memory?) and how to best address them.
While I like that high-level languages mean we can often call “someClass.someOtherClass.doThings()” to accomplish tasks, it also gives me pause when I consider some programmers have never had to think of how to do these things in a more efficient way.
Edited 2018-03-21 15:30 UTC
Which is why I find systems like ESP32 so interesting.
It is like programming a PCW 1512, beefed up with a dual core and network capabilities.
Go, Rust, C, C++, and of course pure assembly all offer functionality for working at that level. It’s just that much less of the programming done today requires that sort of bit fiddling and register massaging anymore.
They talk about copying the static back buffer (“screen 2”) to the screen being drawn, but don’t tell how they did it. Using the right set-up, you can copy four pixels at once with a single movsb (and iirc eight with a movsw), I wonder if they picked that up from Abrash. Also funny they couldn’t get movsw to work (probably an alignment issue), and the assumption movsd can’t be used (a simple “db 66h” doing the trick). But I like their effort
.
jal_,
I commend them for trying & learning. They could have tried NASM to get 32bit instructions, which was (and still is) a popular assembler. You are also right that we had to prepend instruction modifiers in older assemblers.
We could be great mentors on a project like this, it’s just so rare to have people interested in this old tech
Edited 2018-03-21 17:14 UTC
Yeah it is rare today to have people interested on learn about how things work at lower levels and how to code efficiently. Unluckily, we have an ocean of new programmers that behave like javascript is the “be all, end all” language to develop some otherwise nice projects.
I’d love to for the purposes of writing utilities for my retro-computing environments… I just have enough problems with scheduling that I can’t commit any new hobby activities.
Any recommendations for books I could track down used copies of so they can sit on my shelf drawing my attention whenever a spare moment crops up?
Edited 2018-03-22 05:06 UTC
Yes, anything at all by Michael Abrash.
https://en.wikipedia.org/wiki/Michael_Abrash
ssokolow,
If only you had asked last year… I threw out two shelves worth of some good technical books (including abrash’s graphics bible). Some of them I refereed to so often that I would take notes down in the margins. Sadly I couldn’t even give them away.
I gotta say, it’s funny how one gets sentimental about legacy technical material, but the practicality of keeping them diminishes by the year. These days if I have questions I search online or use websites like https://www.osdev.org/
I don’t know if there’s any way of getting advanced notice, but one day I went to the library and by sheer coincidence they were getting rid of lots of obsolete technology books.
Thanks.
(And sorry for only replying just as comments are about to close. It’s been a busy few days.)
Indeed, it’s fun to see newbies in the old tech
http://atariage.com/forums/topic/276082-stunt-car-racer/
Check that out for a port!