Patching IBM DOS 5 for the PCjr

[jmetal88]

Actually, considering how far FreeDOS currently gets in the boot process, I'm not sure it needs this patch.

I'm sure it does, otherwise FreeDOS is going to think the total system RAM is 128K.

What it does need is JrConfig compatibility.

I'm curious if the no-ram-disk version of jrconfig gets farther. Maybe it crashes setting up the ramdisk?

My jrconfig 2.14 package doesn't contain the source; I wonder if the original author is still around and still has it. I took a stab at reverse-engineering it, but it's not quite a typical device driver (there is junk user data in what should be the Device Name section, for example) so I don't hold a lot of hope that it would be "easy" or "trivial" to create .asm source that recompiles, like most device drivers that follow the spec exactly.

Well, from the boot process, it looks like it's just assuming that all the RAM it needs is available, and it's not looking for a value or anything. I could be wrong, though.

EDIT: And I'm already using the no RAM disk version of JrConfig. I do have it setting up an additional inaccessible area of low memory, though.

[Trixter]

I may have misunderstood how jrconfig works -- No matter how I set it up, even with the non-ramdisk version, even with -v32, I always get 640K usable. (my config.sys looks something like "device=jrconfig.dsk -t2 -v64 -c").
I was hoping to set it up somehow so that I can get slightly more RAM available in special situations, like when I develop software; the slower RAM speed hit is still an order of magnitude better than having to swap data in/out of disk. What am I missing?

[James]

Going by memory, but I believe "-L" tells it to look for the extra memory

[Brutman]

I may have misunderstood how jrconfig works -- No matter how I set it up, even with the non-ramdisk version, even with -v32, I always get 640K usable. (my config.sys looks something like "device=jrconfig.dsk -t2 -v64 -c").
I was hoping to set it up somehow so that I can get slightly more RAM available in special situations, like when I develop software; the slower RAM speed hit is still an order of magnitude better than having to swap data in/out of disk. What am I missing?

The point of jrConfig is to enable the extra RAM for DOS usage, which generally means relocating DOS above the video window so that you have one contiguous chunk of it. (Which DOS requires.) JrConfig can do this by hoisting all of DOS above 128K or moving the video window as low as possible, but either way when it is done you will have all of DOS in one chunk above the video window.

What is reporting 640K usable? That seems correct for your settings. With -v64 you are reserving 64K of video RAM. Combine that with probably 16KB required in low memory for DOS and BIOS and you have 512KB + 16KB left over on a 640KB system. (On a jrIDE add another 96KB, which gets you to 640KB.)

To get even more memory, squeeze the video RAM down to 32, 16, or even (gasp) 4 - text mode only.

[jmetal88]

Going by memory, but I believe "-L" tells it to look for the extra memory

Yup, that's exactly the option to use. Your full 736k won't show up without that.

[Brutman]

You don't need the -L when using a jrIDE.

-L tells jrIDE to do a search above 640K because that is where BIOS stops. On a jrIDE I make it look like BIOS walked all of the way to 736K already.

That trick only works on a jrIDE, or if you have modified your BIOS. If you are using a different combination then you need the -L.


Mike

[jmetal88]

You don't need the -L when using a jrIDE.

-L tells jrIDE to do a search above 640K because that is where BIOS stops. On a jrIDE I make it look like BIOS walked all of the way to 736K already.

That trick only works on a jrIDE, or if you have modified your BIOS. If you are using a different combination then you need the -L.


Mike

Hmm, I never realized that, but I just tried it, and it worked! I just always expected it to still need the -L.

[jmetal88]

I may have misunderstood how jrconfig works -- No matter how I set it up, even with the non-ramdisk version, even with -v32, I always get 640K usable. (my config.sys looks something like "device=jrconfig.dsk -t2 -v64 -c").
I was hoping to set it up somehow so that I can get slightly more RAM available in special situations, like when I develop software; the slower RAM speed hit is still an order of magnitude better than having to swap data in/out of disk. What am I missing?

The No-RAM-Disk version still blocks out part of slow memory so programs don't load there. Use -S0 if you don't want any memory blocked off.

[James]

I didn't know that either. Apparently, having the "-L" doesn't do any harm though.

You don't need the -L when using a jrIDE.

-L tells jrIDE to do a search above 640K because that is where BIOS stops. On a jrIDE I make it look like BIOS walked all of the way to 736K already.

That trick only works on a jrIDE, or if you have modified your BIOS. If you are using a different combination then you need the -L.


Mike

[ZiggyTheHamster]

Has anyone been successful in getting this to work with a jrIDE? I have a floppy that boots no problem, but I cannot for the life of me get it to work via a 1GB Compact Flash card.