Mail Archives: djgpp/2003/10/15/04:02:29
On 14 Oct 2003 07:31:02 -0700 in comp.os.msdos.djgpp,
ahenric AT ccii DOT co DOT za (Arne) wrote:
>Eli Zaretskii <eliz AT elta DOT co DOT il> wrote in message news:<ur81gkwy6 DOT fsf AT elta DOT co DOT il>...
>
>> > From: ahenric AT ccii DOT co DOT za (Arne)
>> > Newsgroups: comp.os.msdos.djgpp
>> > Date: 13 Oct 2003 23:54:00 -0700
>> >
>> > I am writing this application for MS-DOS only, and I am using the
>> > DJGPP compiler. Why does the timer not speed up when I change it? Does
>> > the DPMI server somehow prevent the change to the PIT? And from where
>> > is the SIGALRM signal called: from INT 08h or INT 70h?
>>
>> The DPMI server does not prevent you from reprogramming the timer.
>> In fact, there used to be a PCTIME14.ZIP file on SimTel (RIP) that
>> showed a working code that did what you intend.
>
>yes, I have tried PCTIME, but there again it just doesn't change
>anything. PCTIME will change the frequency, but the new handler will
>still call the original tick handler at the default frequency of
>18.2Hz.
Calling the original system tick handler at the default frequency
is required to keep the system timing facilities correct.
When you change the frequency, you may need to save the vector
for the system int 8 clock tick handler, then install your own
tick interrupt handler (_go32_dpmi_allocate_/_free_iret_wrapper
and _go32_dpmi_get_/_set_protected_mode_interrupt_vector: see
info example).
Your handler must then call the system tick handler thru the
saved vector (_go32_dpmi_simulate_fcall_iret) at the appropriate
rate.
That's one reason most code reprograms the timer to a binary
power: divides nicely into the original 65536 count.
IIRC Turbo C used to reprogram the divider to 256 and call the
system tick handler every 256 interrupts to keep the system time
correct.
For your purposes, a divider of 16384 would give you <5ms
resolution and calling the system tick handler every 4 calls to
your tick handler would keep the system time correct.
All code I have seen disables interrupts while setting the timer
divisor: try wrapping your divisor code in disable() and enable()
calls.
I turned up a note that timer mode 3 was used in early PCs, mode
2 has been used since ATs: you might want to try sending 0x34
instead of 0x36 to port 0x43.
IIRC original PC code needed NOPs between chip accesses to give
the chip time to do its work: you may have to allow a delay
between operations, unless current versions of the timer chip
delay the processor until each operation finishes.
You also have to dismiss the interrupt with outportb( 0x20, 0x20)
in your code every time you don't call the system tick handler.
You must also restore the normal divisor and saved int 8 vector
on any exit from the program, so you may need to disable/trap
ctrl-C (__djgpp_set_ctrl_c) and ctrl-break
(_go32_want_ctrl_break) interrupts, handle them during
processing, and restore them before exiting from your program.
This is all based on decades old assembler experience on original
PCs: some of this work may already be handled for you by DPMI, so
checking the info and source for the library timing routines,
go32, and maybe the DPMI code may save you a lot of work.
>Thats why I think the signal SIGALRM is called somehow always
>from this original handler. Any idea how to generate SIGALRM from my
>own handler? Will a signal only be generated when the handler returns?
Read the info notes for alarm() and under signal() at the bottom:
doesn't work under Windows9X, while within a DOS call, or in a
tight register loop that avoids memory.
You may also want to look at info on uclock().
It might also help if you described what overall goal you are
trying to achieve with this code.
Thanks. Take care, Brian Inglis Calgary, Alberta, Canada
--
Brian DOT Inglis AT CSi DOT com (Brian dot Inglis at SystematicSw dot ab dot ca)
fake address use address above to reply
- Raw text -