Date: Sat, 27 Sep 1997 09:44:17 -0700 (PDT)
Message-Id: <199709271644.JAA15953@adit.ap.net>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
To: cellis AT voyageur DOT ca, djgpp AT delorie DOT com
From: Nate Eldredge <eldredge AT ap DOT net>
Subject: Re: 16 to 32-bit
Precedence: bulk

At 09:18  9/26/1997 -0500, J.E. wrote:
>I'm trying to make a delay function for my game, but the one I'm going
>by is meant for a 16-bit compiler.  Here's the function:
>
>------------------------------------------------------------------------
>#include <stdio.h>
>#include <conio.h>
>
>void delay(int ticks);
>
>int main()
>{
>  int total = 0;
>  int ticks;
>  clrscr();
>  printf("Enter the number of clock cycles to delay: ");
>  scanf("%d", &ticks);
>  while (kbhit() == 0)
>  {
>    delay(ticks);
>    total++;
>    printf("\n  Tick --> %d", total);
>  }
>  return 0;
>}
>
>void delay(int ticks)
>{
>  unsigned long far *clock = (unsigned long far *)0x0000046CL;
>  unsigned long now;
>  now = *clock;
>  while (abs(*clock - now) < ticks) {}
>}
>------------------------------------------------------------------------
>
>Now, how do I convert this to 32-bit compatability for DJGPP?  Do I just
>remove the "far"'s in the clock pointer declarations and then change the
>pointer?  If so, what should the new pointer be?  A far pointer is just
><segment><offset>, right?  So, shouldn't that pointer also work in a
>32-bit environment like Djgpp?  Thanks in advance for all your time and
>help!!:-)
Not quite. The GNU C compiler doesn't support far (segment/offset) pointers
directly. You will need to use the _farpeek/_farpoke functions. Here's how I
would write `delay' to work with DJGPP:

void delay(int ticks)
{
   unsigned long start = _farpeekl(_dos_ds,0x0004C);
   while (abs(_farpeekl(_dos_ds,0x004C) - start) < ticks) ;
}

Don't worry about the overhead of _farpeekl's; they compile into two
instructions when you turn on optimization.
Btw, there is a libc function called `delay' which might conflict, and which
you could easily use instead. It takes its argument in milliseconds, which
would take a little scaling, but could be much more convenient.

Nate Eldredge
eldredge AT ap DOT net