[comp.sys.ibm.pc.digest] Info-IBMPC Digest V90 #191

Info-IBMPC@WSMR-SIMTEL20.ARMY.MIL ("Info-IBMPC Digest") (11/26/90)

Info-IBMPC Digest           Mon, 26 Nov 90       Volume 90 : Issue 191 

Today's Editor:
         Gregory Hicks - Rota Spain <GHICKS@WSMR-Simtel20.Army.Mil>

Today's Topics:
                         ATMATLAB under Windows
                        Re: 8250 and 8259 chips
        Re: Interrupt-driven serial communications programs in C
                          HARDWARE INTERRUPTS
                        VGA cards for XT and AT
                             Virus scanners

Today's Queries:
                     Address Brother Industries ltd
                         Any info on BSR 386SX?
                           FAX and phone-mail
                           Where is Borland?
                           Oriental Software?
            Downloading Binary Files with Kermit under Telix
             Sales Management Simulation Game . . .Wanted!

Send Replies or notes for publication to:
<INFO-IBMPC@WSMR-SIMTEL20.ARMY.MIL>

Send requests of an administrative nature (addition to, deletion from
the distribution list, et al) to:
<INFO-IBMPC-REQUEST@WSMR-SIMTEL20.ARMY.MIL>

Archives of past issues of the Info-IBMPC Digest are available by FTP
only from WSMR-SIMTEL20.ARMY.MIL in directory PD2:<ARCHIVES.IBMPC>.

----------------------------------------------------------------------

Date: Sat, 17 Nov 90 11:09:51 -0500
From: william stevenson <wstevens@uceng.UC.EDU>
Subject: ATMATLAB under Windows

In comp.sys.ibm.pc.digest you write:

>I am using ATMATLAB and am trying to get it to work under Windows 3.  I
>can run PCMATLAB, but when I run ATMATLAB the machine reboots (even to
>the point of rerunning the memory tests!)

As far as I know, the Dos extenders used by Win3 and Matlab are
different and incompatible.  You could check with Mathsoft.

William

------------------------------

Date: Sun, 4 Nov 90 15:53:47 -0500
From: david@csource.oz.au (david nugent)
Subject: Re: 8250 and 8259 chips
Keywords: 8250 8259 interrupts serial

In <1210@vaxeline.COM> gordon@vaxeline.COM (Gordon Lee) writes:

> My Interrupt Service Routine (ISR) is currently defficient in that it 
> can miss a transmit completion, thereby wedging my outgoing data stream.  
> This only happens under heavy bidirectional traffic, which leads me to 
> believe that my ISR is losing when a transmit completion intr and a receive 
> intr happen "simultaneously".  I think my routine is handling the receive
> interrupt while allowing the transmit completion interrupt to drop on 
> the floor.

You are no doubt absolutely correct. This is a real pain, and somewhat
of an "undocumented feature" of most UARTS. Even 16550A series UARTS
have the same problem.

> [....]
>
> The crux of what I need to know and what the manual doesn't want
> to tell me is:  how to cleanly service a single physical interrupt
> which is signalling the occurence of more than one type of UART 
> interrupt condition.  I also need to know how to expect a subsequent
> interrupt while I am in my service routine, and the proper way to 
> acknowledge to the PIC notification of multiple "simultaneous" interrupts.

Ok, within the ISR the state of the PIC is irrelevent except that it's
always a good idea, however, to rearm the PIC as soon as possible
(assuming you're working in a standard PC/AT edge triggered non-autoEOI
mode).

Within a communications ISR, you simply loop back and re-test the
UART's IID register for new interrupts - you've probably done this.
The "bug" I refer to above is within the UART itself - it will not
recognise lower priority interrupts (ie. modem status changes and
transmit empty) when servicing interupts of a higher priority.

Wonderful design.  :-(  If your ISR depends on getting each and every
transmit interrupt, one such missing interrupt causes a transmitter
"freeze".  Only by actually sending another character can you restart
it.

A partial solution is to read the line status register on the way out
of the ISR, and loop back of a) there are any characters in your
software transmit queue, and b) if the transmit holding register bit is
empty.

Partial, I say, because it's not entirely reliable.  The INS8250 lies
through it's teeth - it often says it's empty when it isn't, resulting
in loss of characters in the transmit stream since the ISR stuffs
something into the THR when it isn't really empty. Most other UARTs
I've come across don't suffer this same problem, so it should work just
fine.

The best solution I've come up with is to disable transmitter
interrupts by masking out the appropriate bit in the IED, then masking
it again - immediately before servicing the higher priority interrupts
- receive data available, and on delta receive line status.  This does
effectively prevent the UART not noticing that the transmit holding
register becomes empty while within the service routine.

I've used this technique with great success, and some more. The
transmitter I've developed is now entirely driven by the transmit
enable bit of the IER; and relies on the feature in UARTS that triggers
a THRE interrupt whenever that bit is set while the transmit holding
register is empty.  That makes it entirely possible to limit all UART
I/O to within the interrupt service code.

There's probably not enough bandwidth here for further expansion on the
subject and all the horror stories I could tell you about it, so email
if you need any further clarification or help.

    - david

        Fidonet: 3:632/348   SIGnet: 28:4100/1  Imex: 90:833/387
              Data:  +61-3-885-7864   Voice: +61-3-826-6711
 Internet/ACSnet: david@csource.oz.au    Uucp: ..!uunet!munnari!csource!david

------------------------------

Date: Tue, 30 Oct 90 17:44:14 -0500
From: rhys@batserver.cs.uq.oz.au (Rhys Weatherley)
Subject: Re: Help: Interrupt-driven serial communications programs in C
Keywords: Interrupt, ROM_BIOS, modem

cs65x7@sdcc18.ucsd.edu (Trieu Vu) writes:

>This is my first posting so I hope it comes out right.

>    [... lots of stuff on "help me, I want to do int-driven comms" ...]

This is not so much a reply as a request to the serial comms gurus out
there.  This particular question could go on the "MOST frequently asked
questions" list with no troubles.  Since we are continually getting
requests for this operation, maybe there should be discussion in
comp.os.msdos.programmer or somewhere on a STANDARD set of interrupt
driven routines, that will work with both Microsoft C and Turbo C (ever
heard of #ifdef ?? :-).

To date, most routines I've seen on the net and on ftp sites have holes
big enough to push elephants through.  e.g. turning on interrupts on
the chips BEFORE the chip has been properly initialised for
send/receive, and the handler installed - I've seen things like this.
What happens if you get an interrupt "right here" when the chip isn't
quite ready yet?  BOOM!  Murphy's law of interrupts: "An interrupt will
ALWAYS occur where you DON'T want it to!"  Turn them OFF, initialise
the rest, and THEN turn them on.  Another thing I find is many
libraries assume that the chip is in a reasonably OK state when they
initialise it (early attempts at a library of my own showed the chip
would only respond the SECOND time the program was run: using similar
code to something in a book! - the second time the chip was in an OK
state).  Who said it had to be like this!  Murphy's law of hardware:
"It is in a totally random state when you first see it, and it will
also be the least desirable state".  Program defensively, not so it
works "most of the time"!

I have written "reasonably" bullet-proof routines for Turbo C, to
handle COM1 and COM2 (both at the same time too, which is "weird"
elsewhere!), but I don't know enough for COM3-N, so there are
shortcomings.  Also, I can't guarantee that they'll work on anything
except XT clones, cause that's all I have access to at present.

This message is mainly a call for serial gurus to post their source
code, to be inspected for holes, and shortcomings, so we can come up
with a standard set of routines, and say to these people "You can get
it on ftp site XXX, and it is TOTALLY bullet-proof, it will work
everytime, and not cause you any trouble".  Or it could even be posted
bi-monthly or something, just as long as we can help curb this
recurring question.  Of course, you gurus must be "big-hearted" enough
to take flames and criticisms about you code :-).

Any ideas?

Rhys.

  Rhys Weatherley             |  University of Queensland,  
  rhys@batserver.cs.uq.oz.au  |  Australia.  G'day!!        

------------------------------

Date: Sat, 17 Nov 90 17:43:33 LCL
From: WALTER SPETH <SPETH%DBNPIB5.BITNET@uga.cc.uga.edu>
Subject: HARDWARE INTERRUPTS

I gathered some expierience using hardware interrupts on a PC/XT the
other day.  Some questions arose, which I like to be discussed here:

The 8259 PIC Data sheed says, that any IRQ signal asserted has to
remain active (i.e. high) until the Processor responds INTA. As INTA is
not wired to any slot pin, how do the cards in those slot know?

If the IRQ is inactive again, when INTA comes up, IRQ7 (least priority)
will be assumed. That is all right with me for the moment, but not
quite:

Could IRQn be held down by a flip flop which will be reset by the
interrupt's service routine just before issueing EOI? No? too long?
just some clock cycles? how many then?

I indeed do use the IRQ7 pin (B21 on the slot). When my TTL devices, I
am playing around with, try to push it high (active), it is obviously
held down by the ACK gate of LPT1 on my hercules/printer card - there
is no jumper. Many people/texts assert, it will be quite all right for
SEVERAL devices to use the SAME hardware interrupt. I do actually not
understand how that can be possible, if any card tries to assert
TTL-high level while others hold it low.

Well, so far asking for INFOS. If anybody actually wants some details
to try his own first hardware-ints, I could get more elaborate on facts
I found out reading several books/data sheets/magazines.

                   Walter SPETH@DBNPIB5

------------------------------

Date: Tue, 01 Jan 80 03:41:29 ARG
From: Luis MAGNI <banyc!atina!fmcba!luis@uunet.UU.NET>
Subject: VGA cards for XT and AT.

Dear Alex Lai.

I am using a VGA card 8 bits in NEC 386 - 20. It is a VGA Paradaise
Plus from

Paradaise Systems, Inc
800 E. Middlefield Road
Moutain View, CA 94043-9701

I have tested in an 8 bits XT clone 12 MHz and work well, it has a
maximun resolution of 800 x 600 at 16 colors, and was tested with NEC
Multisync 3D.  It did not show any problems with both machines,I think
this is a good card...

		Luis MAGNI    
		Centro de Microscopia Electronica - U.N.Cordoba
		RAN	:luis@fmcba.sld.ar         
		BitNet	:luis%fmcba.sld.ar@uunet.uu.net

------------------------------

Date: Sat, 17 Nov 90 19:25:10 PST
From: Robert_Slade@cc.sfu.ca
Subject: Virus scanners

I suspect that the call for a "safe" virus detector, protector,
disinfector, et al was prompted by the reports that SCAN, one of the
best known, is *not* safe to use.  The fact is the files purporting to
be versions 65, 68 and 70 of SCAN have been found to contain viri or
trojan programs.  The latest version that I know of is 67C (67 and 67B
were functional but had bugs).
 
An alternate is F-PROT whose author, Fridrik Skulason, can be reached
at frisk@rhi.hi.is.  This is the program that I most recommand.  It is
a very complete suite of virus detection and security utilities.
 
Of the commerical software, I note that VirexPC is written by Ross
Greenburg, well known in anti-viral circles for Flu-Shot.

------------------------------

Date: Tue, 01 Jan 80 03:47:01 ARG
From: Luis MAGNI <banyc!atina!fmcba!luis@uunet.UU.NET>
Subject: Address Brother Industries ltd.

I am looking for an address of Brother Industries Ltd, recently I buy a
Laser Printer Brother HL8e and its Centronics parallel port do not
work. I need to contact them if possible via FAX. If anyone know the
address please let me now...

Thanks.

		Luis MAGNI    
		Centro de Microscopia Electronica - U.N.Cordoba
		RAN	:luis@fmcba.sld.ar         
		BitNet	:luis%fmcba.sld.ar@uunet.uu.net

------------------------------

Date: Thu, 15 Nov 90 15:59 CDT
From: David Egle <DLEAFD0%PANAM.BITNET@ricevm1.rice.edu>
Subject: Any info on BSR 386SX?

In the Winter '91 issue of the DAK catalog they advertise a BSR 386SX
computer.  The price looks like a good deal ($1799 + $69 P&H) for the
system and software they offer (1M RAM, 40M 28 ms disk, 1.2M 5 1/4
floppy, 1.44M 3 1/2 floppy, VGA card and monitor, DOS 3.31, Windows
3.0, Quattro Pro, Wordstar 5.5 Professional, Reflex 2.0, Sidekick,
etc.)

Does anyone have any information on this computer?  I know of BSR in
the audio world.  Is this the same company?

Any information would be appreciated.

Thanks in advance.

  David Egle / Math & Computer Science / Univ Texas - Pan American
   Edinburg, TX  78539 / Bitnet> DLEAFD0 @ PANAM (last character zero)

------------------------------

Date: Sat, 17 Nov 90 19:36:36 -0500
From: dsrekrg@prism.gatech.edu (Rob Gibson)
Subject: FAX and phone-mail

Have you had direct every day experience with FAX boards such as
Intel's Connection Co-processor or SatisFAXtion, AT&T's Fax Connection,
Complete PC's Complete Fax, GammaFax CP, or Panasonic's Fax Partner ?

Have you daily experience with a PC based phone mail system such as
Complete PC's Complete Answering Machine ?

Do they do the job you wanted?  What is your opinion of the software?
Do you use any type of FAX/modem/voice switch on one phone line?

Please email to me and I will summarize to the net.

Rob Gibson, WREK 91.1 MHz, 40000 watts
Georgia Tech, Atlanta Georgia, 30332        404/894-2468
uucp: ...!{allegra,amd,hplabs,seismo,ut-ngp}!gatech!prism!dsrekrg
ARPA: dsrekrg@prism.gatech.edu

------------------------------

Date: Sat, 17 Nov 90 15:03 N
From: PAAI%KUB.NL@CUNYVM.CUNY.EDU
Subject: Where is Borland?

Nine months ago I had to call for your help getting an answer from
Borland. Sorry, but I again need your help.

In August 1990 I did send Borland my registration card for the new C++
I bought in Holland and added a letter with some technical questions.
Getting no response  I wrote again end september. Nope.  And I *did*
paste stamps on the envelopes :-)

This seems an exact copy of the trouble I had last year getting
response from Borland, only they had the excuse of an earthquake and
sorry, we seem to have lost a few letters in the confusion.  I wonder
what excuse they have now for not answering. It really gets me mad: I
mean, if they give no support outside the USA I can as well go and
steal their compiler in stead of buying it :-((.

Anyway, would somebody over there in the States be so kind and notify
Borland again that they still have to answer a letter?

Thanx
Hans Paijmans
PAAI@KUB.NL

------------------------------

Date: Sat, 17 Nov 90 18:48:18 -0500
From: jguo@HARPO.CS.NYU.EDU (Jun Guo)
Subject: Oriental Software?

1.) Can anybody tell me something about Japanese wordprocessors that
are compatible on general English MS-DOS machine? (VGA/EGA preferred)

2.) I heard that there is a CC-LIST discussing Chinese softwares, can
anyone give me the address?

3.) Have you ever come across pictures of oriental art in GIF format?

  Many thanks.

Jun

------------------------------

Date: Fri, 16 Nov 90 15:43 EDT
From: David Hart <HART53%SNYPOTVA.BITNET@CORNELLC.cit.cornell.edu>
Subject: Downloading Binary Files with Kermit under Telix

I am having trouble downloading binary files useing Kermit under Telix
3.12 (registered!).. When I try to download a .ZIP file that I got
through FTP, I set Telix (using ALT-O) to receive a binary file. But
when I begin the transfer, it just sits there waiting for the file
header. If I set Telix to receive the file as a text type file, it
transfers alright, but doesn't run when I get it on my system. Any
suggestions?

David Hart (HART53@SNYPOTVA.bitnet)

------------------------------

Date: Thu, 15 Nov 90 14:05:53 CST
From: Rogelio Isaac Garza <RGARZA@TECMTYVM.bitnet>
Subject: Sales Management Simulation Game . . .Wanted!

I will apreciate any help on my quest for a Sales Management Simulation
Game. My intention is to expose several groups of students to a compe-
titive situation in order to allow them to get some expertise in sales
management.

Any information about software suppliers or actual users would be most
apreciated.

 ROGELIO ISAAC GARZA               
 MONTERREY INSTITUTE OF TECHNOLOGY 
 SCHOOL OF BUSINESS                
 DEPARTMENT OF MARKETING           
 MONTERREY, NUEVO LEON, MEXICO     
 BITNET: RGARZA AT TECMTYVM        

------------------------------

End of Info-IBMPC Digest V90 #191
*********************************
-------