Well I have fond memories of programming in Turbo Pascal for DOS. As there is not much multimedia in there by default you kind a look for graphics+soundblaster libraries and maybe end up writing your own set of libraries. Like writing a procedure to read bmp files, then pcx files. too much work but somehow fun.

There used to be something like SWAG if I remember correctly.
Maybe this is it: http://www.bsdg.org/swag/
I still have some of the more interesting code snippets stored somewhere.

Do think beforehand about how many memory you are gonna use, e.g. real-mode vs. protected-mode programming. Real-mode is the default but when you want to use bigger/truecolor bitmaps it easily falls short.

I reckon the DOS Allegro libraries are the way to go. No need to re-invent the wheel.

Well, there's a couple ways you can go about this, and it's important to figure out right from the start if you want to work within the 640K limit, or go for something that uses more.

Working under the 640K limit, you're probably going to end up doing much of the hard work yourself, such as programming graphics, sound and input I/O, but resources on doing this aren't too difficult to find. Just type "DOS programming" into Google or any other search engine and you'll get a whole bunch of stuff. (Though anything that covers "batch files" won't be what you're looking for.) Making stuff that fits within the 640K limit isn't too tricky, but you'll be very limited in terms of how many graphics and sounds you can load up in one moment, not to mention if you have game maps, the size of each map can't be too large.

The other option is to use a modern SDK, such as the Allegro Game Programming Libraries, which work in DOS and can be utilized with free programming utilities such as DJGPP, which is a C/C++ compiler. This will do all the memory handling, graphics handling, I/O, etc., so that you don't have to, since writing these aspects from scratch and making sure they work properly can be time consuming. The downside to this approach is that Allegro is only designed to utilize 256 colour graphics modes, so you won't really be able to make an authentic CGA or EGA game with it. I mean, you could bypass the graphics handling and write your own routines, but then Allegro still compiles to protected-mode, and I don't think there's a single CGA or EGA game out there that is.

As for the language to use, C/C++ is your best bet. DOS programs can be written with only a handful of lines in C/C++. Turbo Pascal is OK... but the TP7 libraries have some issues running on fast systems due to an overflow error for timing stuff. Tyrian is also one of the few games to utilize a 16-bit DOS extender so it's not really the best example for learning DOS programming because its code will be very different from normal.

One benefit if you go with Allegro is you can join the Allegro.cc programming forums which are very active and the people there can help you get yourself going with Allegro itself. There's also a wrapper for Allegro to make it work with Pascal, but I know very little about it so I don't know if it will be useful for what you're doing.

Gemini000 wrote:

Tyrian is also one of the few games to utilize a 16-bit DOS extender

Really? How does that work?

286 has some protected mode features.

I think even the Crusader action games use a 16-bit extender because they are built on an old Ultima engine. That was of course rather strange for '95-'96. It comes down to what tools they used to develop the game and apparently that was Borland and Pharlap 16-bit.

http://groups.google.com/group/comp.sys.ibm.p … en&dmode=source

Turbo C++ is a good start

Thanks everyone 😀

gerwin wrote:

Do think beforehand about how many memory you are gonna use, e.g. real-mode vs. protected-mode programming. Real-mode is the default but when you want to use bigger/truecolor bitmaps it easily falls short.

Yeah I'd prefer to dive into protected-mode code because my goal is to ultimately make a game that utilizes 256 color/SoundBlaster/AdLib. But real-mode might too be fun to figure out at some point.

Gemini000 wrote:

The other option is to use a modern SDK, such as the Allegro Game Programming Libraries, which work in DOS and can be utilized with free programming utilities such as DJGPP, which is a C/C++ compiler.

That sounds like the best option for now. The idea of using TurboPascal was fun but a library is really what I need. I'll run a search for this library and compiler and see if I can give it a try.

Also, as for Tyrian, as far as I know the original TurboPascal source isn't even available. The OpenTyrian project is a rewrite of that code, but they weren't allowed to publish the original.

Gemini000 wrote:

One benefit if you go with Allegro is you can join the Allegro.cc programming forums which are very active and the people there can help you get yourself going with Allegro itself.

Sounds like exactly the kind of place I needed. Hope they still support people working in DOS.

Jorpho wrote:

Gemini000 wrote:

Tyrian is also one of the few games to utilize a 16-bit DOS extender

Really? How does that work?

Memory addresses in DOS have always technically been 32-bit, in that you have both a segment address and then the address within that segment, both of which were 16-bit values. All an "extender" does really is give access to memory beyond the 640 KB limit, and I think virtually every extender out there (except maybe the one in Zone 66, not 100% certain) utilizes protected mode processing, as opposed to real mode, which helps to protect other applications in memory from being accessed improperly, among other things.

You also had a variety of different kinds of pointers for dealing with these situations: Near, Far and Huge. Near and Far pointers in 16-bit programming are both limited to 64 KB of address space, but near pointers reference the current segment space while far pointers need to have a segment offset set as well and thus take more processing time to handle. Huge pointers were special in that they could wrap over their 64 KB boundaries, but this required even more processing time than Far pointers.

Once you go from 16-bit to 32-bit programming, it becomes much easier to set up pointers and place stuff in memory because the pointer size can now handle 4 GB of address space as opposed to 64 KB.

Believe it or not, QBASIC is another option. These days, there are many libraries that can make QB 4.5 fly - Future.Library for example can do graphics modes of 800x600 with millions of colours. Check out http://www.petesqbsite.com/downloads/libraries.shtml

Also it's worth mentioning that my goal is to make something that actually works decently on a PC from that era (let's say first generation Pentium ~60MHz). I'm not sure if something like Future.Library is fit for that, but it looks neat anyhow and I suppose I should check it out later.

I actually still use QuickBASIC for a few things, mostly just to quickly check some complex math calculations when I'm designing a game. Recently, for the game I'm currently working on outside of work on ADG, I had to balance out the average amount of money you could earn based on the difficulty of a level, versus how deep into the difficulty ratio I wanted the player to be by the time you reached the final moments of the game, so I used QB to see all my numbers in play and to figure out an actual equation I could use.

It's important to note that QBASIC is not the same thing as QuickBASIC, with the two biggest differences being that QuickBASIC can compile standalone executable files and can also handle larger program sizes.

For someone with little programming experience, QBASIC/QuickBASIC is a good place to start, but for someone who already knows how to program, C/C++ is simply faster, more powerful, and has more options for where to go with development.

Gemini000: Is Powerbasic not the compiler of one of the two basic versions, you have mentioned ? or am I wrong about that , cause I seem to remember a friend mentioning to me, that Powerbasic could compile one of the two.

Two questions:

One, is there an IRC channel for discussing DJGPP? I didn't find it on Freenode anyway.

Also, since I'm going to be compiling DOS programs, I downloaded VirtualBox, but which DOS version should I run in it?

WolverineDK wrote:

Gemini000: Is Powerbasic not the compiler of one of the two basic versions, you have mentioned ? or am I wrong about that , cause I seem to remember a friend mentioning to me, that Powerbasic could compile one of the two.

PowerBASIC is just another of the many versions of BASIC that exist for both DOS and Windows... and it costs $50. From what I understand though, it's fairly capable of handling QBASIC/QuickBASIC code.

dada wrote:

is there an IRC channel for discussing DJGPP? I didn't find it on Freenode anyway.

I don't know, but one thing I forgot to mention is that DJGPP is just the compiler and such for the most part. If you want an IDE as well, a common one to use with it is called RHIDE.

dada wrote:

Also, since I'm going to be compiling DOS programs, I downloaded VirtualBox, but which DOS version should I run in it?

6.2 or 6.22 are your best bets since you're making modern, protected-mode software. You could always use DOSBox as well. The only reason you would want to run an earlier version is if you're trying to make a game that doesn't run in protected mode and you want to be able to play it on very old computers.

Gemini000 wrote:

dada wrote:

is there an IRC channel for discussing DJGPP? I didn't find it on Freenode anyway.

I don't know, but one thing I forgot to mention is that DJGPP is just the compiler and such for the most part. If you want an IDE as well, a common one to use with it is called RHIDE.

Remember that the actual compiler is GCC, so that's what you need to be looking for; DJGPP is the name given to the packaged up collection of the GCC toolchain (the GNU compiler, assembler, linker, libraries and header files etc) for Dos.

Gemini000 wrote:

dada wrote:

Also, since I'm going to be compiling DOS programs, I downloaded VirtualBox, but which DOS version should I run in it?

6.2 or 6.22 are your best bets since you're making modern, protected-mode software. You could always use DOSBox as well. The only reason you would want to run an earlier version is if you're trying to make a game that doesn't run in protected mode and you want to be able to play it on very old computers.

I wouldn't reccomend using Dosbox for compiling - the performance metrics for that compared to a more general purpose VM like virtualbox, xen or vmware are abysmal. Though conversely none of those general purpose vm's are any good at running games, of course.

I spent a couple of weekends about 6 months ago tinkering with Allegro to build a Dos game inventory/menu/launcher (I lost in interest in it eventually) and compiling just a few files of C source code within Dosbox on my Q6600 Linux workstation compared to the Pentium Pro 200 Freedos box next to it was several times slower.

I use Turbo C++ myself which apparently comes with its own graphics API which is nice. I also have DJGPP but you have to have CWSDPMI.EXE in the same folder every time you run the resulting compiled binary. At least, that's how it was from my experience.

I also wrote my own game launcher for DOS. Still have it. I keep wanting to expand on it and fine-tune some features but I haven't been back to it in a while. Works like a charm for what it is, though. Right now everything is hard-coded, but I'd like to be able to write a config file system for it so that I can add games a lot more easily then coding it straight in and recompiling it all the time.

If you can find one try one of the "Tricks of the Game Programming Gurus" books.....

Yes, I am aware I am digging up a very old thread. @admins: If I shouldn't have I will be happy to hear about it and to be more careful about it next tme. Anyway for anyone who still cares about this topic:

I have programmed with QuickBASIC for a long time, and I only recently got my hands on a copy of PowerBASIC 3.5. From what I can tell PowerBASIC is more efficient at executing code fast than QuickBASIC (GWBasic is even worse). VBDos is okay, but unless you're going to write a Windows-like program using a TUI and running under DOS it seems a bit sluggish and bulky. PowerBASIC also appears to have better support for low-level memory access and supports in-line assembly code.

Also I can provide some code that demonstrates how to use a Sound Blaster in BASIC, how to do SVGA graphics or how to use the mouse.

Before I forget:
One reason I sometimes use VBDos instead of QuickBASIC/QBasic is because it allows me to test code using the "Option Explicit" statement. A very useful addition to BASIC that helps prevent typo's and errors in using the proper scope for a variable and parameters not being passed to a procedure. PowerBASIC has "$DIM ALL" for that btw., which I appreciate.

Also few other useful DOS utilities,
-There is HelpPC by David Jurgen, a very useful reference tool for looking up interrupts, memory addresses, I/O ports, assembly instruction info, etc.
-Norton Commander - useful for viewing (especially raw binary) and managing files.
-The Editor provided with 32-bit Windows is good for the basic raw editing and viewing of binary files (and plain-text including source code).
-I think NASM is a pretty good assembler. Especially because it compiles flat binaries by default. Very useful for writing snippets of asm code for your BASIC programs or to write a simple utility.

I may add some stuff later when I think of it. Bye.