Date: Fri, 8 Jan 93 04:30:18 PST
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 #8
To: tcp-group-digest
TCP-Group Digest Fri, 8 Jan 93 Volume 93 : Issue 8
Today's Topics:
CPU ID test code (3 msgs)
CPU ID test update
DPMI et al...
DPMI library posted
DPMI mode (5 msgs)
MID dups problem - Revisited
REPEAT (4 msgs)
Shared Interupts
UNSUBSCRIBE
update for directory code
update on repeat
WAMPES Convers Problems (2 msgs)
XSPAWN.... Revisited and fixed
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: Thu, 7 Jan 1993 15:31:00 -0500 (EST)
From: MIKEBW@ids.net (Mike Bilow, <MIKEBW@ids.net>)
Subject: CPU ID test code
To: JT@zfja-gate.fuw.edu.pl, tcp-group@ucsd.edu
Everything you say makes good sense. No one has reported any problem
with my CPU type detection scheme, so it looks good so far.
Your comment about the use of the machine ID byte being misleading was
a surprise. I have run across ancient XTs that had junk in there, but
the junk was always zero if not a legal ID code. There were some few
manufacturers who made up their own codes, especially Compaq, but I
coded the am_i_an_AT() routine to default to XT mode if the code was
not the proper one for an AT. As you say, this would blow up if the
code in an XT happened to be the right code for an AT, but I have
never seen this.
Testing the DMA channels and such is more trouble than it is worth.
If someone actually had an XT with an AT type code, then they could do
a manual override by putting the "isat 0" command in AUTOEXEC.NOS.
The model ID is more reliable than the direct CPU testing scheme for
the purposes of setting the "isat" flag, since there are a fair number
of machines with 80186 or 80286 CPUs but XT architectures otherwise,
especially the ATT 6300 series and several early Tandys.
In answer to a couple of your questions, I think that the later Intel
processors reused the NEC-specific opcodes. I believe these were for
REPC and REPNC on the NECs. I don't know if attempting to execute them
on a later Intel processor would do anything harmful. I do have the
needed references and can check, but, as I said, this is beyond the
scope of anything we need for NOS.
High resolution timing on channel 3 of the 8253 works in an XT, but
isn't safe. That same timer channel is used to drive the speaker, so
anything which so much as beeps -- including, for example, the keyboard
buffer on some machines -- will corrupt your timer. This means that the
high precision timer has to be done with interrupts down, which is not a
good thing to do in NOS. The 55 ms garnularity of the standard system
timer tick is good enough for most things in NOS, even if it would be
nice to have something better.
The 80486SX (there is such an animal) was a marketing invention by Intel.
It has the same internal and external data path sizes as the 80486DX, so
there is no similarity in the 80386SX/80386DX nomenclature. What an
80486SX chip is, is just an 80486DX chip with the floating point unit
disabled. Originally, Intel was affirmatively disabling the FPU in the
80486DX die to make an 80486SX, but they are now using a different die.
Cyrix has a competitive 80486SL, which is a pin-for-pin replacement for
the 80386SX, which obviously has the narrower external data paths.
Maybe the Next Big Thing will not be RISC, but RCSC (reduced chip set
computing).
-- Mike Bilow, <mikebw@ids.net> (Internet)
------------------------------
Date: Thu, 7 Jan 93 21:45:49 PST
From: "Jerzy Tarasiuk" <JT@zfja-gate.fuw.edu.pl>
Subject: CPU ID test code
To: MIKEBW@ids.net (Mike Bilow, <MIKEBW@ids.net>)
> Date: Thu, 7 Jan 1993 15:31:00 -0500 (EST)
> Message-Id: <930107153100.3ee0@ids.net>
> Your comment about the use of the machine ID byte being misleading was
> a surprise. I have run across ancient XTs that had junk in there, but
> the junk was always zero if not a legal ID code. There were some few
I saw a machine which had BIOS creation date there. It wasn't anything
similar to AT ID. I saw it because someone had problem with a program
interpreting it incorrectly.
> Testing the DMA channels and such is more trouble than it is worth.
> If someone actually had an XT with an AT type code, then they could do
> a manual override by putting the "isat 0" command in AUTOEXEC.NOS.
Fact. The only worth of interest is to write a test program (separate
from NOS) which can detect it and say need put "isat 0" or "isat 1".
> The model ID is more reliable than the direct CPU testing scheme for
Yes, of course. My colleage had an accelerator board - containing 80286
and suitable to plug into 8088 socket.
> In answer to a couple of your questions, I think that the later Intel
> processors reused the NEC-specific opcodes. I believe these were for
> REPC and REPNC on the NECs. I don't know if attempting to execute them
It is almost sure, at least for 80386. Probably can write program which
can execute on any of these CPU-s and recognize which it is.
But I don't even know why NOS is to recognize CPU type: if it has code
for better CPU, it cannot be used on worse. Putting code compiled for
8088 and 80386 in one file: what way load only needed code to memory ?
I have read Phil's msg about interrupt entry/exit code for program
compiled for 80386 CPU, but what way cause to load 80386 code when
have 80386 and 8088 code when have 8088 only ?
Seems simplest is short program which exit code depends on CPU (call
your CPUID; mov AH,4C; int 21h) and use it in a batch file...
Or allow user to do it manually.
Verify CPU is suitable for our code ? Need to be sure no 80386 opcode
is to be executed (in C library start code) before we verify it.
> High resolution timing on channel 3 of the 8253 works in an XT, but
(channel 2, I suppose, Intel uses names Counter 0 .. Counter 2).
I thought about channel 0, with different mode - 2 instead 3.
55ms is poor resolution when I want to check response time on fast
local network (Ethernet, for example; the time is several ms).
Tnx for info about 486SX/SL.
> Maybe the Next Big Thing will not be RISC, but RCSC (reduced chip set
> computing).
It was already tried - 80188 which has inside: 2 DMA channels, 3 Timers,
Interrupt Controller (4 external inputs only, 8 levels; 4 of them only
from internal devices like timer or DMA). NEC V40/50 are even better,
they have 4 DMA channels (suppose Intel made 80188 before IBM published
PC documentation and NEC after since NEC knew need 4 DMA channels).
But I don't know anyone to have 80188/6/V40/50 based computer.
73's, JT
------------------------------
Date: Thu, 7 Jan 1993 16:55:07 -0500 (EST)
From: MIKEBW@ids.net (Mike Bilow, <MIKEBW@ids.net>)
Subject: CPU ID test code
To: JT@zfja-gate.fuw.edu.pl, tcp-group@ucsd.edu
The remark about "reduced chip set computing" was mostly a joke. There is
a U.S. company, Chips and Technologies, which sells an entire XT computer
on one chip. I think the number is F8680. The Hewlett-Packard 95LX
palmtop must use something similar.
The main objective for my CPU test program right now is so obvious that
you didn't think of it! If there is going to be a 386-specific version
on NOS, it has to at least produce and intelligible error message if
someone tries to run it on an XT or 80286. This is a user support issue.
If the program isn't smart enough to quit gracefully on a machine that
can't run it, it will most likely just lock up.
I must have personally answered 300 user support questions because of
the change in asy handshaking. After telling several hundred people
that they needed to add "param ax0 dtr 1" and "param ax0 rts 1" to
their AUTOEXEC.NOS files. I think we learned this lesson once.
It would be nice if my CPU test program eventually can be used to run
one version of NOS which will automatically select 386 or generic
instructions, but the performance penalty would probably be too high
to make this realistic.
-- Mike Bilow, <mikebw@ids.net> (Internet)
------------------------------
Date: Thu, 07 Jan 93 06:32:03 MST
From: rnielsen@tapr.ampr.org (Bob Nielsen)
Subject: CPU ID test update
To: MIKEBW@ids.net (Mike Bilow, <MIKEBW@ids.net>)
MIKEBW@ids.net (Mike Bilow, <noao!MIKEBW@ids.net>) writes:
> I have now received confirmation that my little CPU ID test program
> correctly detects: 8088, 80286, and 80486DX. I would still like to
> have someone confirm it on the 80386 (DX and SX), and the V20. Any
> testing on really weird stuff, like the 8086 or 80186, would be nice,
> if it's not too much trouble.
Mike, I get the following:
80386DX reads as 80386/80486
V30 reads as 8088/8086/V20/V30
Bob
Bob Nielsen W6SWE
ax.25: w6swe@wb7tpy.az.usa.na Internet: rnielsen@tapr.ampr.org
amateur IP: 44.124.12.16 CIS: 71540,2364
------------------------------
Date: Thu, 7 Jan 93 12:30:56 PST
From: "Roy Engehausen (8-457-2712)" <enge@almaden.ibm.com>
Subject: DPMI et al...
To: TCP-GROUP@UCSD.EDU
It has been pointed out to me that BC++ 3.1 only has DPMI support for
the compiler and not for user programs. I guess the next version of
the compiler will have the DMPI support for user programs that is just
appearing with BPascal 7.0.
Also, I need to clarify a few things. While the new version of AA4RE
BBS will have DPMI support, there will also be a non-DPMI version of
the code circulated. They will have the same features except for the
on-line editor. I had to use a different editor for the DMPI version
since I didn't have all the source for the old one.
A similar tact could be taken with NOS (DPMI versus non-DPMI) using
simple conditional compile statements.
Now if I can find a copy of TCPIP written either in DLLs (which the
DPMI pascal supports) or in Pascal itself, I would add it to my BBS.
Roy
------------------------------
Date: Fri, 8 Jan 1993 2:21:47 -0500 (EST)
From: MIKEBW@ids.net (Mike Bilow, <MIKEBW@ids.net>)
Subject: DPMI library posted
To: tcp-group@ucsd.edu
For those interested in experimenting with it, I have posted the Qualitas
freeware DPMI library (the Borland C++ 3.x version) to ucsd.edu in the
.../incoming directory. This is a royalty-free, freeware, library with
full source code included. There are also versions for Borland C++ 2.0,
Microsoft C 6.0, and Microsoft C/C++ 7.0, but I did not post them.
-- Mike Bilow, mikebw@ids.net
------------------------------
Date: Thu, 7 Jan 1993 10:05:31 -0600
From: miltonm@inetnode.austin.ibm.com (Milton Miller)
Subject: DPMI mode
To: TCP-GROUP@UCSD.EDU, enge@almaden.ibm.com
In message <9301070237.AA23071@ucsd.edu>, Roy Engehausen <enge@almaden.ibm.com> wrote:
>
> I have started playing with Turbo Pascal's DPMI mode. This puts the
> computer into 286 mode and allows use of more than 640K.
...[Used by his BBS now]
> Now the $64,000 question for the NOS people. Borland C++ 3.1 has DPMI
> support also. Anybody experimenting with it yet? This could solve
> the NOS constraints that everybody has been complaining about.
>
> Roy, AA4RE
Two comments:
1) Not everyone is using Borland C++ 3.1
2) Not everyone is using 286s or 386s
(I fall into the second category). The existance of the memory constraints
you mention depends on the features you compile. Here, we took out NET/ROM
support to give room for RSPF. Later we took out RSPF. So on a 640K 8088
running DOS 3.3, I often have over 100k free. I admit you can not compile
a NOS with all the features available, but I don't have any problem with
picking my features. If the features are too big, lets take a critical look
at how they are coded.
milton
------------------------------
Date: Thu, 7 Jan 93 10:37:27 PST
From: Eric Hermanson <erich@hpvcijm.vcd.hp.com>
Subject: DPMI mode
To: tcp-group@ucsd.edu
> Two comments:
> 1) Not everyone is using Borland C++ 3.1
> 2) Not everyone is using 286s or 386s
>
> (I fall into the second category). The existance of the memory constraints
> you mention depends on the features you compile. Here, we took out NET/ROM
> support to give room for RSPF. Later we took out RSPF. So on a 640K 8088
> running DOS 3.3, I often have over 100k free. I admit you can not compile
> a NOS with all the features available, but I don't have any problem with
> picking my features. If the features are too big, lets take a critical look
> at how they are coded.
>
> milton
This is an interesting topic that has come up in every software house that I
have worked in. The actual question is whether we should write software for
obsolete hardware or should we write software for today's machines with an
eye towards tomorrow's? Most software vendors take the approach of writing
for today's machines. I believe that packages such as NOS should probably
go the same way.
The 8088/8086 obsolete? Yes, it is. This architecture is as obsolete as
Apple II, VIC-20, TI/44, Radio Shack, etc. Even the future of MS-DOS looks
pretty limited now (Windows/NT looks like the first step in making Windows
a full operating system instead of just an operating environment). Software
such as NOS should be looking at this and other advancements and try to take
advantage of what it can.
--
----------------------------------------------------------------------------
Eric Hermanson | "You can't discover new oceans unless you have the
erich@hp-vcd.vcd.hp.com | courage to loose sight of the shore." --Anon
1-206-944-2939 |
------------------------------
Date: Thu, 7 Jan 1993 14:38:12 -0500 (EST)
From: MIKEBW@ids.net (Mike Bilow, <MIKEBW@ids.net>)
Subject: DPMI mode
To: miltonm@inetnode.austin.ibm.com, enge@almaden.ibm.com, tcp-group@ucsd.edu
The Borland C++ 3.1 compiler runs under DPMI, but it doesn't come with
any useful utilities or tools to make programs that use DPMI. The Phar
Lap DOS extender that is bundled with BC++ 3.1 is crippleware.
If a real DPMI server is available (as it is in a DOS window under
OS/2 2.0 or under Windows 3.x in enhanced mode), there are a number of
libraries available for accessing DPMI services. Qualitas (the maker
of 386 to the MAX) publishes a freeware DPMI library with full source,
since their 386 to the MAX product provides DPMI services. This library
is available from wuarchive.wustl.edu in version for BC++ 2.0, BC++ 3.x,
MSC 6.0, and MSC/C++ 7.0 as a single file. I split them up into four
separate files on ChowdaNet, DPMIBC2.ZIP, DPMIBC3.ZIP, DPMIMSC6.ZIP, and
DPMIMSC7.ZIP. (Downloadable at 9600 bps V.32, (401)331-0334, or at
14400 bps V.32bis, (401)3315587. Fidonet FReq'able from 1:323/120.)
-- Mike Bilow, <mikebw@ids.net> (Internet)
------------------------------
Date: Thu, 7 Jan 1993 16:24:45 -0800 (PST)
From: Bruce Perens <bruce@pixar.com>
Subject: DPMI mode
To: Eric Hermanson <erich@hpvcijm.vcd.hp.com>
I was thinking about trying to build under a DOS extender, and then
I decided to trash DOS and put Linux on my system. For those of us
lucky enough to have 386 and higher systems, this seems to be a good
route to take. The whole system uses less than 10MB of disk, including
the standard Unix executables, man pages, and a few megabytes for swap
space, the free GNU C/C++ compiler, and the entire kernel source.
There's an existing KA9Q port that runs on the system.
The advantages you get over DPMI/DOS are:
Robustness. True multiple protected address spaces.
Crashing NOS doesn't lock up the system.
Servers can be broken out into their own processes,
True 32-bit flat address space. No switching to 16-bit to
service interrupts, etc.
Virtual memory. Idle servers occupy swap space, not RAM.
You can configure _everything_ into NOS without bogging down
the system. 4MB RAM makes a practical system, 2MB runs.
True preemptive multiprocessing. Use the system for something
else while NOS is running. Compile and edit while NOS is up.
You can do something useful with telnet, since there is true
multiprocessing.
You get all of the kernel source, and it's even reasonably
readable. Have you ever been able to fix a bug in DOS?
The C/C++ compiler is free, and it's a lot better than Turbo.
Debugger support is in a state of flux at the moment, since
the kernel debugger interface (a /proc filesystem) is being
worked on.
Everything else is free, too.
Good support through the news groups.
There is TCP/IP in the kernel now, and kernel support
for amateur protocols is evolving.
Support for bus mice in the kernel. Sound board drivers are in
beta test.
Most anything that has ran under Berkeley Unix can be made to run
under Linux.
Shared library support, makes your executables smaller.
More stable than 386BSD at the moment. This won't always be the
case.
Disadvantages:
Steep learning curve if you don't know Unix.
There's a DOS emulator that I haven't tested. If your program
touches hardware directly, it probably won't work. This includes
direct screen write applications, things that touch the serial
port registers, etc. The major thing I'd want to run is Quicken,
which can be made to use BIOS to get to the screen. I haven't
tested that yet.
Doesn't support Microsoft Windows. There is a free version
of the X Window System, which might not run well unless you
have 8MB ram.
If you have a lot of RAM and disk, 386BSD is an alternative.
Bruce Perens
------------------------------
Date: Fri, 8 Jan 1993 1:08:37 -0500 (EST)
From: MIKEBW@ids.net (Mike Bilow, <MIKEBW@ids.net>)
Subject: DPMI mode
To: erich@hpvcijm.vcd.hp.com, tcp-group@ucsd.edu
Whoa! I did not mean to get involved with/conspire in/have anything to
do with starting another one of these periodic religious arguments about
whether to abandon the 8088 support. I think it is important to recall
that NOS is distributed in source code form. As long as this is the case.,
it should have 8088 support in it. That does not, however, imply that my
particular EXE cannot be restricted to 1 386 or better, nor that we can't
have conditional compilation directives that might result in XT non-support.
-- Mike Bilow, mikebw@ids.net
------------------------------
Date: 07 Jan 1993 23:11:10 -0500 (EST)
From: "Brian A. Lantz" <BRIANLANTZ@delphi.com>
Subject: MID dups problem - Revisited
To: tcp-group@UCSD.EDU
Well, with a simple addition to the forward.c file of WG7J1.07b, the dup
MIDs problem is history! This is the snip of code I added to TNOS to
handle the problem. I've sent it to Johan, and he is adding it to JNOS.
The code changes the bid from $abcde_host.domain to $abcde%destinationuser.
This makes it unique for each message.
Modifications while you wait! In by 9, out by 5! ;-)
-------------------insert at line 488 of 1.07b forward.c ------------
/* This fixes the problem with personal MIDs being the same with
* messages generated from aliases, RMAIL, or mail-groups. Changes
* the bid from $abcde_host.domain to $abcde%destinationuser. - KO4KS
*/
if (!bulletin && (m->sid & MBX_MID)) {
if ((cp = strrchr (bid, '_')) != NULLCHAR) {
cp++;
if (!strnicmp (Hostname, cp, strlen(cp))) {
*(cp-1) = '%'; /* change '_' to '%' */
if(dest != NULLCHAR && *dest != '\0')
strcpy (cp, dest);
else
strcpy (cp, to);
bid[13] = '\0';
if ((cp = strchr (bid, '.')) != NULLCHAR)
*cp = '\0';
}
}
}
/* Add the bid to bulletins,
* AND ALSO to anything that came in with a bid !
* Takes care off duplicate 'SP SYSOP@xxx $BID' problems.
* ALSO add it to ALL messages if the remote system supports MID's - WG7J
*/
----------------------------------------------------------------------
73 from Brian A. Lantz KO4KS@KO4KS.#TPAFL.FL.USA.NA 3100813105
Internet: brianlantz@delphi.com
Amprnet: ko4ks@ko4ks.ampr.org [44.98.0.167]
P.S. Yes, it says "RMAIL, or mail-groups"! Trust me, you'll find TNOS
WORTH THE WAIT!! Coming soon to a CRT near you!!!
------------------------------
Date: Thu, 7 Jan 93 11:01:33 EST
From: crompton@NADC.NADC.NAVY.MIL (D. Crompton)
Subject: REPEAT
To: tcp-group@ucsd.edu
I have ported Phil K's repeat function into WG7J107. The required modules
are in incoming at UCSD. The file is DSP107A.ZIP. Copy these over 107 and
recompile. The base is the latest 107 code - 107B.
It does not work as well as in Phil's code but that is mainly because he
handles the video differently. I opted to do a gotoxy rather than a clrscr
because at least at higher rates this looks better. It may not always properly
update though as it is an overwrite as compared to a clean write. Be prudent
in the use of repeat because some things obviously should not be repeated!
Try a 'repeat 100 t s' or 'repeat 100 ps' - ajust the rate up if the
update rate is annoying. I am using a fast computer and on slow ones
this may not work very well - you may not be able to use faster rates.
Questions I have regarding the repeat code ---
How do you turn off the cursor in Borlandc without using ansi characters?
When you create a newsession but not a socket - I.E. a local stream What
can you use with a loop to detect closure/reset of that session?
sp=newsession(.....)
for (;;) {
pwait(null);
if (??????)
get outta here
}
sp->s always equals -1 in this case so you can't use it.
So in the repeat code I simply close the session when you leave it - hit
F10 or any other session. Just repeat the 'repeat' command again.
I briefly reviewed Phil's latest and I was impressed with the screen
update speed. I was using the 386/486 version. Phil's code is as different
as night and day now compared to WG7J which is based on KA9Q base of over
a year ago now.
Porting many of the new things over without making wholesale changes would
be difficult if not impossible. One nice feature is the view command which
allows scrolling back and forth in a file.
A couple of features that could be ported over are the telnet to a
serial port (port 5000) with password and telnet to a BSR device. As in
BSR/X10.
Doug
------------------------------
Date: Thu, 7 Jan 1993 15:54:44 -0500 (EST)
From: MIKEBW@ids.net (Mike Bilow, <MIKEBW@ids.net>)
Subject: REPEAT
To: crompton@NADC.NAVY.MIL, tcp-group@ucsd.edu
You can always cheat and call _setcursortype(_NOCURSOR) from the Borland
run-time library. (One of those RTFM things...)
The session descriptors are maintained as an array with a global base.
"Sessions" points to the first session data structure (struct sp*).
As a result, "Sessions[0]" is the first session data structure,
"Sessions[1]" is the second session data structure, and so on, up to
"Sessions[Nessions-1]". I think you can see from this explanation
and a little hunting in SESSION.C, especially in newsession() and
sessptr(), how to do what you want to do?
-- Mike Bilow, <mikebw@ids.net> (Internet)
------------------------------
Date: Thu, 7 Jan 93 16:03:53 EST
From: kz1f@RELAY.WESTBORO.LEGENT.COM
Subject: REPEAT
To: tcp-group@ucsd.edu
Doug writes:
When you create a newsession but not a socket - I.E. a local stream What
can you use with a loop to detect closure/reset of that session?
sp=newsession(.....)
for (;;) {
pwait(null);
if (??????)
get outta here
}
This was a pervasive problem in making the OS/2 version of nos. In that case
each session was asociated with a seperate task within the system, Doug, this
would be identical under NT as well. With this architecture for(;;) are
dangerous since the task never acually goes away, soon nos has reached the
system's max tasks. I had actually mentioned this "problem" to Phil yesterday
and asked if he had addressed this in his new kernel. I havent heard back yet.
What I did was change the api that could indefinately block a thread to return
EABORT in the event the task was "killed". By testing for this the task could
actually unwind itself and leave the system. This also required changing
killproc/killself and pwait as well as various blocking api. I realize Doug is
not asking abt how to implement nos as a real multitasking program but the
fix I came up with will also resolve his problem/question. Walt
------------------------------
Date: Thu, 7 Jan 93 17:11:25 EST
From: crompton@NADC.NAVY.MIL (D. Crompton)
Subject: REPEAT
To: MIKEBW@ids.net, crompton@NADC.NAVY.MIL, tcp-group@ucsd.edu
Mike,
Yes I found the _setcursortype and put it in. It works fine.
I have already done a lot of that hunting and it appears that when
you do a close or reset it does not seem to effect anything in the
session structure. The session is closed by freesession. From that
example that I gave I want to be able to detect that the session
was closed from within the loop - that is closed by a close or reset
at the net prompt. I have looked thru the session structure parameters
and even displayed some for debug while reseting and nothing seems to
change. I also was not able to find anywhere where this is currently
done in NOS because unlike tis repeat other functions have logical
ends - not an endless loop. I know (hope) I must be missing something.
Anyhow the way it is working right now is not bad the repeat session
closes as soon as you leave it. Being able to detect closure from
within would allow you to go back to the session but it is no big
deal.
Doug
------------------------------
Date: 07 Jan 93 19:21:57 CST
From: Jack Snodgrass <kf5mg@vnet.ibm.com>
Subject: Shared Interupts
To: <TCP-Group@UCSD.Edu>
Anyone know how shared interrupt processing for 4, 19.2kb async
devices performs compared to using individual interupts? If I have a
board and code that supports shared interupts, should I configure it for
that? If the answers yes.... anyone want to add Phil's shared interupt
code to Johan's code? Thanks.
73's de Jack - kf5mg
AMPRnet - kf5mg@kf5mg.ampr.org - 44.28.0.14
AX25net - kf5mg@kf5mg.#dfw.tx.usa.na - work (817) 962-4409
Internet - kf5mg@vnet.ibm.com - home (817) 488-4386
------------------------------
Date: Thu, 7 Jan 1993 20:52:49 -0800 (PST)
From: "Hank E. Eggers" <heggers@eis.CalState.EDU>
Subject: UNSUBSCRIBE
To: tcp-group@ucsd.edu
DELETE TCP-GROUP
UNSUBSCRIBE
------------------------------
Date: Thu, 7 Jan 93 23:43:05 EST
From: crompton@NADC.NAVY.MIL (D. Crompton)
Subject: update for directory code
To: Johan@ece.orst.edu
Fix to allow FTPCLI to use NOS curdir at session start as opposed to
using DOS's
----------------------------------------------------------------------
Line 255 - main.c - change line
init_dirs(&dirs,"");
**************************************************
Line 183 - ftpcli.c - change line
tprintf("Local Directory - %s\n",init_dirs(&dirs,Command->curdirs->dir));
**************************************************
New 'init_dirs' in dirutil.c - (ALSO change prototype in dirutil.h)
/* Initialize Structure cur_dirs - use current 'path' if given else
use drive/directory as derived from DOS curdrv/curdir
*/
char *
init_dirs(struct cur_dirs * dirs,char *path)
{
char buf[128],fullpath[128],*a;
int x,drive;
for(x=0;x<=26;x++)
dirs->curdir[x]='\0';
if (! *path){
drive=getdisk()+1;
getcurdir(drive,buf);
undosify(buf);
sprintf(fullpath,"%c:/%s",drive+'@',buf);
} else {
a=path;
if ((*(a+1)==':') && (isalpha(*a))){
drive=toupper(*a)-'@';
} else {
drive=getdisk()+1;
}
strcpy(fullpath,path);
}
dirs->curdir[drive]=strdup(fullpath);
dirs->drv=drive;
dirs->dir=dirs->curdir[drive];
return dirs->curdir[drive];
}
END OF CHANGE
Doug
------------------------------
Date: Thu, 7 Jan 93 14:30:41 EST
From: crompton@NADC.NAVY.MIL (D. Crompton)
Subject: update on repeat
To: johan@ece.orst.edu, tcp-group@ucsd.edu
Add the >>> lines to the 'dorepeat' function in main.c - dsp107a.zip
at ucsd and wg7j incoming.
while(MYsession==Current){
/* clrscr(); */
/* gotoxy seems to work better - turn cursor off?? */
gotoxy(1,1);
>>> _setcursortype(_NOCURSOR);
ret = subcmd(Cmds,argc,argv,p);
if(ret != 0 || pause(interval) == -1)
break;
}
>>> _setcursortype(_NORMALCURSOR);
keywait(NULLCHAR,1);
This makes the display easier to read with quick updates.
Doug
------------------------------
Date: Thu, 07 Jan 93 15:28:58 CET
From: BARRY TITMARSH <BTITMARS%ESOC.BITNET@vm.gmd.de>
Subject: WAMPES Convers Problems
To: TCP-GROUP <TCP-GROUP@ucsd.edu>,
Hello. Useing the wampes port 921129 done by dc1ik, is working fine with
old versions of Linux. Now that Linux has progressed there are now a number
of things not working correctly. One is the conversd daemon. Under Linux 0.99
this is acting strange, in that after it has made an auto connect to another
host soc 3600 this daemon is takeing 89 95 percent of the cpu. Before the
connect is made the conversd daemon only uses 0.9 to 1.0 percent of the cpu
I have also noticed that finger makes a disconnect when you make a finger
to a user on the wampes box, also ftp responds with 0 files found when
a dir NLIST is done in a directory that does have files in it.
Since the bug reports for this code go to you DC1IK Olaf, for the Wampes
that is ported to Linux.
please send any comment to me via internet and or tcp-group.
thanks to you,.
Barry. GM8SAU [linux 0.99p2 user.]
------------------------------
Date: Thu, 7 Jan 93 21:20:35 MET
From: erb@insu7.etec.uni-karlsruhe.de (Olaf Erb)
Subject: WAMPES Convers Problems
To: BTITMARS@esoc.bitnet (BARRY TITMARSH)
BARRY TITMARSH writes:
>
> Hello. Useing the wampes port 921129 done by dc1ik, is working fine with
> old versions of Linux. Now that Linux has progressed there are now a number
> of things not working correctly. One is the conversd daemon. Under Linux 0.99
> this is acting strange, in that after it has made an auto connect to another
> host soc 3600 this daemon is takeing 89 95 percent of the cpu. Before the
> connect is made the conversd daemon only uses 0.9 to 1.0 percent of the cpu
That's right. There's a problem in the select() stuff; Linus changed
something in ~linux/fs/select.c, and WAMPES still has some problems with it.
Here's a quick and dirty fix in select.c.
At the beginning there's something like #define ROUND_UP ....
Look around line 200, where this is used.
Near this there's something like
if (timeout <= jiffies)
timeout = 0;
I just commented this out, (#if 0 ... #endif) and all works fine again.
You can use this as a quick solution of your problem.
There was also (after(!) this fix) reported that 'net' eats up cpu-time.
This was caused by a bad V.24 cable that caused select() to return
immediately. Changing the cable solved this problem.
>
> I have also noticed that finger makes a disconnect when you make a finger
> to a user on the wampes box, also ftp responds with 0 files found when
> a dir NLIST is done in a directory that does have files in it.
The finger problem should not be WAMPES', because the NET program only
gates port 79 via tcpgate to Linux' IP, so you should take a look at your
fingerd.
FTP works fine for me:
220 dc1ik FTP version WAMPES-921130 ready at Thu Jan 7 21:06:35 1993
user ftp
331 Enter PASS command
pass guest
230 User "ftp" logged in
dir
200 Port command okay
150 Opening data connection for LIST /users/ftp
total 128
drwxr-xr-x 2 root root 48 Nov 19 05:50 bin
drwxr-xr-x 2 root root 64 Nov 19 05:50 dev
drwxr-xr-x 2 root root 64 Nov 19 05:50 etc
drwxr-xr-x 2 root root 48 Nov 19 05:51 lib
-rw-r--r-- 1 ftp ftp 125157 Jan 7 03:02 c-sources.taz
drwxr-xr-x 3 ftp ftp 176 Dec 29 21:40 pub
Get complete, 381 bytes received
226 File sent OK
73,
Olaf
--
----------------------------------------------------------
! erb@insu1.etec.uni-karlsruhe.de dc1ik@db0sao.ampr.org !
----------------------------------------------------------
------------------------------
Date: Thu, 7 Jan 93 19:36:05 PST
From: "Jerzy Tarasiuk" <JT@zfja-gate.fuw.edu.pl>
Subject: XSPAWN.... Revisited and fixed
To: "Brian A. Lantz" <BRIANLANTZ@delphi.com>
> Date: 07 Jan 1993 02:07:14 -0500 (EST)
> From: "Brian A. Lantz" <BRIANLANTZ@delphi.com>
> Subject: XSPAWN.... Revisited and fixed
> Message-Id: <01GT7Y7D1O7M8WWK2B@delphi.com>
> I pulled the JNOS107b sources off Wednesday afternoon and looked them over
> tonight. Well (sorry it took so long), here is the fix ;-)
>
> The thread was correct in diagnosing the problem... it was the interrupt
> vectors blowing the system away. The fix at first seems difficult, but is
> very simple. NOS only replaces a limited number of regular interrupt vectors.
> And when any NEW device sets up an IRQ vector, it goes though the setirq()
> routine. So, only two files need to be modified. XSPAWN provides an addvect()
> function that does all the dirty work.
>
> These have been tested pretty heavily, but only over the course of a few
> hours. There STILL MIGHT be other problems, BUT, I have XSPAWNed off and
> started up WINDOWS, to come back and find that all is well! Same with a
> second incarnation of NOS, Norton Utilities, etc. Seems to work fine, now!
>
> Hope this takes care of it! Enjoy!
Not so well. NOS can use packet driver and define procedure to be
called when new packet arrives. As I remember, the driver checks first
few bytes of code where it is to jump into, but it isn't enough.
If just these bytes are intact and other code is destroyed, this will
blow the system. In my configuration, it is not possible to fix it
by changing interrupt vectors or masking interrupts - if I'll mask the
interrupt used by ethernet card, I will be unable to access network
drives where are much of my data and almost all executable programs.
However, adding some code to packet driver interface can fix it - need
save information about any "registration", "unregister" from packet
driver on XSPAWN, then swap NOS to disk, and after swapping it back
into memory "register" on the packet driver again. Should work.
Note also need save interrupt mask on entry (to NOS) and restore it
on XSPAWN before restoring vectors - note the vector saved on entry
may be invalid if corresponding interrupt is masked.
But, anyway, congratulations on great step ahead.
73's, JT
------------------------------
End of TCP-Group Digest V93 #8
******************************
******************************