pouët.net

256b need help

category: general [glöplog]
at least freeze after exit :D
Quote:
Taking and using some static addresses for your needs is not right. If this still somehow works in Dosbox, then on a real DOS it will lead to a freeze in 99% of cases.


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.)
added on the 2023-06-25 22:42:23 by KeyJ KeyJ
Quote:
unless some TSR loaded itself at the top of conventional memory


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.

Quote:
"mov ah, 48h; mov bx, (64000/16); int 21h; mov es, ax"


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.
added on the 2023-06-25 23:15:43 by bitl bitl
Quote:
sound drivers, cd-rom, mouse driver, network drivers, usually emm386, himem.

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...
added on the 2023-06-26 11:10:42 by hfr hfr
Quote:
Before PMode got common, many prods required >600kB of free realmode mem.


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.
added on the 2023-06-26 11:37:59 by bitl bitl
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.
added on the 2023-06-26 14:30:19 by Optimus Optimus
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.
added on the 2023-06-26 14:33:11 by Optimus Optimus
Quote:
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


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).

Quote:
And to hope that segments 8000h and 9000h will be unused is quite naive.


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.

Quote:
Quote:
mov ah, 48h; mov bx, (64000/16); int 21h; mov es, ax

I'm not sure if this is the correct method if we have an exe program, and not com.


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.

Quote:
And of course, if we still use C or Pascal, then it is more correct to use their standard memory management functions.

That's true.
added on the 2023-06-26 15:33:09 by KeyJ KeyJ
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
added on the 2023-06-28 12:40:37 by whizzter whizzter

login