any help greatly appreciated.

Var Timer18:Integer absolute $0040:$006C;

Function GetSpeed : Longint;
Var SavTimer : Integer;
    Cntr     : Longint;
Begin
  Cntr := 0;
  SavTimer := Timer18;
  Repeat Until SavTimer <> Timer18;
  SavTimer := Timer18;
  Repeat
    Inc(Cntr);
  Until SavTimer <> Timer18;
  GetSpeed := Cntr;
End;

The first repeat .. until loop waits until the second changes and the
second loop increments Cntr until the second changes again. You now have
a Cntr longint variable that tells you, reasonably accurately under DOS,
how many increments of Cntr took place in one second. This should give
you the relevant information on how much to delay:

if Cntr =  2000 then delay for period of time 10
if Cntr =  4000 then delay for period of time  5
if Cntr = 20000 then delay for period of time  1
etc.

The loop itself will indeed take some time. It may be preferable to add
a number of NOP statements within the second repeat loop.

For TP6 and 7 use
asm
   nop;  {as many as you want}
end;

For TP5 and 5.5 use
inline($90); {again as many as you want}

--
Pedt Scragg

Actually, it would be better in principle to have Timer18 a word or a
longint, if it is used elsewhere (though here, a byte will do); and one
can use a pointer for DPMI work.

Alas, I cannot now examine the code produced by BP from Pascal in News
as readily as before.

In either case relative timings (to a known machine and video card) will
probably suffice; you probably don't need absolute timing figures.

Jay
--

I made some testing of the posted code. Unfortunately, it turned out
give too volatile results. I also tried averages. The range of the
results varied from (a scaled) 100.0 to 200.0. This I have to take
as "problem not actually yet solved".

I say this only constructively! It would have been nice to have this
as a FAQ, but it is not ripe yet.

   All the best, Timo

....................................................................
Prof. Timo Salmi   Co-moderator of news:comp.archives.msdos.announce
Moderating at ftp:// & http://garbo.uwasa.fi/ archives 193.166.120.5
Department of Accounting and Business Finance  ; University of Vaasa
mailto:t...@uwasa.fi <http://www.uwasa.fi/~ts/>  ; FIN-65101,  Finland

It has been written with TP7.0. Execution time is hardly noticable.
The routine uses PIT counter 2 at port 0042h. It allocates memory (about
64 kB) and fills that with CLCs (Clear Carry Flag), an instruction that
*always* takes 2 cycles and that is not affected by Pentium's U- nor
V-pipe, on Intel and AMD processors. Unfortunately it does not work well
with Cyrix processors, it gives a value about 3 times too high.

Here's the code. Near label @Timer2 the DBs and DW form the instruction
CALL FAR [CS:@SUBR], which unfortunately cannot be entered as assembly.

Kind regards,
Wouter Ras.

-----------------------------------------------------

In pure DOS, I do believe that one can get meaningful results; though if
you have, say, a modern portable with resident code monitoring whether
either the battery or the user appears to be exhausted, or maybe one of
those PCs with non-independent Video RAM whose effective speed is
affected by the picture scanning, ...

There's a *bit* at my  http://www.merlyn.demon.co.uk/pas-time.htm#Misuse

I believe it is not possible to obtain any accurate indication of cpu
speed since, from 8088 processors, the instruction queue will
introduce errors into any loop type estimation procedure. Thing have
become even worse with the implementation of internal and external
caching. If you look at the instruction list for any cpu, you will
notice a range of clock cycles quoted for every instruction. The
situation for PCs is not the same as it was in the days of the Z80
where timing could be accurately calculated from the instructions
executed. Instruction counting loops are just not accurate of which
you should already be aware. The delay procedure in the CRT unit is
the best example and everyone knows that is not very accurate at all
(no matter what machine).

On the subject of graphics performance, I know from experience that
above a certain processor speed (eg, 386SX-16) video card band-width
will be the {*word*109} performance factor. By way of explanation, I
wrote a procedure which updated a small window at the rate of 25 per
second. The procedure runs absolutely flat out with no delays or
adjustments for the cpu and it appears exactly the same on my new
K6-255 as it did on the 386SX-16 because I am using the same 16bit ISA
video card.

I submit this for your consideration and appologise for not having a
worthwhile suggestion for a solution.