www.delorie.com/archives/browse.cgi   search  
Mail Archives: djgpp/1999/03/11/06:25:42

Date: Thu, 11 Mar 1999 11:04:34 +0200 (IST)
From: Eli Zaretskii <eliz AT is DOT elta DOT co DOT il>
X-Sender: eliz AT is
To: cyberian_front AT my-dejanews DOT com
cc: djgpp AT delorie DOT com
Subject: Re: djgpp w/: rhetorex / multi-voice...
In-Reply-To: <7c75mi$qmo$1@nnrp1.dejanews.com>
Message-ID: <Pine.SUN.3.91.990311110340.19994N-100000@is>
MIME-Version: 1.0
Reply-To: djgpp AT delorie DOT com
X-Mailing-List: djgpp AT delorie DOT com
X-Unsubscribes-To: listserv AT delorie DOT com

On Thu, 11 Mar 1999 cyberian_front AT my-dejanews DOT com wrote:

> Has anyone used dgjpp in such a manner?  There is source code for the
> multi-voice lib, and I've seen a c/c++ djgpp lib for xbase file i/o, but what
> about the multi-tasker?  It has to be able to drive 4/8/... lines.

It is very hard to give you a useful answer without knowing more
details.  In general, multi-tasking between different programs is very
hard to impossible to get in the DPMI environment required by DJGPP.
Of course, you could write a real-mode program that would multi-task
DJGPP applications.

If you need some kind of multi-threading inside a single program, that
*is* possible, but it depends on how hard the requirements for the
task switch latency are.

Other considerations include maximum sustainable hardware interrupt
rate (if it's too high, the overhead of interrupt handling and
reflection might kill you), and how much does the application call DOS
or BIOS (if it does many such calls, interrupt reflection might be a
major factor).

> I'd like not have to tell clients that machine xyz is to fast...

Having said all that, you might as well dig some more into the nature of
the problem, since it could well be that it will also happen with DJGPP.
For example, the board might be incompatible with the bus of the fast 
machine.

- Raw text -


  webmaster     delorie software   privacy  
  Copyright © 2019   by DJ Delorie     Updated Jul 2019