Stuck on something and can't figure it out? Need someone to test your game? Scream into the void and hope someone screams back. At the very least it might be cathartic.
i’ve found plenty of information on the technical details of old ibm pcs, but i can’t find much info for working with DOS itself other than interrupt lists. does anyone know good sources of information on this? the kinds of things i’m wondering are:
if you already know the answers to any of these specific questions those would also be helpful by themselves.
I can't definitely answer all of these questions, but can offer some clarification to most of them:
First, when DOS is booted from floppy, the kernel will remain in RAM, but the command shell will be unloaded when you launch a program to free up some memory. When your program exits, it will ask you to insert the dos floppy again so it can load COMMAND.COM back into memory and launch the command shell.
Any CRTC tweaking you do will be undone by a call to the int 10h set video mode function, which should restore you to a known good state. Usually this will be setting mode 3 (80x25 text mode) before exiting your program. The primary interrupt controller by default will be configured with all interrupts masked off except for the PIT, the keyboard, and the secondary PIC. Drivers and TSRs might unmask other interrupts though, so to be safe you can save the initial state of the mask register and restore it when your program exits.
For memory management, DOS maintains its own heap (really more of a stack) that will be allocated to your program on launch. COM programs will be allocated the largest contiguous chunk of remaining memory, up to and including all available conventional memory. You can then use the DOS memory API via int 21h to query how much was actually allocated to you. MZ executables specify in their header how much memory is required and how they should be loaded, but I can't speak to the specifics. Normally this will be handled by the compiler for a C program, and normal heap allocation functions can be used obtain more dynamic memory if necessary.
You can launch sub-programs also using the int21h API, but to do this you must make sure there's actually RAM left to do so. For a COM program this would involve shrinking your own program's allocated space before launching the nested program so that it actually has room to load. When the nested program exists, its ram will be free again to reallocate to yourself. Since DOS is a single-tasking OS, there's no need to worry about "competing" programs allocating ram, your running program effectively has total control of the system and could even clobber the DOS kernel and use its space if you want (though that's obviously not recommended since you'd need to reboot afterward).
Hey folks, I'm working with:
I'm able to display PCX files and move them around, but can't get any sort of transparency working - I've added areas to my images with RGB set to 255, 0, 255 but I'm guessing when GIMP exports to PCX it's not the right colour setting?
Does anyone know the right GIMP settings or potentially even another program to help edit these images and included DOS friendly transparency?
It's been a long time since I've used allegro, but IIRC transparency works differently based on the color depth of the source bitmap. The magenta color key (255,0,255) works for truecolor bitmaps, but PCX is an 8-bit indexed format, which means the transparent regions are color index 0. If you're using indexed color mode in GIMP, make sure magenta is the first entry in the palette. A drawing program like GrafX2 or aseprite is also useful for palette manipulation and working with 8-bit images in general.