Date: Tue, 31 Aug 93 04:30:07 PDT
From: Advanced Amateur Radio Networking Group <tcp-group@ucsd.edu>
Errors-To: TCP-Group-Errors@UCSD.Edu
Reply-To: TCP-Group@UCSD.Edu
Precedence: Bulk
Subject: TCP-Group Digest V93 #223
To: tcp-group-digest
TCP-Group Digest Tue, 31 Aug 93 Volume 93 : Issue 223
Today's Topics:
bmh v0.3
KA9Q Speaks!
NOS in NT VDM (4 msgs)
PI CARD PROBLEMS (2 msgs)
Thoughts on X1-J
who's managing this list?
X1J code
Send Replies or notes for publication to: <TCP-Group@UCSD.Edu>.
Subscription requests to <TCP-Group-REQUEST@UCSD.Edu>.
Problems you can't solve otherwise to brian@ucsd.edu.
Archives of past issues of the TCP-Group Digest are available
(by FTP only) from UCSD.Edu in directory "mailarchives".
We trust that readers are intelligent enough to realize that all text
herein consists of personal comments and does not represent the official
policies or positions of any party. Your mileage may vary. So there.
----------------------------------------------------------------------
Date: Mon, 30 Aug 93 09:57:08 EDT
From: crompton@NADC.NAVY.MIL (D. Crompton)
Subject: bmh v0.3
To: Paul.Healy@cs.tcd.ie, tcp-group@ucsd.edu
Paul,
What about the support of JNOS indexed mail files. I know Johan was working on that
as a add-on to his changes in JNOS.
Doug
------------------------------
Date: Mon, 30 Aug 1993 13:53:49 -0700
From: David_Shalita.ES_AE@xerox.com
Subject: KA9Q Speaks!
To: orvb@micom.com
Hi Orv,
Can you pass me the address of the Holiday INN and the hours they are open
to the public each day, any info will help, or direct me to someone who has
that info via packet?
73 Dave
w6mik @ k6ve
Info via Internet is ok also.
------------------------------
Date: 30 Aug 93 06:08:37 CDT
From: Jack Snodgrass <kf5mg@vnet.IBM.COM>
Subject: NOS in NT VDM
To: <TCP-Group@UCSD.Edu>
>I tried to run JNOS107b under NT in a DOS VDM.
>I tried this with an empty autoexec.nos file and
>find that NT reports an illegal instruction at
>CS:0000 IP:00A8 OP:f004b5cbb8
FYI. JNOS 1.07b runs fine in an OS/2 2.1 VDM. BTW... why is NT V3.1?
What happened to V1.1?
73's de Jack - kf5mg
Internet - kf5mg@kf5mg.ampr.org - 44.28.0.14
Worknet - kf5mg@vnet.ibm.com - work (817) 962-4409
AX25net - kf5mg@kf5mg.#dfw.tx.usa.na - home (817) 488-4386
------------------------------
Date: Mon, 30 Aug 93 08:01:55 CDT
From: Jack Spitznagel <spitznagel@utmem1.utmem.edu>
Subject: NOS in NT VDM
To: tcp-group@ucsd.edu
Hi Dav ide, All,
David wrote:
>I tried to run JNOS107b under NT in a DOS VDM.
We tried this with the last beta NT code and were completely unsuccessful . I
wonder if "virtual hardware interface" availability is not the culprit....
I had to experiment quite a bit with various versions of JNOS under OS/2 before
finding ones that would run smoothly...Versions 1.03 to 1.06 were OK but none
were reliable (or in DOS! -- but it was nice not to have the whole system crash
tho'!! ) Enhanced DOS compatibility has now cured the problems with that OS, but
we found that versions of JNOS compiled under Turbo-C did not run as well as
those done with Borland C/C++ compilers....
You might try doing "bare minimum" configurations then add in the stuff you
need step by step... That was how some of the problem were identified for OS/2.
NT was too much work and I did not have any real time to play. The system was
slow and unpredictable on our test-bed, so we gave up. Good luck and keep us
informed how you make out!
Jack.... KD4IZ
John Spitznagel D.D.S. | #1. Check the fuse!
College of Dentistry | #2. Turn it on.
UT-Memphis | #3. Kick it.
875 Union Avenue | #4. Drop it.
Memphis, TN 38163 | #5. Call the company.
(901) 528-6441 | #6. Read the Manual.
------------------------------
Date: Mon, 30 Aug 93 10:44:16 EDT
From: crompton@NADC.NAVY.MIL (D. Crompton)
Subject: NOS in NT VDM
To: tcp-group@ucsd.edu
I was also not successful in my initial 'pif' file runs of NOS. NT is very particuliar
about any direct I/O. Not sure if any is done without an autoexec file though.
Doug
------------------------------
Date: Mon, 30 Aug 93 10:20:00 EDT
From: crompton@NADC.NAVY.MIL (D. Crompton)
Subject: NOS in NT VDM
To: TCP-Group@UCSD.Edu
I tried running KA9Q - 01/18 under NT and got the same type of message. I seleceted
ignore the warning and it did not respond to any keyboard input. I was able to close
it without any problems though.
I have not tried JNOS yet. This may be related to the (lack of) a PIF file. I will
fool with it some more in that regard and let you know.
Doug
------------------------------
Date: Mon, 30 Aug 93 08:24:47 CDT
From: Jack Spitznagel <spitznagel@utmem1.utmem.edu>
Subject: PI CARD PROBLEMS
To: tcp-group@ucsd.edu
Hi Karl, All...
Karl Ebel writes:
>Inspection of what the PI card sends show a bad sendbuffer pointer. JNOS
>is able to support the PI card in two different ways, by an internal,
>compiled-in, driverfunction or by the TSR driver from ve3ifb. Both
>versions show the same failure. There seems to be something bad in the
>handling of DMA in a DOS session of V2.1 OS2.
I would say that the DMA handling in v2.1 is better!.. But Karl, did you add
the DEVICE=c:\os2\vdma.sys line to your config file? This line has done much
for those using DMA in a VDM with cards that provide for it..... I would be
interested to find out how you make out with it!
Jack -- KD4IZ
John Spitznagel D.D.S. | #1. Check the fuse!
College of Dentistry | #2. Turn it on.
UT-Memphis | #3. Kick it.
875 Union Avenue | #4. Drop it.
Memphis, TN 38163 | #5. Call the company.
(901) 528-6441 | #6. Read the Manual.
------------------------------
Date: Mon, 30 Aug 93 09:54:12 EDT
From: crompton@NADC.NAVY.MIL (D. Crompton)
Subject: PI CARD PROBLEMS
To: TCP-GROUP@UCSD.EDU, karl.ebel@drig.com
Karl,
I don't believe you mentioned the bios or make of your new motherboard. One gotcha that
I found here is a scheme called 'hidden refresh' that the Symphony chip set uses. It is
incompatible with many video cards and maybe others. On one system I have the AMI BIOS
does not have a configuration option for it. Instead it is always on!
The other things you should check is the AT buss speed. It is defined as clk/x and is
usually set at 4 - I.E. 33/4 or just above 8Mhz. This should work for most all boards, in
fact I generally run it at clk/3 for 11mhz, but I have seen cases where it had to be set
at clk/6! Just one slow card can foul up the works.
Just some thoughts although they may not have any relation to your particuliar problem.
Doug
------------------------------
Date: Mon, 30 Aug 1993 01:10:36 -0400
From: ve3mmn@gw.ve3rpi.ampr.org
Subject: Thoughts on X1-J
To: tcp-group@ucsd.edu
The deviation meter is a good idea, but from a site-management standpoint
it would be more interesting to use the hardware to read a calibrated
temperature sensor to find out the temperature at the site, especially
for those sites exposed to temperature extremes. Maybe even use the
extra LED on the TNC (or at least it's output from the SIO/O) to control
a small heater or something (like a light bulb) to maintain internal
site temperature on cold days. You could make the trip point an entry
in one of the parm lists and do a simple compare every once in a while
to see if the measured temperature was above or below the trip point
and act accordingly. You would not necessarly even need calibrated
readings, just a simple 0-255 scale which could be externally converted.
The coding can't be too severe.
How about a hardware watchdog circuit also, something which simply watches
the PTT line on the TNC and if there is no activity in 20 minutes then
reset the node. Set you ID beacon to 15 minutes to be sure to allow the
circuit to reset. I am sure that there are cases where a simple circuit
like this would not adequately restart a scrambled TNC, but even saving
one in three trips to the site is useful. How about a "warm start" counter
to indicate the number of warm-start's since a cold boot (This might
already be present but I don't have my doc's handy).
Much of this coding should be fairly easy to add to existing code, and in
the case of the watchdog really doesn't utilize hardware other than the
warmstart counter. BPQ for the DataEngine has this faculty and it is
quite handy - perhaps too a time indicator to indicate time since the
last warmstart would also be handy. After all, the more data there is
to analyze remotely the greater the chances of determining problems and
formulating solutions before you go running to places awkward :-)
73 de Dave VE3MMN
ve3mmn@ve3mmn.ampr.org [44.135.84.196]
------------------------------
Date: Mon, 30 Aug 93 13:27:25 CDT
From: System Operator <MIX.Operator@mixcom.mixcom.com>
Subject: who's managing this list?
To: tcp-group@ucsd.edu
Who is managing this list?
Message headers say to send errors to ucsd!tcp-group-relay@uunet.uu.net.
There is an invalid address in the list that goes to my machine,
and I want it removed. I've sent at least three messages to the
address shown above and have heard nothing. Meanwhile messages
continue to be sent to an invalid address.
Dean Roth
MIX System Operator
-------------------
/`-_ Milwaukee Internet Xchange Usenet BBS, Worldwide Email
{ }/ MIX Communications
\ */ P.O. Box 17166 sysop@mixcom.com
|___| Milwaukee, WI 53217 (414) 241-5469 modem
------------------------------
Date: Mon, 30 Aug 93 8:27:41 PDT
From: Glenn Elmore <glenne@hpsadl3.sr.hp.com>
Subject: X1J code
To: tcp-group@ucsd.edu
Subject: X1J TNC Code
I guess I've had my head buried in RF hardware for too long. I
finally got around to scanning the feature set of the X1H code and it
certainly looks like people have been busy. I am particuarly interested
in it because it appears to offer a means to have an inexpensive IP
router at a remote site; no host is required.
Since temporarily punting the MIO hardware which has been attached to a
couple of my 904 MHz radios on hilltops and replacing them with PacComm
10 MHz Tiny2 TNCs I've been trying to see what kind of code to run in
order to get the best radio performance.
Up to now, I've run MFJ code which has the TXDIDDLE capability. This
allows setting TXDELAY to 0 and limits total keyup time to a few hundred
microseconds while offering the maximum number of transitions for the
remote receive data clock recovery to chew on prior to start of the
frame. The problem is that even though performance on the radios and
wire are now the same, the TNC is cpu bound and can only keep up at 38.4
Kbps, which is one tenth of what the radios have previously run with
MIO.
I've fairly well accepted that one has to walk before he can run but
I'd certainly like to get some code without all the conventional TNC2
baggage so that higher radio speed might be supported. The existing
KISS code as written by k3mc and modified by the GRAPES folks appears to
support 56K on the radio side. I suppose that with the 10 MHz hardware
in the TNC that twice this might be expected. However, this requires
the remote sites to have a resident host computer to talk KISS back to
the TNC and mind the store. I've totally depleted the radio budget and
finding volunteers to "own" hilltop sites has been at best difficult.
Presently there is no one working to resolve the MIO problems which keep
those from being used and it seems I have to find a way to make TNC2s work
if the radios aren't to go to waste.
Mike, k3mc, is looking at the original KISS code to see what it would
take to add ax.25 digipeat capability for standalone use at higher
speeds. Pending that working I'm wondering if anyone has tried to turn
the radio side speed up on X1J code to see how it fares.
Or does anyone have a better suggestion for TNC2 firmware to run
standalone, high speed radio hardware at remote sites? It would certainly
be nice to get to use these radios at least once before the
band collapses into a total morass of Part 15 devices, weather profilers
and AVL. It may be too late as it is though.
Any helpful comments or ideas gratefully received.
73
Glenn n6gn
------------------------------
End of TCP-Group Digest V93 #223
******************************
******************************