May we test your compiled DJGPP binary? Or were you not able to compile the DJGPP version, and only got the real-mode timer compiled successfully?

zyzzle wrote on Today, 11:29:

May we test your compiled DJGPP binary? Or were you not able to compile the DJGPP version, and only got the real-mode timer compiled successfully?

OK, here is the sourcecode and the binary.

EDIT: testflag is always 0, which means the real mode handler is never called. Also, the time is very fast, which means the BIOS handler is still there.

your all sorts of convoluted. I dont think you need to do anything to the RM handler, hooking the PM handler should be enough (it is in watcom from what I remember).

The best thing to do is, keep count of your ticks, then when the program ends, set the date+time (which wont have changed) plus your ticks. This is the best way, because if you chain into the old handler you never know how expensive thats going to be (how long it will take), and you dont want to miss your own interrupts or get your behind in frame generation.

you also dont need the whole counter_reset thing. just inc your ticks++ and trigger EOI. keep your timer as short as possible.

BloodyCactus wrote on Today, 12:16:

your all sorts of convoluted. I dont think you need to do anything to the RM handler, hooking the PM handler should be enough (it is in watcom from what I remember).

The best thing to do is, keep count of your ticks, then when the program ends, set the date+time (which wont have changed) plus your ticks. This is the best way, because if you chain into the old handler you never know how expensive thats going to be (how long it will take), and you dont want to miss your own interrupts or get your behind in frame generation.

you also dont need the whole counter_reset thing. just inc your ticks++ and trigger EOI. keep your timer as short as possible.

The issue is, I would like to use stable high-frequency IRQ to play Ad Lib music and MIDI while using SDL. Currently, if the BIOS handler cannot be called at the default frequency, the time stamps in the log will be incorrect. I am not sure what other side effects there might be in SDL.

in that case you will have to approximate the calls. if you know your timer is 4x, then every 4th call, manually call the old handler and dont EOI (assume the old handler will EOI).

BloodyCactus wrote on 46 minutes ago:

in that case you will have to approximate the calls. if you know your timer is 4x, then every 4th call, manually call the old handler and dont EOI (assume the old handler will EOI).

Thank you so much!
Reporting the result of my recent tests. Manually calling the old handler in my custom protect mode handler seems to work, but I cannot block the old handler call. It seems that even if I set a new real mode handler, the BIOS handler is still being automatically called.

This is a piece of the code:

1      _go32_dpmi_get_protected_mode_interrupt_vector (8, &pm_old_handler);
2      pm_new_handler.pm_offset = (int) pm_new8h;
3      pm_new_handler.pm_selector = _go32_my_cs ();
4      _go32_dpmi_chain_protected_mode_interrupt_vector (8, &pm_new_handler);
5
6      _go32_dpmi_get_real_mode_interrupt_vector (8, &rm_old_handler);
7      rm_new_handler.pm_offset = (int) rm_new8h;
8      _go32_dpmi_allocate_real_mode_callback_iret (&rm_new_handler, &r1);
9      _go32_dpmi_set_real_mode_interrupt_vector (8, &rm_new_handler);
10