Brutman wrote:
You can have the jrIDE BIOS extension fix 0x413 but you still need something to deal with the video buffer. To get rid of jrconfig you have to put that in the BIOS. Personal opinion, but based on 28+ years of software development, I think that function makes more sense as software, not a BIOS extension: jrconfig is quite flexible about how it lays out the memory. Maybe most people don't care about those options and would choose to just load DOS above 128K, but losing configuration flexibility and making the BIOS more complex doesn't seem like a great trade-off to me.
I respectfully disagree; since the jrIDE will never add less than 768K (1MB) RAM to a system, it is reasonable, even expected, that it will do what IBM would have put into the BIOS anyway had they had the foresight. I'd expect the BIOS to reconfigure the PCjr appropriately to handle a jrIDE configuration:
- Ensure correct 40:13 and 40:15 BDA values consistent with the IBM 5150
- Change where the bootstrap loads software, from 0000:7C00 to 2000:7C00 (configurable back to 0:7C00 for compatibility if necessary)
However, the real target for what should happen on a jrIDE system isn't possible in the jrIDE BIOS, which is loading DOS completely outside the first 128K. No matter what options you use with jrconfig, IBMDOS.COM (or equivalent) loads into the first 128K, and is why a DIR takes 55 seconds instead of 15. Device drivers load after IBMDOS does, and while jrconfig doesn't move DOS, Quarterdeck proved it was possible to do so (I am not immediately aware of what kind of fixups are involved; it might be simple, it might be complex). A fully jrIDE'd system should have the interrupt table and videostuff in the first 128K and nothing else.
I haven't looked at DOS source in a while, but it is entirely possible that changing the bootstrap to load at 2000:7c00 might actually be enough: If DOS never assumes it is always loaded at segment 0 (and it doesn't, I see it changing ES to 40h when referencing the BDA), that just might work.
the video buffer fix-up
There isn't really a fix-up -- jrconfig just allocates memory up to the end of 128K, so that the very next thing to load starts loading past video memory. If you use the ramdrive version, jrconfig makes some of it available as a ramdrive, otherwise it's just unused. It's never "gone" or "moved" -- I used 6 video pages while jrconfig was loaded, it's just using the VGA page registers as always.
A system with extra memory should not be functionally different from a different system with a different memory expansion.
That's likely the crux of your disagreements. For the record, I disagree, because I'm not under any misconception that a jrIDE needs to maintain compatibility with IBM's memory device driver (or any device driver). It should be compatible at bootup, but last I checked, MS Flight Simulator 2.13 still asks me if I "want to use my extra memory" to run faster, and it works. I doubt fixing up the BDA would change that, since I'll bet MS 2.13 doesn't look at the BDA since that value never changes.
I'd really like native Ethernet for one
Well, I think we all agree on that :-)