Animation with int 21h ah=2ch

[amrac]

Yes, It does work faster. The first procedure is too slow even if I put it to work at the fastest it can get. And it has much less code.

[MichaelW]

lol - that is some old-timie stuff, Michael
how old are you, anyways ?

I first noticed the technique when I was examining some BIOS code. I think it was code that operated the diskette or hard drive. I'm half way to 118, so I'm approaching middle age :lol

Do you have a correction for the "NT versions"?

I never considered trying to derive a correction. For a delay value of 20000, on my Windows 2000 system it delays for ~6990ms. So applying a correction factor of 3, for a delay value of 60000 it delays for ~20900ms.

[FORTRANS]

Hi,

   Well, Michael's routine does perform differently on different
systems.  So, before using it one should probably run some
checks or a calibration.  My Windows 2000 performs like
Michael's, about 3x.

   On two machines running DOS it runs pretty well as posted.
For a 15 second delay, one was 15 seconds or just over. the
other one was a second or two slow.

   On an PC/XT compatible it just locks up as expected as
that port changed on the PC/AT.

   On two OS/2 VDM's, one ran 2x and one was 7x.  (?)
May have to retry that one with a cold boot.

   The Int 15H wait function 86H does not work on the
Windows 2000 and PC/XT machines and returns immediately.
The rest ran okay.

   It is nice that Michael's routine works on Win2k, where the
Int 15 wait does not.  And it provides significantly shorter
delays than the ones I was using there to get around Int 15
not working.

Thanks,

Steve N.

[amrac]

With int 21h and ah equal to 2ch I get the milliseconds in al. But I find this strange because I can only have a maximum value of 255 milliseconds. Is this correct?

[dedndave]

those are probably 100th's of a second (0-99)
as a side-note - the dos clock updates 18.2 times per second, so the hundredths do not step "evenly"
the hundredths skips over several values on each clock tick (it doesn't count 1,2,3,4...)

[sinsi]

AL isn't a return value -

Code Select Expand


INT 21 - DOS 1+ - GET SYSTEM TIME
AH = 2Ch
Return: CH = hour
CL = minute
DH = second
DL = 1/100 seconds
Note:   on most systems, the resolution of the system clock is about 5/100sec,
so returned times generally do not increment by 1
on some systems, DL may always return 00h


[MichaelW]

For Function 2Ch, Get Time, the documented (in the Microsoft MS-DOS Programmer's Reference) return values are:

CH = hour in 24-hour format
CL = minutes (0 to 59)
DH = seconds (0 to 59)
DL = hundredths of a second (0 to 99)

Running under Windows 2000, on return AL is always zero, and the value in DL changes in increments of 5 or 6 counts so the resolution is effectively the period of the timer tick ~ 55ms. The code that generated this displayed the return values each time the value in DL changed:

Code Select Expand


AL CH  CL  DH  DL
0  19  10  41  78
0  19  10  41  83
0  19  10  41  89
0  19  10  41  94
0  19  10  42  0
0  19  10  42  5
0  19  10  42  11
0  19  10  42  16
0  19  10  42  22
0  19  10  42  27
0  19  10  42  33
0  19  10  42  38
0  19  10  42  44
0  19  10  42  49
0  19  10  42  55
0  19  10  42  60
0  19  10  42  66
0  19  10  42  71
0  19  10  42  77
0  19  10  42  82


To get a higher resolution you need to access a counter that runs faster than the system timer tick. Running under Windows you have only a limited number of choices.