DOS starting memory address

[alanh]

I disassembled 2.14 again and I swear I cannot find where it's placing a reservation. Yet I'm running 2.14 on my machine and DOS programs are loading at around +148 KB offset into memory.

[KenG]

I think you have to look at the boot sector of the media. It determines where io.sys is loaded. The references I found said at 0000:7C00.

[KenG]

Oops, were you talking about jrconfig.sys? I think I got my conversations confused.

[Trixter]

I disassembled 2.14 again and I swear I cannot find where it's placing a reservation. Yet I'm running 2.14 on my machine and DOS programs are loading at around +148 KB offset into memory.

I haven't looked at it for a few nights, but last I checked, JRCONFIG was doing two things that was interesting: 1. It was poking around in low memory (may have been manipulating the BIOS DATA area), and 2. It was hooking some interrupts (10, 20, 21, 27) to always call a CPU/VDU page set routine before calling the original interrupt. The latter is a red herring, I think; it looked interesting, so I checked the PCjr BIOS for what it is doing, expecting to see some memory stuff, but it's doing what you would expect it is doing.

I think JRCONFIG is able to find where DOS keeps its heap start pointer and increases it directly in the data structure. I can keep tracing (I'm working with 2.10), but have you tried giving Larry a call?

[Trixter]

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.

They get loaded at a fixed address but most software that uses MS-DOS functions properly (through the int 21, etc. interfaces) would work just fine if DOS were relocated somewhere else in memory. (Quarterdeck wrote a section of QEMM to do just that, so that portions of DOS can be loaded into upper memory.) However, because using DOS functions (copying files, doing a DIR, etc.) is less than 1% of the time spent using a vintage system, there is pretty much no benefit to attempting this for PCjr. It would take many tens of hours to come up with a device driver to do so, but you'd never get that time back actually using a slightly-sped-up system.

[Brutman]

I think that Larry has been dead for years ... I tried the contribution thing almost 10 years ago.

[Trixter]

I got over my fear of public speaking and called the number, and talked to him! He was very nice, and was very surprised (laughing, actually) to learn that we were doing what we do. Unfortunately, he lost the JRCONFIG source code a long time ago, but he was able to confirm a few things:

• When he still had the source, he gave it to someone who asked for it and wanted to make modifications. I now believe that to be someone from PC Enterprises, so if anyone has any PC Enterprises contact info, now's the time to reach out.
• He confirmed that the main mechanism for adjusting where DOS loads new programs is a DOS memory structure. He directly adjusts that value to set the new starting location of whatever DOS uses for its heap mechanism.

Continuing disassembly of the source is our final recourse if nobody knows anyone who used to work at PC Enterprises. Now that we know what the mechanism is, hopefully there's some documentation somewhere (maybe the DOS 6.x source code) that lists DOS memory structures and how to locate them.

[Brutman]

Phew - happy to be wrong!

[James]

I emailed back and forth with son of the founder of PC Enterprises a couple of years ago. I was hoping to get my hands on a jrExcellerator, display master and Combo v3 (jrVideo, Quicksilver, Keyboard Buffer and Compatibility) cartridge or anything else that might be interesting. He said he looked in their back room but all they had were PC Enterprises mouse pads. Friendly enough but I got the feeling that they were not going to expend much effort. He never answered my question whether they had the rights to sell the source code for the combo v3.

Update:

Found the email address and made an inquiry

[Trixter]

I'm assuming the inquiry fell on deaf ears?

I did some more digging and found that DOS 2.0 definitely has a concept of a heap start:

Code: Select all

        i_need  arena_head,WORD         ; seg address of start of arena
        i_need  CurrentPDB,WORD         ; current process data block addr
        i_need  FirstArena,WORD         ; first free block found
        i_need  BestArena,WORD          ; best free block found
        i_need  LastArena,WORD          ; last free block found
        i_need  AllocMethod,BYTE        ; how to alloc first(best)last

This was out of the 2.0 source code. So it's clear JRCONFIG is just adjusting arena_head to start at the 128K border. As to where that data structure actually is, I haven't found that yet, but I'm guessing it's at the DOS parameter area that starts at 50:00.