Date: Sat, 25 May 1996 15:35:32 -0700 (PDT)
From: Jamul <mhommel AT trumpet DOT aix DOT calpoly DOT edu>
To: Eli Zaretskii <eliz AT is DOT elta DOT co DOT il>
Cc: djgpp AT delorie DOT com, Samuel Vincent <svincent AT cs DOT sonoma DOT edu>
Subject: Re: COM port access
In-Reply-To: <Pine.SUN.3.91.960524143749.5365I-100000@is>
Message-Id: <Pine.A32.3.91.960525151511.164082B-100000@trumpet.aix.calpoly.edu>
Mime-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII


  I got the faq, and checked it out - it doesn't apply to my situation at 
all (it does tell me that DJGPP has inportb and outportb, but then I had 
already figured that one out) - I probably should've stressed just how 
simple what I am doing is: NO interrupts, no nothing.  It amounts to this:

init_rs232(); (this is done with inline asm, using the "int" instruction 
  - is that bad?)
while(1) {
  if(status port says data_ready)
    data=inportb(buffer port);
  (when it comes time to send something) {
    if(status port says xmission buffer clear)
      outportb(buffer port, data to send);
  }
}

  In case you can't tell, that's pseudocode.  So there are no interrupts 
to muck about with (I've done interrupts for timer and keyboard, and boy 
do I know that that is mucking about.. BLEH! - speaking of which, I have 
to reread that part of the faq - maybe my keyboard handler will stop 
missing keypresses on fast computers!), really the only sneaky low-level 
tricks are using ports and the inline asm that inits the port.  It always 
either just waits forever not receiving any input, or crashes horribly.  
Oh, by the way, I have run it on one computer and run the talk program on 
the other, and THAT works perfectly - so it is not the receiving that is 
the problem, it is transmission.  For some reason, it does not transmit 
any data.  However, the talk program's send data code consists of these 
two lines:

  xmt:  mov dx,XMT_BUF
        out dx,al

  (obviously, al already contains the character to be sent).  XMT_BUF is 
the same value I use in mine, and as I have mentioned, this talk program 
works perfectly.  My code looks like this:

  outportb(COM[outcom].buf,packet);

  (it feels so much more networky if I call my byte "packet" - but it is 
a byte, nonetheless).  The problem is not in my usage of a COM array - it 
gets all the right status information, and it receives correctly (for 
instance, it continuously returns 96 on the status port, meaning 
transmission buffer clear, and transmission shift buffer clear), so I 
know my values for COM[outcom].status and COM[outcom].buf are correct.
  This is a very perplexing conundrum (sorry, had to use that word).  
Though I don't know if it would help with this problem, I am interested 
in seeing Mr. Vincent's com port library.  So if you upload that 
somewhere (x2ftp.oulu.fi, perhaps?), let me know.
  So, the question of the day is, can anybody tell me what's going on 
with this code?  It's been driving me insane for a good week, and I 
suppose I can confide in you guys: it's due this friday!!  AUGH!  Well, I 
am going to give real mode turbo pascal a shot on tuesday if there seems 
to be no answer for DJGPP.  If it does the same thing, I will just assume 
I am much too dumb to program, and will retire.  That seems the most 
reasonable course of action.

*****************************************************************************
* Jamul(ha-MOOL) aka Mike Hommel * "It's too bad that whole families have   *
* Head Honcho, Jamul Software    *  to be torn apart by something as simple *
* mhommel AT trumpet DOT calpoly DOT edu    *  as wild dogs." - Jack Handy             *
* http://ppp110.callamer.com     *                                          *
*********SPISPOPD VII: SPISHULK: THE SEARCH FOR BOUAPHA, COMING SOON!********