Mike's PCjr Page

Brutman wrote:The real issue here is boot diskettes from one PCjr not working on another PCjr.

To me, this is not an issue at all.

• If I install a jr-IDE, suddenly I can run software that I can’t run on a stock 128K Jr.
• If I install a Tandy mod, I can run software that won’t work on other Jrs.
• If I install an NEC V20, ditto.

Every upgrade makes the Jr capable of new things, and having a BIOS fix that makes it possible to run regular DOS 5+ on the Jr is no different in my mind. It’s not as if the DOS 2.1 or 3.3 boot disks wouldn’t work any more.

Meanwhile, I find the double-boot pretty tedious. First I have to wait about 6 seconds for the jr-IDE to decide that I don’t have a second drive, then wait 5 seconds for the default boot menu choice, then wait through the boot menu pause again. Or, more commonly, I sit there and hit Esc, C, Esc, C every time I boot. Either way it’s less than excellent. Old DOS machines need to be rebooted often, and I have a lot going on in my autoexec.bat (including DHCP and NTP—thanks, Mike!) that makes the boot process slow enough already.

The jr-IDE maxes out the RAM, so having it also do JrConfig’s usual job of moving the video buffer, enlarging it, and blocking off the rest of the slow RAM would be nice. I’d just want to be able to turn that feature off on the rare occasions I wanted to do something different. If you wanted to continue using JrConfig, you could leave the feature off permanently.

It would also be nice to streamline the jr-IDE’s startup: avoid the long wait on a second drive that will probably never be there and shorten the pause for the boot menu (2 seconds?). Maybe provide one-key shortcuts so I can just hit C instead of ESC, C. With these changes and avoiding double-booting, 16 seconds of waiting could be cut to 2 or less.

Brutman wrote:Assume you have a PCjr that can run DOS 5 unmodified. Now it's not compatible with any other PCjr in the house, and you still need two sets of boot floppies. The second boot required by jrconfig also doesn't take a lot of time or break anything so I don't understand the need to fix it.

I completely disagree. A stock PCjr could technically boot an unmodified DOS 5.0 with JRCONFIG.SYS needed to move the window. However, your example assumes 2 Jrs both with extra memory. My position is both of those expanded Jrs are inherently 'broken' because the memory expansion in either doesn't augment the limitations of the stock BIOS and correct the BDA to indicate the true top of RAM. I'm proposing fixing one of those systems.

The other flaw in your example, is you don't need two sets of boot floppies. You just need the modified one. There is nothing stopping a patched DOS 5.0 from booting on a system where the option BIOS already fixes-up the BDA.

This discussion is interesting because it's a software architecture and philosophy discussion ...

The BDA area issue is complicated. 0x413 can't be set the same as 0x415 because by default the video buffer at the top of the first 128K breaks things. Setting 0x413 to the same value as 0x415 does absolutely nothing for compatibility, and worse, tricks DOS (all versions) into loading at the wrong place and stepping on the video buffer. (Or having writes to the video buffer step on something else.) That can be fixed by moving the video buffer (which jrConfig can definitely do) or by loading DOS above 128K. Every memory expansion had the opportunity to fix this in a BIOS extension and chose not to for a reason; it's complicated and limits configuration flexibility.

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.

The jrIDE changes the picture because it is guaranteed to be the only BIOS extension installed and the FLASH gives us the option to have a configuration area. Doing all of this is more feasible, especially if you need to change the configuration behavior - it's a matter of updating FLASH, now throwing hard switches.


Alan - If you fix the BDA area problem in BIOS you still need two sets of boot disks; one with jrconfig and one without. If you get DOS to boot and you don't have jrconfig you are going to stomp on the memory window. There are two ways out of this; if jrConfig fails to run because it is not on a Jr or if the BIOS does everything (and thus jrconfig is not needed at all). Jrconfig is probably smart enough to fail, so maybe this is not an issue. I realized my mistake regarding the BDA last night but left it uncorrected because the memory window is still a problem; with a corrected BDA DOS loads but then stomps the memory window.


DoctorOctal:

My issue isn't with extending the capabilities of the Jr. My issue is that for 36 years all memory expansions have basically worked the same way, and they require the video buffer fix-up and possibly a second boot. (I haven't touched the other memory managers in years.) A system with extra memory should not be functionally different from a different system with a different memory expansion. Things that extend the system (what you listed) are different than things that change the nature of the system. (Nit: the V20 breaks LodeRunner, which was poorly written and can be fixed.)

I also don't mind the double boot; a few seconds here and there does not bother me. It's a vintage machine; I expect my current 16 core workstation to be fast, not my vintage machines. I'm happy when everything works.


This is all a matter of personal opinion. I think there are bigger problems out there to fix before fixing the double boot behavior. I'd really like native Ethernet for one. And a second serial port with a Ring Indicator signal would be nice. I don't want to break compatibility with my other Jrs which are not as well equipped. If the BIOS gets updated it should be configurable. What people do with their bedroom PCjrs is not my concern. ;-0

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 :-)

We can respectively disagree all we want, but it has to be based on facts. Jrconfig can absolutely be told to move the video buffer ... go boot with the /S0 option set and see for yourself.

The screen output booting DOS 2.1 with Jrconfig.Sys says the following:

736 Total memory
80KB of Slow memory available
9KB allocated for a RAM disk
16 KB allocated for the video buffer at segment 0800h

That says the video buffer starts at 32KB and extends to 48KB, leaving 80KB of the first 128K usable by DOS. Within the first 32KB there is the BIOS data area and probably the lower portion of DOS, and 9KB of RAM disk space because the video buffer must be 16KB aligned.

Chkdsk reports 690992 bytes available (674KB) out of 736KB. 32KB lost to BDA and DOS, 16KB to the video buffer, and some more to RAM. It adds up pretty well.


Back to the discussion. Personally, I think this is too complicated for a BIOS extension and it belongs in software. I'm not stopping anybody and my opinion really doesn't matter. The double boot issue just doesn't bother me enough to do anything about it. My opinion is mine alone ...

I wrote "move DOS", not move the video buffer. jrconfig does not relocate DOS out of the first 128K which is something that I feel should happen on a system with 736K memory. The speed penalty of leaving DOS in the first 128K is measurable with a stopwatch and is worse than the extra ~64K you'd get as available DOS memory. In my opinion, anyway.

For completeness of information, jrconfig "moves" the video buffer by changing the CRT page and processor page registers to point to different memory pages. This process is not compatible with all PCjr-specific software, but then again compatibility in this area is not something we expect from our favorite computer :)

Trixter wrote: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.

I was responding to this. jrconfig can allocate memory up to the 128K boundary, but it can also allocate very little. In my /S example it was only reserving the first 48K of memory; 32K + 16K for the video buffer. The moving of the B800:0000 window is very much a fix-up.

I was looking in the tech ref when I wrote my post. I also looked at the annotated jrconfig assembler listings that Alan posted, but strangely I did not find the OUT commands to the port needed to move the memory window.


Mike

Going to go back and read the latest replies when I have more caffeine. Let me re-iterate... the only thing I'm trying to solve is the double boot issue. The only thing necessary to prevent jrconfig.sys from double booting is the fix-up patch code you have been manually adding to (eg) DOS 5.0's MBR loader. Adding that to the BIOS will not break loading a patched DOS - if that's what you have on-hand. It will also make the system boot much faster as jrconfig.sys will not reboot. I have the change in my BIOS re-write and it works just fine - as it should as it just does the same thing as the patched DOS MBR loader.

The only thing I was lacking in the BIOS re-write was a configurable mode switch to handle LBR translation. I wanted to include three modes, 1) the legacy translation code in Jeff/Mike's BIOS as-is so it wouldn't break existing disks formatted with the old algorithm, 2) a more optimal algorithm that eliminates a multiplication in situations where the geometry allows simple shifts to translate, and 3) a CHS translator that will overcome the BIOS vs DOS CHS parameter limitations for older drives that are not LBA aware. #2 and #3 can be combined where a drive does support LBA but it is easier to perform simple CHS shifts to realign sector arguments. 2+3 was what I implemented and then realized it horribly breaks backwards compatibility. Then I ran out of time again.

-A

If moving 0x415 to 0x413 fixes the double boot, great. But are you still using jrconfig? Is it detecting that 0x413 has been adjusted and not making the second boot as a result?

I'd love to see CHS support in the BIOS - that's one of the usability problems that I would fix first.


Mike

Brutman wrote:If moving 0x415 to 0x413 fixes the double boot, great. But are you still using jrconfig? Is it detecting that 0x413 has been adjusted and not making the second boot as a result?

jrconfig.sys is still a must. Sorry, I mis-stated. I move 736 into both BDA fields and jrconfig.sys skips the double boot. jrconfig.sys checks the 413h size for 128KB or less. If it is 128KB or less, it copies 415h into 413h and reboots.

I do have a byte-perfect fully annotated jrconfig.sys 2.14 disassembly located at:

https://www.retrotronics.org/svn/jride/ ... rc214.dasm

The 3.10 is there to but not annotated.

EDIT: wtf.. I'm getting old. 3.10 is partially annotated and I really don't remember doing that.