How do I program in DOS(Disk-Operating-System)directly?

You need a 16-bit compiler, like Turbo C++. You also need a 32-bit windows OS or emulator.

Thanks! I'll make sure to get Turbo C++.

But ... I have a 64-bit version of Windows 7.

What do you mean by an emulator of 32-bits?

There are emulators for Windows 7 32-bit? O.o

Since Vista, IIRC, 16-bit support has been removed from Windows 64-bit editions. You'll need a version that supports WoW16 still (IIRC 32-bit editions of Windows still have this) or a VM that runs a true 16-bit OS.


If you want to really write 16-bit code, that's it anyways; if you just want a game that looks retro but still runs in 32/64-bit modes, there's easier ways to do that. If you just want to write really low-level stuff on a limited architecture, look into the Arduino or something similar.

What if I want to write 2, 4, and 8-bit code for 8-bit games?

Could I download an 8 or 16-bit OS, and boot a separate partition of the hard drive where I store the OS, and, when capable, program from that OS in the lower bit system support?

Like Windows 95 for example. Are there any downloads of it available?

And does coding style strictly change within different bits?

Because I notice that in DOS you have to add a whole bunch of code that is specific to DOS's 16-bit system.

I fear you have a few misconceptions. DOS didn't work in a "1 bit per pixel" style. It worked in a "this vendor does it this way with 4 bit-planes per pixel addressed at such and such or accessed by way of these interrupts, that vendor does it that way, and I need to write about 7 different 'drivers' for the most popular EGA/CGA/MCGA/VGA cards if I want to expose my game to the widest possible audience. And I have to hand-code them in assembly. I also have to be careful, because squeezing the best bare-metal performance out of these vendor-specific cards can be a pain in the ass." The VGA era of cards started to bring some sanity to the whole mess, but it wasn't really until the Windows era that developers could start to count on a consistent interface with the video drivers and not worry about coding for several different popular vendors.

These days, it is hard to find retro PC platforms to develop upon. Your best bet is to find a VM or emulator. You can dig around with old projects like DJGPP, which was once upon a time a pretty active project in the 16-bit era. The good thing about emulators is that you don't have to worry about the vendor-specific crap. Just code to the emulator.

As far as my personal opinion, I'm glad those days are past. GLAD, I say. I have 0 nostalgia for them. I still remember my very first graphical game written in DOS using the A86 assembler on an old 8088. 32x24 tiles at 16x16 pixels per tile on an EGA, and you could literally eat two bites of your PB&J while waiting for the screen to redraw because I knew exactly dick about the hardware and optimization. My personal opinion is to forget DOS assembly coding and emulators, and just code a retro-looking game using these so, so lovely modern tools that we have.

But your suggestions are a perfect example as to why I was struck to write this post:

http://www.gamedev.n...-say-otherwise/

I disagree with you, and that post above will open your mind.

A few wrong ideas up-front.

Windows 7 doesn't "have DOS"; it has a command-prompt, but that command-prompt is a native Windows application. The last DOS-based version of Windows was Windows Me; Windows 2000, XP, Vista and 7 are not DOS-based.

Windows 7 is not 16-bit. The last 16-bit version of Windows was 3.x in the early 90s; Windows 95, 98 and Me were hybrid 16/32, all NT-class versions of Windows (which includes 2000, XP, Vista and 7) are fully native 32-bit or 64-bit.

Under any of these operating systems you cannot access the hardware directly. It's forbidden, you must go through an API.

JTippets is correct - the old days were horrible. No multitasking, no device drivers, no protected memory, you could (and often did) write a program that gleefully corrupted anything else on your PC. Back in the late 80s/early 90s writing "the C program that rebooted your computer" was a rite of passage - and that was the least worst thing you could do.

No standardization - you had to write a separate renderer, separate sound code, separate input code, etc for each variation of hardware that could exist. No guarantee that your program could work on any other machine.

The answer to your question is: "you don't". Those days are gone, and for very good reasons.