DOS starting memory address

[alanh]

My understanding of JRCONFIG.SYS is that irregardless of which video page remap it chooses for the B8000-BFFFF area, it still tells DOS to start it's allocations at 10000h (+128K) to avoid DOS loading itself (MSDOS.SYS, IO.SYS, or COMMAND.COM) or applications in the slower shared motherboard RAM. Any idea how it does this?

I'm aware that DOS consults the BDA for the top usable limit where the transient portion of COMMAND.COM usually resides and obviously the heap limit. But I'm not sure how it determines the first available start address.

[KenG]

I believe the BIOS stores the addresses for bottom and top of free memory during the boot process. Then DOS where to load and updates them as drivers and programs are loaded. I don't know which memory addresses contain this information though.

[Trixter]

Because IO.SYS/MSDOS.SYS load before device drivers, a portion of DOS always resides in the lower 128K (which is why DIR free space calculation takes exponentially longer on PCjr, even if you have a memory expansion installed). Only COMMAND.COM and programs loaded after JRCONFIG are in the faster expansion RAM.

JRCONFIG is configurable; you can tell it to not start at 128K, but earlier; this provides more system RAM at the expense of speed. I'm guessing it allocates the first available pages after itself to video RAM, then issues a DOS memory allocation for that area so that it isn't available moving forward, but that's just a guess. If you need it, I can spend some time disassembling the "non-ramdisk" version of the driver to see exactly what it is doing.

[alanh]

That's exactly what I did. I took the 2.x version which was something like 2300 binary bytes and disassembled it taking care to include fixups necessary to reassemble it binary perfect to the original. Then I started annotating. More than 60% of the code related to features unrelated to memory or video services. Tons of RTC code for two rare clock chips, enhanced keyboard code for another buffer product PCE sold, and some other random test code. Despite the relatively small amount of code left, I wasn't able to tell how or where it did the allocation.

I've mostly re-written the JR-IDE BIOS. It had some fairly severe performance issues like an extraordinary number of push/pops around the sector handling. That is all in-lined now (and much simpler as it's not abstracted). And it always did LBA translation even if the CHS was within both DOS and IDE limits. So there were two muls and a ton of arithmetic setting up each int13h call. I've also added proper RTC support, flash disk (496 KB read and write) support, and hooks for high mem support for both the available C segment pages and auto-detection of the ZM56 mod for D and E pages. I haven't touched the boot menu yet, but it will need some TLC to handle the new and much simpler disk redirection (swap) method I've come up with.

I'll take another look at JRCONFIG this weekend. I can also post my annotated disassembly then too. I want to start checking stuff into to the public repo this weekend as well.

[Trixter]

It might be easier to just contact Larry directly -- it appears he is still living in the same place as the documentation states:

http://www.peoplebyname.com/people/Newc ... ethesda/MD

Phone number is part of the above.

[KenG]

If part of the slowdown is due to io.sys and msdos.sys loading into lower memory, could the Jr-IDE BIOS have an option to do what jrconfig does so then these load into faster memory? You would probably want a way to shut this off. Maybe a config setting or another menu? Besides speeding thing up, you could do away with the double boot.

[KenG]

It also seems like the jr-IDE BIOS could put the correct memory amount in the location that DOS expects to see it so that later versions of DOS wouldn't need to be patched.

[James]

It might be easier to just contact Larry directly -- it appears he is still living in the same place as the documentation states:

http://www.peoplebyname.com/people/Newc ... ethesda/MD

Phone number is part of the above.

That's good to know. I should probably send him the $10 contribution that he requested if you found jrconfig useful. Seriously I think will, just on general principal, as I have found jrconfig useful, on and off, for over 25 years.

[Trixter]

If part of the slowdown is due to io.sys and msdos.sys loading into lower memory, could the Jr-IDE BIOS have an option to do what jrconfig does so then these load into faster memory?

JRCONFIG does not relocate these into faster memory. It sets up the system so that everything loaded after JRCONFIG loads into faster memory.

It might be possible, with much studying of DOS internals, to relocate DOS to faster memory, as well as the data structures DOS uses to faster memory. This would be a huge effort for very little benefit, since DOS is only called upon when you work with files, and there is already a monumental speedup using a flash DOM with a jrIDE.

It also seems like the jr-IDE BIOS could put the correct memory amount in the location that DOS expects to see it so that later versions of DOS wouldn't need to be patched.

That's a good suggestion!

[KenG]

OK, I investigated this. The boot sector always loads these starting at a fixed address, so DOS and other programs knows where to access there features. I can now see where changing these would totally mess up DOS and any programs that might access io.sys and msdos.sys directly instead of using DOS int functions. Definately not worth the effort and would probably break compatibility with some programs.

I am learning a lot about the PCjr and DOS via these discussions though. So thanks for your answers to my questions.