Clock timer issue. See SPEEDSET in Deep Thought.

Ofcourse.. I should have mentioned that the games theirself run perfect. Midi timing is great, midi tempo isn't.

I've tried speedset ofcourse, though never gave it any thought because the games run just fine!

I'll speedset some more later this evening, maybe you're right.

Shame on me, speedset is the thing!

I seem to need to set it at 0.0053 for old dos playback.. THNX!

There just one thing, I get real small velocity/tempo changes in midisongs.. timing is perfect, overall tempo is overall perfect..

Is there more to speedset, maybe I should not set in prime numbers?

I can give a recording if u'd like..

Hm - hey Vlad - next version of Speedset: use external recording (wave file, midi), extract tempo using algorithms, attempt to automatically match it using Speedset?

😉

Complicated and more complicated.

Uh... it seems to me that having an audio file of the music would defeat the purpose of needing SPEEDSET in the first place. Especially since the sound rates VARY and aren't constant.

Sorry, I don't know really know anything about soundrates.. 🙁 I'm quite newbie at old games - midi related stuff. I also don't have the audio files you imply.. It was quite some work to make a dos recording of lsl5.. 🙁

I was just wondering if i'm doing something wrong.. the tempochanges are somewhat constant, so I just thought I was using speedset wrong..

Mainly because I've got no clue what this speedset does.. en why it requires an interrupt. Listening to this you'd think that speedset opens a thread and throttles cpu time, but it doesn't obviously.

this i've found somewhere else on the board.

The value you gove to SPEEDSET 1.0.1 is the number of "extra" interrupts per millisecond. SPEEDSET then spreads them out, computing the "ideal" interrupt rate, rounding it down to the closes millisecond period (closest kHz value). So every period the DOS stub will generate a number of INT8 (timer IRQs), which will vary up and down (+/- 1) as to achieve an accurate overall "interrupts per millisecond" value.

Maybe it doesn't spread the interrupts equally enough on my system

Snover wrote:

Uh... it seems to me that having an audio file of the music would defeat the purpose of needing SPEEDSET in the first place. Especially since the sound rates VARY and aren't constant.

Hm, that's true. Well, it was just an idea. But there should be some way for SPEEDSET to dynamically find a "proper" setting. It may be impossible, yes, but it should.

Stiletto wrote:

Hm, that's true. Well, it was just an idea. But there should be some way for SPEEDSET to dynamically find a "proper" setting. It may be impossible, yes, but it should.

Impossible. It would have been almost possible if there was a way for me to get the value at which the PIT was programmed and then assume that the most that Windows could do is 1kHz and provide the rest, but there is no documented way of getting the PIT start-count value.

V.

vladr wrote:

Impossible. It would have been almost possible if there was a way for me to get the value at which the PIT was programmed and then assume that the most that Windows could do is 1kHz and provide the rest, but there is no documented way of getting the PIT start-count value.

Damn. DOSBox logs it, I know...

Oh, and here's some lovely PIT-related links for you:
http://www.nondot.org/sabre/os/files/MiscHW/PIT.txt
http://www.microsoft.com/hwdev/platform/proc/mm-timer.asp

So, to rephrase the problem:
We have a MS-DOS 16-bit application that directly programs the PIT. We're now using Windows, and we'd like to intercept the value at which the PIT is programmed using a 32-bit TSR, but we don't know how to read the PIT start-count value. Is this possible?

Could be a good question for the guys at rec.games.programmer or comp.lang.asm.x86 or some place.

But, are you saying that they would just say, "it's technically impossible"?

So, like this then...
http://google.com/groups?selm=1994Oct31.09244 … ews.brandonu.ca

Or this?
http://google.com/groups?selm=2cb67nINN86l%40dns1.NMSU.Edu

Another very useful link:
http://www.qzx.com/pc-gpe/

Well, I don't know of any way of finding out what the "countodwn" (as opposed to the current) value is on a PIT. In a controlled environmnet (where you'd check the "current" value from the terminal count interrupt or read it in a tight loop and pick the largest value) yes, there are ways, but in a SPEEDSET environment I can't see any.

BTW, the "latch value" in the usenet post latches the *current* (not the countdown) value AFAIK. So I guess that the guy was in the Usenet post would hog the computer polling the counter value until he got the first non-zero value after zero. Can't really do that in NTVDM (SPEEDSET is supposed to speed up, not slow down games 😉 ).

V.

Okay. So we'll have to stumble upon the right settings... that's like finding a needle in a haystack...

Did some disassembling of ntvdm.exe, dunno if you can read any of it's local tables from within an vdd. But there's a table in there for the 3 PIT Timers each 0x74 bytes, and on location 0x28 in that table is the dword counter value.

Good thing you don't live in the US, Harekiet, since you just violated the DMCA! 😒

Oh dear god noooooooooo.

Harekiet wrote:

Oh dear god noooooooooo.

*ROFL* I wonder if we could violate the DMCA some more to improve Windows' DPMI support.

... anyhow, the EU should have some DMCA-like legislation on the books soon, although I would think a country's own laws could override them if they have laws about it...

... Vlad, any of this look useful?

So, in other words, do it faster? (Or move to Antarctica?)

Harekiet wrote:

Did some disassembling of ntvdm.exe, dunno if you can read any of it's local tables from within an vdd. But there's a table in there for the 3 PIT Timers each 0x74 bytes, and on location 0x28 in that table is the dword counter value.

I'm still curious if this is useful. Probably not, though...

Yes, I can read the thing from a VDD. And yes, that would be useful. Only problem would be getting those addresses right under all versions of NTVDM.EXE, though on second thought I could probably cycle through various values for the PIT when SPEEDSET starts up and scan NTVDM's address space for the changed values. Talk about the mother of all hacks. Will see.

V.