• Please review our updated Terms and Rules here

Discovered RTC bug in PC DOS 2000 / IBM DOS 7

640KB

640KB

Experienced Member
Joined
Jan 8, 2019
Messages
136
Location
NYC
During some testing of GLaTICK we discovered a curious "bug" in PC DOS 2000 / IBM DOS 7 having to do with DOS DATE/TIME support of `INT 1Ah` real-time clock functions. On an XT machine with a V20 CPU running these versions, when using DOS's DATE or TIME commands to set the clock (or any DOS `INT 21h` clock function) the RTC would be set with incorrect values. Specifically, if you set the time as 2023-04-18 12:05:00, the RTC would read back as 1417-04-12 0C-05:00.

After some debugging and tracing, it turns out that IBM DOS 7 and its decedents replaced the code that converts a byte value to a BCD value (which `INT 1Ah` expects) with the following:

ibm7_debug_1a.png

Since `AAD imm` is not supported on V20 it will execute `AAD 10h` as `AAD 0Ah`, meaning that the `AAM` and `AAD 10h` negate each other and DOS ends up passing the binary value to `INT 1Ah` instead of the BCD value, resulting in the invalid times. This code saves 8 bytes (though is actually more clock cycles) compared to the normal (and well tested) shift-n-OR method.

Anyway, just thought I'd share so it can be documented for posterity.

640KB
 
I've used many V20/V30/V40 systems with PC DOS 7.0/2000 and never run into this issue, because each system -- if it even has a hardware real-time clock -- has its own RTC driver to read and set the clock.

I did have one system which set the RTC year to 192x instead of 202x, but that was due to a bug in the RTC driver, not DOS.
 
vwestlife said:
I've used many V20/V30/V40 systems with PC DOS 7.0/2000 and never run into this issue, because each system -- if it even has a hardware real-time clock -- has its own RTC driver to read and set the clock.

I did have one system which set the RTC year to 192x instead of 202x, but that was due to a bug in the RTC driver, not DOS.
Click to expand...

Right, this wouldn't affect clock setting/reading programs that run within DOS. This is an issue specific to DOS 7's CLOCK driver in the way it sets and reads a real-time clock IF `INT 1Ah` support is detected at boot where RTC is provided by the BIOS -- as it would be for 286's and up. Since very few XT's had BIOS-level support for their RTCs (and of those, fewer had V20's) this would have been a corner case for sure.
 
Seems more an issue of running PC DOS on an unsupported system. I don't believe IBM ever suggested PC DOS was designed for V20 based system?
 
booboo said:
Seems more an issue of running PC DOS on an unsupported system. I don't believe IBM ever suggested PC DOS was designed for V20 based system?
Click to expand...

Sure -- they intended this version for IBM hardware of the time (which was well into the Pentium era at that point), of which IBM never made any V20 based PCs so it's logical that they wouldn't have considered that system in design or testing.

On the flip side, I suppose I'd be interested if IBM ever suggested that PC DOS 7/2000 specifically did not support XT class machines, or explicitly V20-based XT machines. I haven't looked for nor found anything that says one way or the other about system requirements different than previous versions of DOS. Though other than this V20 issue and features that are clear in saying they require a 386 or above (EMM386, etc), there's nothing I've seen that says that version could/should not be run on XTs.

I just tend to classify it as a DOS bug because they made a code change that broke a feature for some users that had previously worked. Using `AAD imm8` is just one of those instructions programmers want to use because it's short and neat (like SALC 0D6h), but in reality know they really shouldn't in production software because it's officially undocumented and as such the behavior could change at any time.
 
PC DOS hardware requirements are listed at https://www.ibm.com/common/ssi/rep_ca/2/877/ENUSZP95-0102/index.html
PC DOS Version 7 operates on Intel(**)-based or Intel-compatible personal computers (8088, 286, 386, 486, and PENTIUM processors).
Click to expand...

The systems that would catch this bug would include the PS/2 Model 25 or 30 that got upgraded to a V chip and many of the palmtops such as those from Tidalwave that shipped with a V chip. The Model 25/30 and many of the late budget XTs might not have been expected to work with DOS 7 since the Dallas clock chip would have probably run out of battery before DOS 7 was released.
 
The issue is that the V20 is not 100% compatible with the 8088. Which is why it's a V20 bug.
 
booboo said:
Seems more an issue of running PC DOS on an unsupported system. I don't believe IBM ever suggested PC DOS was designed for V20 based system?
Click to expand...
Actually they did. The release notes for PC-DOS 7 are quite proud of their V20 optimizations
 
The manual for PC DOS 7.0 specifically states that it supports everything down to the original 5150 PC, as long as it has enough RAM and hard drive space.

The only component of any DOS that I'm aware of which will run on a NEC V20 but not on an 8086 or 8088 is the Windows 95/98 (MS-DOS 7.x) version of the MS-DOS Editor.
 
Shows what a "clever" piece of code can do.

The only component of any DOS that I'm aware of which will run on a NEC V20 but not on an 8086 or 8088 is the Windows 95/98 (MS-DOS 7.x) version of the MS-DOS Editor.
Click to expand...

There are other products, such as network drivers, that are coded to expect 286+ instructions, and work just fine on a V20-equipped XT. So there's that.
 
FYI, almost all the programs in PC DOS 7.0/2000 were compressed using PKLite, which saves disk space but takes additional RAM and CPU time to uncompress before the program runs.

Compression of EXE files in DOS began with the use of EXEPACK in MS/PC DOS 5.0, which led to the cryptic "Packed file is corrupt" error message:

EXEPACK and the A20-Gate | OS/2 Museum

www.os2museum.com www.os2museum.com
 
Any way to patch PCDOS to address this issue? I have GLaTICK running on my Compaq Portable with an AST MegaPlus II (running PCDOS 2000 with a V20) and was scratching my head on why it didn't quite work!
 
You can always downgrade to 6.3. Or try to convince pcdosretro to come back to the forum and hope he still has the source :)
 
I wonder if this change was to avoid partial register stalls on the AH register.
 
krebizfan said:
The systems that would catch this bug would include the PS/2 Model 25 or 30 that got upgraded to a V chip and many of the palmtops such as those from Tidalwave that shipped with a V chip.
Click to expand...
V30 based Olivetti PCS 86 and Quderno-XT is affected as it has RTC. Maybe V40 based Olivetti M200, Prodest PC 1, ETV 2700, VM 2000 and Quaderno-XT also would be affected if they would have RTC (they don't have). But the two ETV and the VM would not be recommended to use other DOS version than 3.20 as their special printer drivers only work with 3.20, other DOS version would make those word processor systems useless.

(Quaderno has ROM based DOS 5 but can boot other DOS versions, too, but most still existing Quaderno are dead because of tantalum capactors and/or "wormy" LCD.)
 
Chuck(G) said:
There are other products, such as network drivers, that are coded to expect 286+ instructions, and work just fine on a V20-equipped XT. So there's that.
Click to expand...
IOMEGA ZIP driver is such an example. A V20/V30 CPU is the way to use a parallel port ZIP drive on XT class computers. The driver uses some 80186 commands which are supported by the NEC CPU but not on 8088/8086.

(There is palmzip driver as well, but this one won't work on some parallel ports like on Olivetti M24. Additionally to V20/V30 CPU you will need to have MS-DOS 4.01 or newer to support 100 MB medias)
 
You must log in or register to reply here.
Back
Top