pouët.net

at least freeze after exit :D

That's not quite true. I also learned the 0x8000 / 0x9000 trick back in the DOS days, and used it constantly (before learning what a horrible hack it is and switching over to proper memory allocation from then on). I can confirm that it worked without issues, on real MS-DOS, even though I was running my code with a "fat" IDE (Turbo Pascal) still in memory. As long as less than 512 KiB of conventional memory are used, 0x8000 is going to work; in the same way, 0x9000 is fine for up to 576 KiB, unless some TSR loaded itself at the top of conventional memory, as Optimus mentioned.

That being said, using fixed addresses is still technically wrong. It can be a fair trade-off for sizecoding prods, so I wouldn't blame anyone for using this in a 256b intro. From 4k on, I really don't see an excuse for not doing "mov ah, 48h; mov bx, (64000/16); int 21h; mov es, ax" at the very least. (Bonus points are awarded for proper error handling.)

That's it. And when DOS was used as a working machine, then you definitely had a bunch of TSR-programs: sound drivers, cd-rom, mouse driver, network drivers, usually emm386, himem. And to hope that segments 8000h and 9000h will be unused is quite naive.



by the way, I'm not sure if this is the correct method if we have an exe program, and not com. And of course, if we still use C or Pascal, then it is more correct to use their standard memory management functions.

For DOS demos you usually had a clean config without most of these.
Before PMode got common, many prods required >600kB of free realmode mem.
Few of them were working when only a mouse driver was loaded...

but using memory with static segment addresses is still very strange (unless it's for 128-512 bytes intros).

PS: I had a configuration menu in DOS, with different options. But in general, for most demos (real mode) was enough 580kb. At the same time, I used QEMM, and with the mouse, sound, CD-ROM drivers loaded, I always had at least 590kb of conventional memory.

Thanks, I need to really fix my 286 openwatcom setup. I get more trouble with always using the inline assembly in C code. I should use separate assembly files compiled with some assembler, as the inline watcom assembly misses some syntax, not even repeat macros or others or couldn't make something work. Yesterday I wanted to do a far jump like JUMP 09000h:0000h and got some errors I can't understand "only register or label is expected in override". That compiles well on Fasm so I don't know if the syntax is different.

I am used from other old platforms btw, where you know your memory map, like on Amstrad CPC you don't malloc or anything, you just know that you can use any free areas, or areas over 0A000 might have system calls, so you disaple system and use the whole RAM as you please. Probably, strange for later OS or DOS where TSRs or other might be running at high areas, so I need to change my approach. Didn't crash in my 286/386 so far even with stuff loading in autoexec though.

But how many of those relocated themselves at just below the 640k boundary? I really don't have hard numbers here, but from what I remember back in the day, most drivers just stayed at the address DOS loaded them at, which was either quite low (default) or in the UMA (with LOADHIGH).



Absolutely! But as said, 8000h is a pretty safe bet iff less than 512k are currently used and no more than 64ks worth of TSRs relocated themselves.



That shouldn't matter. The main difference between EXE and COM in this regard is that a COM always gets 64k allocated to it, while an EXE says in the header how much memory it wants upfront. You can always order more than that.


That's true.

TLDR; Most productions this small are going to be .com files and TLDR; 6000h,7000h,8000h should be safe-ish (unless you have much TSR's loaded).

Longer:
Fuzzy memory but if memory serves me corrrect DOS has a linked list of all "allocations" between the segments, the last entry of this list is usually just before video memory starts (hence 9000h isn't really "safe").

.EXE files can specify how many segments they want (this is how a TSR,etc can be smaller by default or be stopped if there is too little memory).

.COM files are older (no header), so by default they consume as much of the memory as possible (a dos call exists to reduce the used amount, but by default it's everything), so once started a com file will reserve all memory from the first free place up until the limit (either end of memory or last TSR).

So assuming you have smth like 580kb free before starting you should be reasonably safe (don't remember exactly how much is reserved at start apart from the interrupt table).

Source: old memories experimentation and Ralph Brown Interrupt List