DOS ain't dead

I'm currently moving some data around that has to stay in the low memory area. Is there any data between address 0h:520h and 0h:600h? (That's between segment 50h and 60h except the few items described in RBIL 61's MEMORY.LST.) Does any program use this space?

There's a large table I want to put there in one piece. It currently requires about 300 byte. When the upper 256 bytes are placed in segment 60h, it would require about 40 byte at the end of the 256-byte segment 50h.

---
l

> I'm currently moving some data around that has to stay in the low memory
> area. Is there any data between address 0h:520h and 0h:600h? (That's
> between segment 50h and 60h except the few items described in RBIL 61's
> MEMORY.LST.) Does any program use this space?
>
> There's a large table I want to put there in one piece. It currently
> requires about 300 byte. When the upper 256 bytes are placed in segment
> 60h, it would require about 40 byte at the end of the 256-byte segment
> 50h.

Well, everybody that wrote a TSR and got the same idea. Of course you'll only find out later

> I'm currently moving some data around that has to stay in the low memory
> area. Is there any data between address 0h:520h and 0h:600h? (That's
> between segment 50h and 60h except the few items described in RBIL 61's
> MEMORY.LST.) Does any program use this space?

A copy of floppy disk parameters (11- or 14-byte table) is typically placed by DOS at 0:522h, and the INT 1Eh vector points there. The table is moved there either at DOS BIOS (IBMBIO.COM/IO.SYS) initialization (in PC DOS, MS-DOS 6-, DR-DOS), or even earlier, by the bootstrap loader in the Boot Record (in MS-DOS 7+). (The purpose of copying the table from ROM BIOS to RAM is to optimize head settle time and to set the maximum sectors per track for high-capacity formats.)

The memory area at 0:500h is also used temporarily at boot time, e.g., PC DOS and MS-DOS 6- bootstrap loaders read directory sectors there. But this is probably non-conflicting with your idea.

Anyway, it is rather risky to assume that the remaining area is not used at all by any software. What do you exactly need this space for? Is there any good reason to use it, other than saving some Conventional Memory for applications?

> A copy of floppy disk parameters (11- or 14-byte table) is typically
> placed by DOS at 0:522h, and the INT 1Eh vector points there. The table is
> moved there either at DOS BIOS (IBMBIO.COM/IO.SYS) initialization (in PC
> DOS, MS-DOS 6-, DR-DOS), or even earlier, by the bootstrap loader in the
> Boot Record (in MS-DOS 7+). (The purpose of copying the table from ROM
> BIOS to RAM is to optimize head settle time and to set the maximum sectors
> per track for high-capacity formats.)

Thanks; I once knew that table was also somewhere there. It doesn't conflict with me using the high part for another table.

> The memory area at 0:500h is also used temporarily at boot time, e.g., PC
> DOS and MS-DOS 6- bootstrap loaders read directory sectors there. But this
> is probably non-conflicting with your idea.

Yes.

> Anyway, it is rather risky to assume that the remaining area is not used
> at all by any software. What do you exactly need this space for? Is there
> any good reason to use it, other than saving some Conventional Memory for
> applications?

Well, beside that, there isn't really a good reason. I'm relocating the second Interrupt Restoration Table (IRT) which should allow to reboot with Int19 at any time, just like Jemm's FASTBOOT option. (Of course some software like EMMs have to return to real mode in their Int19 code for this to work.) However neither the table nor the Int19 handler itsef can move into the HMA or even UMA. A20 might be disabled and the XMM may not be available to enable it for using the HMA; and DOS's UMA is probably just extended memory mapped in by an (already disabled) EMM.

So, yes, I just want to save some LMA space.

I found that the DOS-C user documentation (file config.txt) states that "a reasonably safe choice" for relocating the Int09 keyboard buffer (KEYBUF command) should be offset 0x140 to 0x1BF (of segment 40h), including. I would currently place the IRT at 0x1D0, so it won't conflict with a keyboard buffer in this area. (Other locations mentioned in config.txt include the few bytes for PrnScrn/DOS single-floppy change and the BASICA data.)

---
l