Board index » cppbuilder » DOS Interrupts, multiple files, and video memory...

DOS Interrupts, multiple files, and video memory...

Hello, I have three questions:

1)  How do I compile multiple *.cpp files together using the
command-line compiler that is part of the Builder 5 Enterprise package?
(Where only one cpp file has the main() function).  I want to know how
Builder and other IDEs work internally during the compilation stage
before I actually use the Windows IDE.

2)  How do I access the registers affected by the __int__ keyword?
__int__ is used in dos.h for geninterrupt.  Other than that, it isn't
documented anywhere in the Borland Help or Include files.  I want to
port one of my DOS applications over to the Borland compiler so I can
have access to Winsock functions.

3)  Using Borland, are there any special requirements/functions for
accessing the first 640K of memory?  I need to be able to access the
video memory directly under DOS for the program that I want to port.
Also, sample code to access the video memory area directly would be
highly appreciated (writing a single ASCII character to the screen is
fine).

Just in case you want to know what compiler I'm porting from, it is
DJGPP.  DJGPP has a lot of quirks that make it difficult to access
volatile RAM directly (mostly due to DPMI specifications and the way
DJGPP handles the 32-bit environment).  I have written several DJGPP
functions to make allocating and freeing up memory in the 640K barrier a
lot easier (acts more like malloc and free), but it is still a pain.
DJGPP also requires accessing DOS memory with a pre-defined selector and
functions that use that selector.  Avoiding any step results in a GPF.

Thomas Hruska

 

Re:DOS Interrupts, multiple files, and video memory...


Quote
> 1)  How do I compile multiple *.cpp files together using the
> command-line compiler

The whole pointof C and CPP is that you never compile multiple cpp files
together. Instead, the compilation of each C or CPP file is completely
independent.

Therefore: compile each individual cpp file on its own, and link together
the .obj files afterwards.
Actually, that's not true. That used to be the whole point. But yuckiness
like CPP's way of handling templates, means that compilation is no longer
naturally so independent. I don't know how these work.

--
Lucian

Re:DOS Interrupts, multiple files, and video memory...


Quote
"Lucian Wischik" <ljw1...@cam.ac.uk> wrote in message
> [snip]

Actually, if you've been using djpp, then I bet you already know all of this
better than I. In which case you should disregard everything I said.

--
Lucian

Re:DOS Interrupts, multiple files, and video memory...


The reason I asked the question is because I can compile the cpp files into OBJ
files but when I attempt to link them together, the linker complains of not
having main functions in the cpp files that do not contain them.  This baffles
me since that is how I know DJGPP works.

Thomas Hruska

Quote
Lucian Wischik wrote:
> "Lucian Wischik" <ljw1...@cam.ac.uk> wrote in message
> > [snip]

> Actually, if you've been using djpp, then I bet you already know all of this
> better than I. In which case you should disregard everything I said.

> --
> Lucian

Re:DOS Interrupts, multiple files, and video memory...


Quote
> 1)  How do I compile multiple *.cpp files together using the
> command-line compiler that is part of the Builder 5 Enterprise package?

Just string them along the command line:

bcc32 file1.cpp file2.cpp file3.cpp

bcc32 without any parameters list the help for it.

Quote
> 2)  How do I access the registers affected by the __int__ keyword?

You can't in Win32.

Quote
> 3)  Using Borland, are there any special requirements/functions for
> accessing the first 640K of memory?  I need to be able to access the

You can't in Win32.

+====================================================+
| Jonathan Arnold (mailto:jdarn...@buddydog.org)     |
| Havas Interactive             HyperStudio Engineer |
| http://www.buddydog.org http://www.hyperstudio.com |
+====================================================+

The Internet has proved that a million monkeys could not
replicate the works of Shakespeare - Robert Wilensky

Re:DOS Interrupts, multiple files, and video memory...


Borland Builder can only create 32-bit Windows applications (Console or GUI).
It can not create DOS applications at all. This means that anything related to
DOS such as INT 21h or the BIOS should be forgotten since neither is available
to your application.

Some of what DOS.H defines is still usable because it has been mapped onto the
equivalent Windows API function but generally alarm bells should ring whenever
you find yourself having to include "dos.h".

For applications there is only one linear address space. The concept of Real
memory or "the first 640kB" is nonsensical for code generated by Builder. You
can forget trying to access video memory directly.

Win32 is a protected environment and the code Builder generates is application
code. Such code is not allowed to mess about with hardware, any of the CPU's
control registers or indeed do anything  "device-driver(ish)". This protection
is handled by the CPU and the Kernel so don't think you can work around the
compiler by coding in assembler <g>.

You mention the function 'geninterrupt()'. This function is a classic example
of the kind of thing that application code is simply not allowed to do under
Win32. This is probably why it is so "poorly" documented. In truth it is
absolutely irrelevant for anyone using Builder.

FWIW Windows 9x does allow some of this kind of tomfoolery but that's only
because the Win32 platform for those OSes is incomplete to assist with
backward compatiblity. Neither WinN2 or Win2K will tolerate applications that
try to fiddle with the hardware or reprogram the CPU.

Andrue Cope
[Bicester, UK]

Re:DOS Interrupts, multiple files, and video memory...


Andrue,

Quote
You wrote:
> It can not create DOS applications at all. This means that anything
related to
> DOS such as INT 21h or the BIOS should be forgotten since neither is
available
> to your application.

I used to use interrupt driven functions to retrieve data from the serial
ports and populate a queue for the data to be processed by my program.  The
reason is that polling the port was much too slow even with the older uarts
and more data was dropped before being retrieved than was actually retrieved
and processed by my test program.  Interrupts were the only reliable means
of getting that data.

If, in win32, access to interrupts is not available, how do you attack the
problem?  Presumably one wants a separate thread to handle processing data
from the serial port which is kept suspended until there actually is data
available.  And one would want a mechanism to generate some kind of event
that the application can respond to in order to awaken the suspended thread
when there is data available (or if there is to be periods of an active
connection and periods without a connection, the event would be generated
only when an attempt is made to create a connection and the thread kept
alive during each session).

The problem is, if windows has the whole responsibility for handling
interrupts, how one tells windows to put data from the port into your
application's data queue (which would be a standard library container so it
can grow or shrink as required) whenever data is coming in through the
serial port (or parallel port or USB), and how does one generate the
required events as appropriate.

You might suppose, for the sake of argument, that I have an external device
connected at 56kbps and that generates and sends 1kB/s through the com port
every second.  How would one use the system interrupts to guarantee that
that data ends up in one's program's data queue?  What if the port is a
bidirectional parallel port or a USB (with correspondingly greater rates of
data creation and transmission)?

Just curious.  I do not now when someone may ask me to do real time data
collection and processing again.

Cheers

Ted
R.E. Byers
ted.by...@sympatico.ca

Re:DOS Interrupts, multiple files, and video memory...


Quote
> If, in win32, access to interrupts is not available, how do you attack the
> problem?  Presumably one wants a separate thread to handle processing data

A couple of ways:

1) Get a component to do the work.  Check out commercial products listed
on the Borland web site:
http://netserv.inprise.com/bcppbuilder/bcppbtools.html#comm

Shareware ones on Torry's:

http://www.torry.webnorth.com/comms.htm

Some freeware ones:

Brian Gile's TComThread: http://www.protogene.com/people/giles/builder.html
Harold Howe's TCommPort: http://www.bcbdev.com/components.htm
Dejan Crnila' ComPort: http://www2.arnes.si/~sopecrni/

2) Roll your own by using the Win32 CreateFile API.  Check out the win32.hlp
file (under "Communications"), as well as the following links:

http://msdn.microsoft.com/isapi/msdnlib.idc?theURL=/library/sdkdoc/wi...
http://www.traverse.com/people/poinsett/bcbcomm.html
http://www.temporaldoorway.com/programming/cbuilder/windowsapi/readin...
http://www.bcbdev.com/faqs/faq87.htm

+====================================================+
| Jonathan Arnold (mailto:jdarn...@buddydog.org)     |
| Havas Interactive             HyperStudio Engineer |
| http://www.buddydog.org http://www.hyperstudio.com |
+====================================================+

The Internet has proved that a million monkeys could not
replicate the works of Shakespeare - Robert Wilensky

Re:DOS Interrupts, multiple files, and video memory...


Quote
> If, in win32, access to interrupts is not available, how do you attack the
> problem?  Presumably one wants a separate thread to handle processing data
> from the serial port which is kept suspended until there actually is data
> available.

Using the CreateFile API, you can issue Asynchronous reads / writes to the
comm port, then wait on their completion.  This can, but doesn't have to be
done in a seperate thread. You have the option of using multiple buffers,
but this isn't necessary, as the driver will queue received data.

Re:DOS Interrupts, multiple files, and video memory...


Quote
> > If, in win32, access to interrupts is not available, how do you attack
the
> > problem?  Presumably one wants a separate thread to handle processing
data
> > from the serial port which is kept suspended until there actually is
data
> > available.

> Using the CreateFile API, you can issue Asynchronous reads / writes to the
> comm port, then wait on their completion.  This can, but doesn't have to
be
> done in a seperate thread. You have the option of using multiple buffers,
> but this isn't necessary, as the driver will queue received data.

I had seen this API, but was wary of it because it looked too much like the
polling functions that could be used on DOS.  Does the driver it uses depend
on interrupts to retrieve data and put it into an internal buffer?  Does the
function consume any processing resources while waiting on data to be
received from the com port?  Does the program that interacts with the com
port take ownership of it, so only it can read and write on it until it
closes it?

Ted

Re:DOS Interrupts, multiple files, and video memory...


Quote
> I had seen this API, but was wary of it because it looked too much like
the
> polling functions that could be used on DOS.  Does the driver it uses
depend
> on interrupts to retrieve data and put it into an internal buffer?

The driver may depend on interrupts, depending on the device.  In any case,
these are not available to you, for direct use unless you want to code on a
driver level.
Yes, the driver will buffer the input.

 Does the

Quote
> function consume any processing resources while waiting on data to be
> received from the com port?

Here, I assume you mean your program vs the driver.  Neither will consume
resources while waiting for input.

Quote
>oes the program that interacts with the com
> port take ownership of it, so only it can read and write on it until it
> closes it?

When you open or create the file, you get a Handle to it.  Your program
controls the device until you close the handle.  I don't believe that
sharing the device with other programs is an option.

Re:DOS Interrupts, multiple files, and video memory...


Thanks Pete,

Quote
"Pete Pedersen" <engrp...@spiricon.com> wrote in message

news:3a1431d9$1_2@dnews...
Quote
> > I had seen this API, but was wary of it because it looked too much like
> the
> > polling functions that could be used on DOS.  Does the driver it uses
> depend
> > on interrupts to retrieve data and put it into an internal buffer?

> The driver may depend on interrupts, depending on the device.  In any
case,
> these are not available to you, for direct use unless you want to code on
a
> driver level.
> Yes, the driver will buffer the input.

Since my concern was regarding the com ports, and maybe parallel and USB
ports, I would expect that the drivers would depend on interrupts, since
polling the ports is too slow and wastes too much processing resources.

I do not really want to handle interrupts myself.  I had to deal with that
to get my application to work on DOS, but if that is all handled reliably by
this API, then this is one aspect of programming automated data collection
much simpler, and I am quite happy to have MS programmers deal with such low
level programming issues.  All that matters is that I can get my data
reliably without wasting cycles.

Thanks for the info.

Ted

Re:DOS Interrupts, multiple files, and video memory...


Hello All,

Quote
Ted Byers wrote:
> Just curious.  I do not now when someone may ask me to do real time data
> collection and processing again.

Frankly you don't :-( As others have said Windows deal with all the data by
interrupts, buffering it for you and providing an cycle-efficient interface to
it, just like a real operating system should. This, of course, is why the
application programmer should *not* try to access the port directly as it will
interfere with Windows' own management of the port. The trouble is that Windows
is not a realtime operating system and as such doing realtime data collection
is, under many circumstances, not reliable. It can be done, with great care and
by applying strict operating constraints. Things such as the user innocently
starting another application can mess things up completely, and Windows does
have a habit of doing unexpected things at unexpected times. All versions do
this, more so with NT variants which are inherently more complex, and hence
unpredicatable in terms of timing than 95/98/ME. If you really want to do true
realtime then Windows, any version, is not the operating system to choose. If
you want to do psuedo-realtime, as I do, then Windows 95/98/ME can be coaxed
into behaving itself enough to be usable, most of the time.  Getting NT
(3.5x/4/2000) to co-operate is quite another matter. Furthermore NT gives you
even less control over the hardware than 95/98/ME, that combined with its hidden
workings makes it a very poor realtime platform.

That said, for most applications involving serial data Windows should be fine.
Its when you get up to faster data rates, as in my case where I take data in in
realtime through a PCI parallel port, where the problems really start. Hardware
considerations also come into play - for example I found that with PCI based
video my data transfer would be mucked up if I moved a form (as that involved a
lot of processor-video card data transfer that in turn messed up the all
important incoming data transfer). The solution was to change to AGP video, as
that left the main PCI bus relatively free. Realtime is not just about the
choice of operating system.

--
Bye,
Chris Boyce
Technical Development Engineer
Titan Environmental Surveys Ltd
c/o Isle of Wight Radio
8 Dodnor Park
Newport
Isle of Wight
PO30 5XE
Tel/Fax: 01983 532089
email: tal...@globalnet.co.uk or chris.bo...@titansurveys.co.uk

Re:DOS Interrupts, multiple files, and video memory...


Hi Chris,

Quote
"Chris Boyce" <tal...@globalnet.co.uk> wrote in message

news:3A150FDD.B5F0AB1@globalnet.co.uk...
Quote
> Hello All,

> Ted Byers wrote:

> > Just curious.  I do not now when someone may ask me to do real time data
> > collection and processing again.

> Frankly you don't :-( As others have said Windows deal with all the data
by
> interrupts, buffering it for you and providing an cycle-efficient
interface to
>[snip]
> That said, for most applications involving serial data Windows should be
fine.
> Its when you get up to faster data rates, as in my case where I take data
in in
> realtime through a PCI parallel port, where the problems really start.
Hardware
> considerations also come into play - for example I found that with PCI
based
> video my data transfer would be mucked up if I moved a form (as that
involved a
> lot of processor-video card data transfer that in turn messed up the all
> important incoming data transfer). The solution was to change to AGP
video, as
> that left the main PCI bus relatively free. Realtime is not just about the
> choice of operating system.

So, in short, if someone asks me to do real time data collection again, I
ought to ensure I can do it using an OS designed for the job, and make sure
they have a competent hardware engineer.  The ones responsible for the
custom hardware my application was supposed to run on took several months to
get each new prototype to me, and the firt one he trashed because he
miswired the serial port connector metween a touch screen and the
motherboard.  He fried the touchscreen.  When he replaced it, he didn't
bother to check, let alone replace, anything else, so I saw strange
behaviour in my app until I figured out the motherboard had been damanged
(the program worked once he sent a unit with all new components).  And HE
was upset when the tech support for the touchscreen he fried yelled at him
and asked if he knew what a serial port is.  I would probably have done more
thanyell at him.  He wasted too much of my time since I had to diagnose a
problem with his hardware that HE ought to have seen.  I am certain he would
have been unable to handle the sort of hardware issues you mention.  Since I
normally don't deal with such low level programming, I'd need someone like
you to point out hardware issues like this.

Thanks,

Ted

Re:DOS Interrupts, multiple files, and video memory...


Quote
Ted Byers wrote:
> So, in short, if someone asks me to do real time data collection again, I
> ought to ensure I can do it using an OS designed for the job, and make sure
> they have a competent hardware engineer.

Yes, that all sounds like a good idea :-)

Quote
>  The ones responsible for the
> custom hardware my application was supposed to run on took several months to
> get each new prototype to me, and the firt one he trashed because he
> miswired the serial port connector metween a touch screen and the
> motherboard.  He fried the touchscreen.

<snip>

Quote
> He wasted too much of my time since I had to diagnose a
> problem with his hardware that HE ought to have seen.  I am certain he would
> have been unable to handle the sort of hardware issues you mention.  Since I
> normally don't deal with such low level programming, I'd need someone like
> you to point out hardware issues like this.

I started out as a test engineer - mainly prototype work, sorting out the fouls
ups the design engineers had missed and swept under the carpet. I'd always been
computer literate, and software, both low and high level, has always been
important to me. I now work as a systems engineer - essentially pulling together
hardware, software and the user into a single unified system. There are issues
such as the one I described which are require hardware fixes to what can be seen
as a software problem. I also ensure the team I work with works as a *team* -
all pulling together to get the system as a whole working properly, not just
their individual bits of it. As such the old hardware/software divide, and the
mindset it engenders, is more of a hinderance than a help.

On a more practical note raw processing power can help to mask a lot of the
potential pitfalls of realtime working. If your processor is fast then it often
makes the job easier, and indeed possible on systems such as Windows. However,
even in this day of 1+GHz clock rates, there are times when I feel like
{*word*242} folks who suggest that getting (what they don't know is) realtime
systems to work under Windows is easy, just because they see all programming as
'easy'. Since the PC the art of realtime systems development has been largely
lost, and the availability of realtime operating systems severly limited (QNX,
rtLinux and....). Realtime hardware simply doesn't exist anymore, and the PC
architecture's severely limited interrupts make realtime  royal pain in the
*%$!

--
Bye,
Chris Boyce
Technical Development Engineer
Titan Environmental Surveys Ltd

Go to page: [1] [2]

Other Threads