Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!watmath!clyde!caip!princeton!allegra!ulysses!mhuxr!mhuxn!ihnp4!inuxc!pur-ee!uiucdcs!convex!tifsie!pat
From: pat@tifsie
Newsgroups: net.lan
Subject: Need help with DEQNA
Message-ID: <3700001@tifsie>
Date: Wed, 16-Jul-86 10:53:00 EDT
Article-I.D.: tifsie.3700001
Posted: Wed Jul 16 10:53:00 1986
Date-Received: Sun, 20-Jul-86 05:51:05 EDT
Lines: 48
Nf-ID: #N:tifsie:3700001:000:2020
Nf-From: tifsie!pat    Jul 16 09:53:00 1986


I am attempting to write a driver for the DEQNA and I'm having some 
problems.  My current problems relate to getting it into "promiscuous"
mode.  The manual is very vague on exactly how to set up the transmit
bdl's byte count.  This is a negative (2s comp) value for a normal transmission.
What should the format be set up for a setup packet?  The book talks about
a value greater than 128.  Is that positive 128 or negative 128?

**** FLAME ON ****

This has got to be one of the worst boards I have ever had to deal with.

The documentation is incredibly vague and sometimes inaccurate.  I'm going to
take great pleasure in filling out the reader comment card on this one!

The setup packet is bad news.  The engineers who designed this beast 
must have something against software people.  Organizing the packet in that 
format (addresses in COLUMNS in an array, with strategic areas of zeroes 
scattered about) is quite anti-social.  How much did that save you in hardware
costs, guys?  A whole $0.15?

I am also quite concerned about missing interrupts.  This comes from personal
experience with looping back a setup packet.  I set up the transmit bdl 
address registers and in the next statement did a printf to check out the
value of the CSR's.  Guess what!  The interrupt bits were set, but did an 
interrupt actually get generated?  Of course not!  A DELAY(100) between setting
up the transmit bdl registers and the printf now allows the interrupt to 
occurr.  DEC's reaction:  "...we don't assist people writing device drivers.
Maybe the forthcoming DEQNA hardware fixes will take care of the problem."
Thanks a bunch guys....

This could be a very long battle.

**** FLAME OFF ****

If you know more about the DEQNA than I do, please contact me.  I'm getting
tired of fighting with this board.

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

Patrick W. Peters	
Texas Instruments
Process Automation Center
P.O. Box 655012, M/S 3635
Dallas, TX 75243

UUCP: 	{uiucdcs!convex!smu, {rice, sun!texsun}!ti-csl}!tifsie!pat
Voice:	(214) 995-2786