Remix.run Logo
pjmlp 3 days ago

As someone that was already coding during those days, having done the transition from a Timex 2068 into MS-DOS 3.3 and wonderful 5¼-inch floppies, the article is quite good.

One thing missing are overlays, where we could have some form of primitive dynamic loading, having multiple code segments for the same memory region, naturally only one could be active at a time.

PennRobotics 3 days ago | parent [-]

Some of the early Microprose games used this, and it was clever for two reasons:

First, more functionality. The minigames and intro/conclusion scenes were their own executables that made use of the original, generated game data. These got loaded into RAM on top of the original executable and then called.

Second, graphics and sound were also overlays. Rather than having useless-to-most Roland MT-32 code in the binary, this was only loaded if requested. There were overlays for Sound Blaster, PC speaker, and Adlib. If your monitor only supported four colors (CGA) there was an overlay for that.

A post would be nice, although you basically described most of it. An .OVL file with a non-zero overlay number is loaded into memory with INT 3Fh (although strangely enough any interrupt number could be chosen?, and the interrupt also would call the desired function after loading into memory). These overlays are loaded as-needed into a shared memory space.

I'd be more curious to see how one would have programmed those overlays in Microsoft C Compiler 3.0. More recent compilers seemed to have better menus and documentation for the memory models, but it seems like they were clairvoyant by squeezing every bit of functionality out of version 3.0 that was made easier by Watcom/Borland/MS 5.0. (Then again, they would have evolved their build system with every successful release and every new hire, plus it was their full time job to "figure that crap out", and maybe Microsoft improved their approach to overlays in response to Microprose and others calling all the time)

The documentation states only one EXE is generated, but Microprose had multiple EXE files. Is it possible those weren't overlays but something very similar? Or did they just change the file extensions? The docs also show the syntax "Object Modules [.OBJ]: a + (b+c) + (e+f) + g + (i)" where everything in parentheses is an overlay. But this isn't elaborated. What are the plus signs? How are these objects grouped? Would their list look like "preload + (cga + mcga + ega + vga) + (nosound + tandy + pcspkr + roland + sb) + (intro) + (newgame) + (maingame) + (minigamea) + (minigameb) + (outro)"? Or would every module be individually parenthesized, and those with plus symbols are interdependent (e.g. not alternatives)? (One website using BLINK seems to suggest the latter.)

I know there are a lot of DOS tutorials (FreeDOS YT channel, blog posts) but I haven't found one that does a start-to-finish overlay example.

achairapart 2 days ago | parent | next [-]

See: https://neuviemeporte.github.io/f15-se2/2023/07/12/overlays....

From this series: https://neuviemeporte.github.io/category/f15-se2.html

Related HN thread: https://news.ycombinator.com/item?id=40347662

PennRobotics 2 days ago | parent [-]

Awesome! That's my reading material for the next week.

Now I wonder if MISC.EXE and xGRAPHIC.EXE were the same across different games e.g. Covert Action vs F15 SE2... (I just checked. MISC is different. Some routines are nearly similar, but newer versions have additional machine code and updated strings.)

achairapart 2 days ago | parent [-]

From the article:

   Interestingly, although Civilization uses an almost identical setup menu and also contains multiple exes that look like sound and graphic drivers based on their name, the overlay header format of those seems to be different, and could not be parsed by my tool. Seems likey they were updating the scheme as they went along (Civ 1 came out 1991, so after F15-II).
My guess is that they constantly updated their libraries game by game, as both hardware and software/dev tools in those times were moving really fast.
pjmlp 2 days ago | parent | prev | next [-]

Borland compilers and Clipper supported them directly.

Chapter 18, TP 3 and 7, to show its evolution

http://www.bitsavers.org/pdf/borland/turbo_pascal/Turbo_Pasc...

http://www.bitsavers.org/pdf/borland/turbo_pascal/Turbo_Pasc...

TC++, page 211

https://bitsavers.org/pdf/borland/turbo_c/Turbo_C++_Programm...

Clipper, section 7-18

https://archive.org/details/Clipper_Compiler_for_dBASE_III_a...

ngcc_hk 2 days ago | parent [-]

What I am looking for. A memory map great, but still needed to be used by normal guy who just use compiler …

int_19h 2 days ago | parent | prev | next [-]

The original X-COM (aka UFO: Enemy Unknown), despite being 32-bit, had two completely separate executables for the strategy part and the tactical combat part. The game basically dumped the relevant state like inventory to disk and then exited and relaunched the other process at switch points.

globalnode 2 days ago | parent | prev [-]

micropose and their floppy disk protection argh!!!, couldnt even backup a purchased game, and you know how long those disks lasted...