DJGPP - How to reprogram 8254 while calling the original handlers still at 18.2 Hz? \ VOGONS

DJGPP - How to reprogram 8254 while calling the original handlers still at 18.2 Hz?

Topic actions

First post, by PalMusicFan

PalMusicFan Offline

Rank Newbie

Rank: Newbie
Posts: 70
Joined: 2019-02-12, 03:28

In order to get an accurate and stable clock to play OPL2 BGM, I need to reprogram the 8254 to obtain a higher frequency int 8h.

However, after consulting a lot of information, it seems that this is quite cumbersome for DJGPP.

PCTIMER (https://technology.chtsai.org/pctimer/) seems to fully meet my requirements. After dealing with some minor issues, it compiled successfully.

However, I found that although the program seemed to be running, the real-mode handler named rm_new8h was not called at all, and the original BIOS handler was still called 1:1.

What is the problem? Thank you so much!

Reply 1 of 4, by zyzzle

Posted on Today, 11:29

zyzzle Offline

Rank Member

Rank: Member
Posts: 485
Joined: 2020-04-08, 04:02

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?

Reply 2 of 4, by PalMusicFan

Posted on Today, 11:58

PalMusicFan Offline

Rank Newbie

Rank: Newbie
Posts: 70
Joined: 2019-02-12, 03:28

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.

Reply 3 of 4, by BloodyCactus

Posted on 42 minutes ago

BloodyCactus Offline

Rank Oldbie

Rank: Oldbie
Posts: 1572
Joined: 2016-02-03, 13:34
Location: Lexington VA

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.

--/\-[ Stu : Bloody Cactus :: [ https://bloodycactus.com :: http://kråketær.com ]-/\--

Reply 4 of 4, by PalMusicFan

Posted on 18 minutes ago

PalMusicFan Offline

Rank Newbie

Rank: Newbie
Posts: 70
Joined: 2019-02-12, 03:28

BloodyCactus wrote on 42 minutes ago:

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.

Go to top of page Go to top of page

Back to DOS Games/Apps