• Please review our updated Terms and Rules here

DOS System Time

P

pearce_jj

Veteran Member
Joined
May 14, 2010
Messages
2,808
Location
UK
I wondered how the DOS system time is kept.

I'm using the system time to calculate disk throughput, which works fine with MFM controllers and XT/IDE in it's default state (the utility creates a 4MB file so it takes a while on this old kit).

However with the modified XT/IDE ('Chuck mod', which enhances read speed) the timing is off. Printing the system time either side of the test, the system clock only advances 15s whilst time in reality has advanced 40s.

Any thoughts greatly appreicated. Time is being gathered by Turbo Pascal 6 DOS unit procedure "GetTime".

Many thanks!
 
It's a known problem with XT-IDE. It has interrupt disabled while reading and writing blocks; as a result it misses the hardware timer interrupts. That means the BIOS time keeping interrupt is not being invoked as often as it should, resulting in time slowing down. You will notice it acutely on benchmarks, and I had a note in the Wiki about it.

On other machines if the hardware timer interrupts have to be disabled for such a long period of time the code will read the timer value, disable interrupts, do it's work, and then adjust the timer value or invoke the BIOS time keeping interrupt the correct number of times to get things back to normal. The PCjr floppy BIOS is a good example of a machine where that is done.

Interrupts can probably be enabled while the port access to read and write the data register is going on, but that's an experiment for another day ...
 
Thanks very much for this. As an aside, do you have a link to the XT/IDE wiki now (since it's all been changed about I can't find anything and the Google links are dead too).

Would it be possible to modify the XT-IDE BIOS to trap the timer ticks and/or enable interrupts, or is there some other reason preventing this?

Many thanks!
 
I never could understand why interrupts were disabled during a transfer. I used Hargle's BIOS modified by me--without the interrupt disabling. It's not as if any of the I/O transfers are time-critical or non-interruptable.

I'm sure that the STI and CLI instructions must not be gratuitous, but I certainly don't know why they're there.
 
Chuck(G) said:
I never could understand why interrupts were disabled during a transfer. I used Hargle's BIOS modified by me--without the interrupt disabling. It's not as if any of the I/O transfers are time-critical or non-interruptable.

I'm sure that the STI and CLI instructions must not be gratuitous, but I certainly don't know why they're there.
Click to expand...

I think it was out of an abundance of caution. It also keeps other code from touching those ports while they are in use, although that is unlikely.

Since you have tested the code without the interrupts being disabled it's probably fair to change the BIOS to do that. But the original intentions were good - program correctness is the highest priority.
 
Yes, but how would other code touch those ports, Mike? It'd have to be within an interrupt service routine, which would be really ratty practice. One could, by the same logic, demand that interrupts be disabled when a CRT screen is being scrolled.

Now, there are logical reasons for doing this sort of thing--if a floppy controller doesn't have DMA access and you're transferring using programmed I/O, data moves in real-time and missing a transfer will get you an underrun error, which is not very cool.

But all IDE-interface devices have integral buffer memory, so it's not an issue.
 
Chuck,

I'm not arguing with you - in fact I have already suggested (and agreed) that it is not necessary and it was done out of an abundance of caution.

But yes, a different ISR can come in and touch things or alter timing. So to be absolutely paranoid is to be correct. We normally start with correct and then optimize for performance later.
 
mbbrutman said:
We normally start with correct and then optimize for performance later.
Click to expand...

I'm not buying it. I've written my share of device drivers and have never disabled interrupts while doing a series of port reads or writes purely out of paranoia.

Look at any system BIOS--it's not done. If some yahoo wants to stick direct port writes to devices he doesn't own in his ISRs, sobeit. That's his lookout and the nature of DOS. It's better that he discover it when he's developing than completely miss the error because some programmer wrote his code to be overly "cautious".
 
Many thanks for the wiki link, detail and ensuing discussion :)

Sounds like having a crack at altering the BIOS would be a good way to 'get in to' the code anyhow.

Cheers!
 
Chuck(G) said:
I'm not buying it.
Click to expand...


Chuck,

I'm not selling anything. We are in violent agreement. It's time to beat a different horse. At this point you are just pissing on some old code that Hargle wrote for no real reason. We know it's not optimal.



Mike
 
I have a question regarding this. What if you have an onboard AST S-x-Pack Plus with clock/calendar enabled. I know you have to write a config sys and autoexec file that will load when you load DOS. This information came from the AST's documentation. Am I to take it from this that XTIDE will not give you or will lose that functionality from the AST? Can't you write an autoexec.bat and config.sys into whatever version of DOS your loading with XTIDE?.

mbbrutman said:
It's a known problem with XT-IDE. It has interrupt disabled while reading and writing blocks; as a result it misses the hardware timer interrupts. That means the BIOS time keeping interrupt is not being invoked as often as it should, resulting in time slowing down. You will notice it acutely on benchmarks, and I had a note in the Wiki about it.

On other machines if the hardware timer interrupts have to be disabled for such a long period of time the code will read the timer value, disable interrupts, do it's work, and then adjust the timer value or invoke the BIOS time keeping interrupt the correct number of times to get things back to normal. The PCjr floppy BIOS is a good example of a machine where that is done.

Interrupts can probably be enabled while the port access to read and write the data register is going on, but that's an experiment for another day ...
Click to expand...
 
bettablue said:
I have a question regarding this. What if you have an onboard AST S-x-Pack Plus with clock/calendar enabled. I know you have to write a config sys and autoexec file that will load when you load DOS. This information came from the AST's documentation. Am I to take it from this that XTIDE will not give you or will lose that functionality from the AST? Can't you write an autoexec.bat and config.sys into whatever version of DOS your loading with XTIDE?.
Click to expand...
There are two clocks:
1. What I'll call the DOS clock (what you see when you use DOS' date and time commands), and
2. The Real Time Clock (RTC) on your SixPakPlus card.

Your AUTOEXEC.BAT file will include a line to run ASTCLOCK.COM
So at boot, ASTCLOCK.COM will read the date/time from the SixPackPlus RTC and set that into the DOS clock.

The slowing that is being spoken of is a slowing of the DOS clock. So for example, you observe that the DOS clock is correct at computer boot, but at the end of the day, you observe that the DOS clock has lost minutes (could be seconds - I'm guessing). Not much of a worry because the RTC on your SixPackPlus is unaffected (it ticks itself). It has the correct time, and when you next boot your computer, that correct date/time will be put into the DOS clock.

So no, use of the XT-IDE will not cause you to 'lose' the RTC functionality on your SixPackPlus. It will be there, but to utilise it, you'll need to add ASTCLOCK.COM and a modified AUTOEXEC.BAT (runs ASTCLOCK.COM) on your boot disks. If you boot from other disks, you'll find that the DOS clock is at its default (some date/time in 1980).
 
Modem7 - thanks, that was a great explanation for the non-techie.

As was pointed out earlier, the loss of accuracy on the DOS clock really only shows up if you are doing something disk intensive, like running benchmarks on the disk repeatedly. That is not going to be a problem for the vast majority of people unless you like to run a lot of disk benchmarks and are not aware of the loss of timer ticks.
 
You must log in or register to reply here.
Back
Top