DOS4GW and PCI Serial card on IRQ9
Bryan Beresford-Smith
successfully using COM1 and COM2 to support serial communications. I have
installed my own interrupts using _dos_setvect etc..
Recently I have had to incorporate another serial port (i.e a third serial
port) in the application.
To do this I have to use a PCI card with a serial port (since EISA cards
can't be used on any new PC :) ).
I am currently trying to use a board from Sunix (4028d) which automatically
remaps its IRQ.
It reports, for example, that it is using COM3 and IRQ9. Using the same
method as I use for COM1(IRQ4)
(including using _dos_setvect) but taking care with masks and EOIs for the
second interrupt controller I can
get the serial interrupt to work BUT ONLY AT VERY SLOW SPEEDS (e.g. 300
baud)
and even then not all the time. Above this speed it always crashes the DOS
machine.
What is going on?
I notice in a posting on 30/05/02 there was a discussion of PCI bridge
interrupts where Stephen Howe wrote:
"DOS4GW has some automatic support for IRQ's 0-7 (via _dos_setvect(), they
then become passup interrupts) but not IRQ 8-15. This is why the game DOOM
supports only IRQ 0-7 for sound cards. However you can manually install
interrupt handlers for both sets of interrupts and it will then work."
What is meant by "manually install". How would I do it? Would it fix my
problem?
Does Causeway have support for IRQ8-15? What about the DOS 32 extender?
Any help/sample code would be much appreciated.
Bryan
Stephen Howe [TeamSybase]
"Bryan Beresford-Smith" <bry...@dragon.net.au> wrote in message
news:BC8q395...@forums.sybase.com...
It means that you use the DPMI calls and not _dos_setvect(). I don't trust
the _dos_setvect() method because DOS4GW is doing things under the hood
which are DOS4GW extensions and nothing to do with the DPMI 0.9 standard. If
you use _dos_setvect(), DOS4GW auto-passes up interrupts in the range 8h-2Eh
excluding 21h
> How would I do it?
Install a real mode and protected mode handler, so bimodal. Doing this would
mean you would get the fastest response from DOS4GW programs. You probably
want to allocate some DOS memory for a buffer that both handlers would have
access to.
>Would it fix my problem?
Yes, I think so.
> Does Causeway have support for IRQ8-15? What about the DOS 32 extender?
Yes Causeway does. Here we come to what I regard as an anomaly in the DPMI
standard. If you read parts of the DPMI standard, it suggests that for any
hardware interrupt, the protected mode handler gets first access, always
(even if execution is currently in real mode). But other parts of the
standard indicate that bimodal interrupt handling is possible for hardware
interrupts.
To me, I don't see how these two passages are resolved. If the protected
mode handler always get the interrupt first, why bother installing a real
mode handler? For that matter, how is bimodal handling possible if the
protected mode handler always get the interrupt first?
What it seems to me is that different DOS Extenders go different ways on the
above. And so they do. So DOS4GW supports bimodal interrupt handling whereas
for Causeway, you just need to install a protected mode handler. This does
mean Causeway is potentially slower.
> Any help/sample code would be much appreciated.
Well see PGUIDE.HLP where it talks about bimodal interrupts and gives code
for a bimodal interrupt handler
Stephen Howe [TeamSybase]
London, UK
Bryan Beresford-Smith
Stephen Howe [TeamSybase] wrote in message ...
>Install a real mode and protected mode handler, so bimodal. Doing this
would
>mean you would get the fastest response from DOS4GW programs. You probably
>want to allocate some DOS memory for a buffer that both handlers would have
>access to.
>
I have always tried to avoid writing bimodal interrupt handlers! When I
looked at the documentation
some time ago it seemed that I had to write these in assembler (is that
true?), basically duplicating
the protected mode handler in real mode. I like to stay with C/C++ as much
as possible :)
>What it seems to me is that different DOS Extenders go different ways on
the
>above. And so they do. So DOS4GW supports bimodal interrupt handling
whereas
>for Causeway, you just need to install a protected mode handler. This does
>mean Causeway is potentially slower.
QUESTION: If I did go to the trouble of writing real/protected mode handlers
for DOS4GW would they both
be used in appropriately Causeway (and perhaps speed up its response) or
would the protected mode
handler always be called?
I have now tested CauseWay on my code.
It was very nice to see the code for my IRQ9 start working (and at 115200)!
I also tested the NOVM option and full use of the available memory (the
restriction to 32MB for
DOS4GW was becoming tiresome now that it is hard to GET less than 256MB on
new PCs these days!).
(Thanks to Michael Devore for making Causeway available).
To use Causeway with the Watcom IDE (under WIndows 98) I used a method
mentioned in a couple of posts
(I repeat it here since it took a while to find it!) i.e.
1. Follow the Causeway notes on installation (Copy relevant causeway files
into binw, edit wlsystem.lnk etc.)
2. In IDE (having selected DOS 32 bit and DOS4GW) change linker option for
system from dos4g to CauseWay.
SMALL QUESTION: If I use target/run in the IDE it seems to run as a dos4gw
executable, not Causeway. Is that true? Anyway to change that?
Unfortunately, a couple of minor things now fail in my program when running
under Causeway
(but never before under DOS4GW).
These are quite probably my fault, but I mention them here in case there is
a simple reason for my problems.
If there isn't I don't want to waste anyone else's time!:
1. When running the DOS program under Windows 98, the system date gets set
back to 1980!
In my program I do try to change the date on a file using DOS function
utime() which seems to
be causing the problem.
Is there a problem with using some DOS functions in Causeway to do this
sort of thing?
On a pure DOS machine the system date isn't changed.
2. On a pure DOS system, the program runs fine but after exiting the program
it won't even start up again
and sometimes the PC reboots. I changed main() to use exit(0) as in the
Causeway documentation.
Perhaps I am not uninstalling some interrupt handlers properly?
Once again, thanks Stephen.
Bryan
Stephen Howe [TeamSybase]
> looked at the documentation
> some time ago it seemed that I had to write these in assembler (is that
More or less. You would need to write the 16-bit handler in assembler.
Iimagine it is theoretically possible to do a 16-bit handler in C, compile
using WCC and then link with the other 32-bit DOS object files. I have never
tried this so I don't know what problems (if any) you would face. Possibly
none.
> QUESTION: If I did go to the trouble of writing real/protected mode
handlers
> for DOS4GW would they both
> be used in appropriately Causeway (and perhaps speed up its response) or
> would the protected mode
> handler always be called?
The protected mode handler would always be called. So there would be no
point writing a RM handler. In some ways, this is nicer for the programmer
as they could write a PM handler in C/C++ and not worry. By default, this is
what happens
Causeway:
Execution in PM when asynchrous interrupt occurs:
Mode switch => default PM handler called => Causeway kernel does mode
switch => default RM handler called
Execution in RM when asynchrous interrupt occurs:
default PM handler called => Causeway kernel does mode switch => default RM
handler called
If you install your own PM handler, it will be called and the above sequence
called if you chain the interrupt. If you don't bother chaining the
interrupt, you will need to inform the PIC that the interrupt has been
serviced (which is what the RM handler would have done).
DOS4GW:
Execution in PM when asynchrous interrupt occurs:
default PM handler called => Tenberry kernel does mode switch => default RM
handler called
Execution in RM when asynchrous interrupt occurs:
default RM handler called
Now if you install PM and RM handlers and do not chain in either you have
bimodal handling. If you do chain, I don't see the point in installing a PM
handler, just do RM only. If you do chaining, then installing a PM handler
only, under DOS4GW that is bad news as you will miss interrupts that occur
when the processor is executing in RM.
I hope this all makes sense :-). To me, the optimal strategy revolves round
whether you wish for the previous handler to handle the interrupt or not.
If you are chaining to the previous handler:
1) For Causeway and DOS4GW install a RM handler. The RM handler will always
get your interrupt.
2) For Causeway only, install only a PM handler
If you are not chaining to the previous handler:
1) For Causeway install only a PM handler.
2) For DOS4GW install a PM handler and a RM handler. Both are necessary.
Bimodal handling. Failure to install both menas you will lose interrupts.
> I have now tested CauseWay on my code.
> It was very nice to see the code for my IRQ9 start working (and at
115200)!
Well it should work at that spped with DOS4GW providing you follow the notes
above.
> I also tested the NOVM option and full use of the available memory (the
> restriction to 32MB for
> DOS4GW was becoming tiresome now that it is hard to GET less than 256MB on
> new PCs these days!).
> (Thanks to Michael Devore for making Causeway available).
Yes. To date, DOS4GW and family have never been updated to use XMS 3.0
instead of XMS 2.0 standard. That means that even Tenberry's
top-of-the-range extender DOS4G will only ever see 64Mb, the liimit of what
can be allocated using XMS 2.0.
Causeway uses XMS 3.0 which means all 4Gb is potentially available.
> To use Causeway with the Watcom IDE (under WIndows 98) I used a method
> mentioned in a couple of posts
> (I repeat it here since it took a while to find it!) i.e.
> 1. Follow the Causeway notes on installation (Copy relevant causeway files
> into binw, edit wlsystem.lnk etc.)
> 2. In IDE (having selected DOS 32 bit and DOS4GW) change linker option for
> system from dos4g to CauseWay.
>
> SMALL QUESTION: If I use target/run in the IDE it seems to run as a dos4gw
> executable, not Causeway. Is that true? Anyway to change that?
Are you sure you are not running the DOS debugger BINW\WD.EXE? That is
DOS4GW executable itself and you will see the startup banner. If you are not
running this, it must be something to do with the stub. It must be linking
in WSTUB which calls DOS4GW.
I will have to try this myself.
> Unfortunately, a couple of minor things now fail in my program when
running
> under Causeway
> (but never before under DOS4GW).
> These are quite probably my fault, but I mention them here in case there
is
> a simple reason for my problems.
> If there isn't I don't want to waste anyone else's time!:
> 1. When running the DOS program under Windows 98, the system date gets set
> back to 1980!
No idea why this is.
> In my program I do try to change the date on a file using DOS function
> utime() which seems to
> be causing the problem.
> Is there a problem with using some DOS functions in Causeway to do
this
> sort of thing?
Should not be. I would need to examine this. Do you have some test code that
demonstrates the problem.
> On a pure DOS machine the system date isn't changed.
>
> 2. On a pure DOS system, the program runs fine but after exiting the
program
> it won't even start up again
> and sometimes the PC reboots.
Then in that case, the program is unstable. You have a problem somewhere, it
should not happen.
> I changed main() to use exit(0) as in the
> Causeway documentation.
> Perhaps I am not uninstalling some interrupt handlers properly?
Well that is a possibility. If you have _dos_setvect, you should use
_dos_getvect first, record the old handler and make sure you reset it no
matter what when your program terminates, normally or abnormally. Are you
doing that?
Bryan Beresford-Smith
>Well that is a possibility. If you have _dos_setvect, you should use
>_dos_getvect first, record the old handler and make sure you reset it no
>matter what when your program terminates, normally or abnormally. Are you
>doing that?
I have my own interrupt handlers for up to 3 serial ports, for the keyboard
and for the mouse.
For all of these, except for the mouse, I do use _dos_getvect and a restore
of the vector at program end (perhaps not at abnormal termination although I
do have an at_exit function to restore the video mode).
Perhaps the mouse is the problem. I have used the "mouse with dos4gw"
example in Watcom help to
set up mouse calls using interrupt 0x33.
In any case, suppose prm.exe is the program as linked with Causeway (from
the IDE as explained before).
Then on a pure DOS machine I can run the program multiple times using
dos4gw prm.exe
and all works fine.
If I run just the causeway executable
prm.exe
then it works fine the first time, but after that it won't run again using
either method and locks up the machine.
I'll keep looking for the problem - I don't want to waste your time if
nothing springs to mind.
So far I can't get a simple example to fail in the same way.
Peter Shaggy Haywood
14:43:56 -0000 in powersoft.public.watcom_c_c++.general.
Re: DOS4GW and PCI Serial card on IRQ9's a cool scene! Dig it!
>> To use Causeway with the Watcom IDE (under WIndows 98) I used a method
>> mentioned in a couple of posts
>> (I repeat it here since it took a while to find it!) i.e.
>> 1. Follow the Causeway notes on installation (Copy relevant causeway files
>> into binw, edit wlsystem.lnk etc.)
>> 2. In IDE (having selected DOS 32 bit and DOS4GW) change linker option for
>> system from dos4g to CauseWay.
>>
>> SMALL QUESTION: If I use target/run in the IDE it seems to run as a dos4gw
>> executable, not Causeway. Is that true? Anyway to change that?
>
>Are you sure you are not running the DOS debugger BINW\WD.EXE? That is
>DOS4GW executable itself and you will see the startup banner. If you are not
>running this, it must be something to do with the stub. It must be linking
>in WSTUB which calls DOS4GW.
Nope, it neither runs the debugger nor links in the DOS4GW stub.
When run from the IDE with Target->Run (or Ctrl+R) Causeway programs
are explicitly executed with DOS4GW.EXE, but when run outside the IDE,
or when run from the IDE using Actions->Run..., they are run without
DOS4GW.EXE.
That's interesting! Sounds similar to a problem I've had. Bryan,
does your DOS machine load a driver for a sound card that emulates a
Sound Blaster, by any chance? Do you get this behaviour when running a
simple "Hello, World!" program?
>Then in that case, the program is unstable. You have a problem somewhere, it
>should not happen.
Not necessarily, Stephen. Don't you remember the problem I've
reported? Even the simplest programs with absolutely no coding errors
unceremoniously reboot the system; eg.:
#include <stdio.h>
int main(void)
{
puts("Hello, World!");
return 0;
}
Hell, even this one does the same:
int main(void)
{
return 0;
}
Bryan Beresford-Smith
>When run from the IDE with Target->Run (or Ctrl+R) Causeway programs
>are explicitly executed with DOS4GW.EXE, but when run outside the IDE,
>or when run from the IDE using Actions->Run..., they are run without
>DOS4GW.EXE.
>
Thanks for that.
I think I have isolated my date being set to 1980 problem in win98 to my
own faulty mouse handler.
It might be due to re-enabling inputs too early and getting a reentrant call
to the handler.
I haven't figured out the exact details yet.
> That's interesting! Sounds similar to a problem I've had. Bryan,
>does your DOS machine load a driver for a sound card that emulates a
>Sound Blaster, by any chance? Do you get this behaviour when running a
>simple "Hello, World!" program?
>
I think the reboot problem also turns out to be my fault (introduced during
debugging the mouse handler) but
I still can't run the program a second time on a pure DOS machine. I do not
have
a sound card in use and as yet I have no simple example. If I can isolate
the problem
into a simple example I will post it here. The difference in behaviour
between dos4gw and causeway on
exactly the same program is interesting.
Thanks for your help.
Stephen Howe [TeamSybase]
> does your DOS machine load a driver for a sound card that emulates a
> Sound Blaster, by any chance? Do you get this behaviour when running a
> simple "Hello, World!" program?
>
> >Then in that case, the program is unstable. You have a problem somewhere,
it
> >should not happen.
>
> Not necessarily, Stephen. Don't you remember the problem I've
> reported? Even the simplest programs with absolutely no coding errors
> unceremoniously reboot the system; eg.:
>
> #include <stdio.h>
>
> int main(void)
> {
> puts("Hello, World!");
> return 0;
> }
>
> Hell, even this one does the same:
>
> int main(void)
> {
> return 0;
> }
Yes I do remember that vaguely now that you prompt me.
This was on the OpenWatcom news server, yes?
Remind me what happened.
Peter Shaggy Haywood
19:53:27 -0000 in powersoft.public.watcom_c_c++.general.
Re: DOS4GW and PCI Serial card on IRQ9's a cool scene! Dig it!
>> That's interesting! Sounds similar to a problem I've had. Bryan,
Yeah, I think I did mention it over there.
>Remind me what happened.
Any Causeway program made with Watcom (I'm still using 10.6 - I'll
get OW before too much longer and see if that still causes problems),
including those above, reboots the machine instantly if run from
vanilla DOS, and causes icons and other window elements to be messed
up if run from a Windows DOS box. And all this occurs only if I have a
DOS driver (a Sound Blaster emulator, really) for a Vibra 128 sound
card loaded. Removing the driver from autoexec.bat (where it is loaded
from) and rebooting stops the behaviour. So the simple solution is to
remove the driver.
I'd like to determine what the problem is and fix it; but I don't
know where to begin. I don't even know whether the bug is within
Causeway, the driver or Watcom. Oddly enough, programs supplied with
Causeway don't seem to produce the error.
Michael Devore
I've had to route CauseWay ops around that sort of thing in the past
(the comments in CW source still insult one bad boy from a few years
ago). If the driver will load without the card, send me an example
source, crashing EXE, and the driver file(s) and I'll take a look. If
the drivers need the card, welp, you'll be on your own there.
(Is this group still considered active vs. OW newsgroups? I only
found it when googling around for something else.)
phay...@alphalink.com.au (Peter "Shaggy" Haywood) wrote in message news:<3e72cedf...@forums.sybase.com>...
bryan...@hotmail.com
>14:43:56 -0000 in powersoft.public.watcom_c_c++.general.
>Re: DOS4GW and PCI Serial card on IRQ9's a cool scene! Dig it!
>>program
>>> it won't even start up again
>>> and sometimes the PC reboots.
>
> That's interesting! Sounds similar to a problem I've had. Bryan,
>does your DOS machine load a driver for a sound card that emulates a
>Sound Blaster, by any chance? Do you get this behaviour when running a
>simple "Hello, World!" program?
>
#include <iostream.h>
#include <conio.h>
#include <string.hpp>
IMR=0x21, ///< Interrupt controller 1 mask register.
ICR=0x20, ///< Interrupt controller 1 control port.
EOI=0x20, ///< End of interrupt.
ICR2=0xA0, ///< Interrupt controller 2 control port.
IMR2=0xA1 ///< Interrupt controller 2 mask register.
};
public:
String s;
unsigned int i;
Si(unsigned int j=0) {
String s = "";
i=j;
}
};
}
unsigned int scanCode, sc;
scanCode = inp(0x60);
sc = scanCode & 0x7F;
int st = inp(0x61);
st |= 0x80;
outp(0x61, st);
st &= 0x7f;
outp(0x61, st);
saveKeyHit(event);
_enable();
}
{
// Install interrupt handler for keyboard
originalKeybdHandler = _dos_getvect(0x09);
_dos_setvect(0x09, kbdHandler); // install new handler
if (event.i!=0) {
cout << " " << event.i;
event.i = 0;
}
}
}