Date: Thu, 7 Jan 93 04:30:15 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 #7
To: tcp-group-digest
TCP-Group Digest Thu, 7 Jan 93 Volume 93 : Issue 7
Today's Topics:
CPU ID test code (4 msgs)
CPU ID test update
DPMI mode
Echo systems
forwarding ax.25 bulletins via smtp
Message CC's and SNR... (3 msgs)
New version of NOS!
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: Wed, 6 Jan 93 16:19:29 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: Wed, 6 Jan 1993 5:07:20 -0500 (EST)
> Message-Id: <930106050720.33ab@ids.net>
>
> I am trying to put something together that will allow identifying the
> type of CPU on the fly. Below is a debug script to make a 161 byte
> COM file that, when run, should tell you whether you have an 8088, a
> 80286, or an 80386/80486. It isn't very sophisticated, but it should
> serve the purposes of NOS. I would appreciate anyone who wants to try
> it doing so and letting me know what happens; I am especially interested
> to know what it thinks of NEC V20 CPUs and similarly oddball things.
Hello, Mike
I remember I had source (probably result of disassembly, with comments
added by me) of program able to distinguish 8088/8086/V20/80188/80186/
80286 (possibly also other Vx0; no ability to distinguish 80286 from
80386 and better CPU-s, it is quite old program wrote in 1987 or so),
and I wrote own program to check bus size (to distinguish 80386SX from
80386; I remember no one of my colleages was able to understand what
way the program works, but result was always correct...) and CPU.
I will look at your, the disassembled and my code, compare methods
used and send you some info about it. What CPU-s need distinguish,
is bus size meaningful (8088 vs 8086, 80386 vs 80386 SX, etc.) ?
73's, JT
------------------------------
Date: Wed, 6 Jan 1993 14:04:15 -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
Well, don't waste your time disassembling that thing. I will send you
the source code if you like. The only reason it did not go out with
source was that it would have been embarrassing if the program bombed.
:-) If it goes into NOS, it will obviously have the source released.
I can't see any reason to bother in NOS with distinguishing among the
8-bit processors (8088/8086/V20/V30/etc.). I know how to do that, but
it doesn't seem worth it. I also can't see any benefit in NOS to
distinguishing the 80386DX and 80386SX from each other, although I
would be interested in your code to do that. The only way I ever found
to tell them apart was by the different prefetch queue lengths, and
that requires self-modifying code.
The objectives I had were:
-- Distinguish three classes of CPU: 8-bit (8088/8086/V20/V30/etc.),
16-bit (80286), and 32-bit (80386SX/80386DX/80486SX/80486DX).
-- Make no use of undocumented features of the chips or operating
system. (Distinguishing between the 8088/8086 and the V20/V30
depends on the REP MOVS bug being present in the 8088/8086.)
-- Do nothing that could result in an exception or protected mode
trap (such as attempting to execute an illegal opcode).
-- Mike Bilow, <mikebw@ids.net> (Internet)
P.S. I have the real source to that 1987 program you are looking at
from disassembly. I'll mail it if I can find it.
------------------------------
Date: Wed, 06 Jan 93 23:06:53 MST
From: rnielsen@tapr.ampr.org (Bob Nielsen)
Subject: CPU ID test code
To: MIKEBW@ids.net (Mike Bilow, <MIKEBW@ids.net>)
Now if there was a way that I could use the ID to make NOS work with my
old 8 bit Compaq, that would be something. I think it must be a
bios-related thing, but it always hangs up as soon as it gets the net>
prompt. I have received several suggestions, but none of them seem to
work (NET, on the other hand, works like a champ.)
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 10:29:17 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: Wed, 6 Jan 1993 14:04:15 -0500 (EST)
> From: MIKEBW@ids.net (Mike Bilow, <MIKEBW@ids.net>)
> Message-Id: <930106140415.36e2@ids.net>
> Subject: Re: CPU ID test code
>
> Well, don't waste your time disassembling that thing. I will send you
The CPUID I disassembled 4 years ago. You program: disassembling took
less time than making a .COM file: DEBUG doesn't like LF-s, especially
it didn't recognize <LF> Q as Q and I needed press Alt-Ctrl-Del.
> I can't see any reason to bother in NOS with distinguishing among the
> 8-bit processors (8088/8086/V20/V30/etc.). I know how to do that, but
> it doesn't seem worth it. I also can't see any benefit in NOS to
> distinguishing the 80386DX and 80386SX from each other, although I
> would be interested in your code to do that. The only way I ever found
> to tell them apart was by the different prefetch queue lengths, and
> that requires self-modifying code.
I used almost same way: check prefetch, but not queue length (can be
different for different CPU-s and not necessarily directly related to
bus size) but amount of bytes read a time: 8-bit CPU read single bytes,
16-bit - words, and 32-bit - doublewords (if CPU needs to put address
on address lines to read opcode, it utilizes full bus size).
> -- Make no use of undocumented features of the chips or operating
> system. (Distinguishing between the 8088/8086 and the V20/V30
> depends on the REP MOVS bug being present in the 8088/8086.)
I suppose can distinguish 8088/6 from V20/30 and 80188/6 from V40/50
by instruction set - the NEC CPU-s have some extra opcodes. But for
80188/6 can get illegal instruction trap. For 80286 vs. V60 cannot
use this way if program is executed in protected mode - cannot catch
the trap. I don't remember what are the NEC-only opcode (instructions
like LOOPC/LOOPNC, as I remember) and don't have NEC databook here now.
> P.S. I have the real source to that 1987 program you are looking at
> from disassembly. I'll mail it if I can find it.
Fact, the source you sent seems to be the same program.
> Date: Wed, 6 Jan 1993 22:17:03 -0500 (EST)
> From: MIKEBW@ids.net (Mike Bilow, <MIKEBW@ids.net>)
> Message-Id: <930106221703.3a86@ids.net>
> Subject: CPU ID test update
>
> 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.
I checked it on Intel 8088, 80286, 80386DX, 80486DX, NEC V20.
And can ask one of my friends to check on 80386SX. I don't know if
anyone here has 80486SX (is such an animal at all ?).
> By the way, I received a couple of private mail suggestions that I
> look at the code in some of the later versions of NOS that sets the
> "isat" flag automatically, the am_i_an_AT() function in PC.C. First,
> I wrote that routine. Second, all that routine does is look at the
> machine ID byte in the system BIOS ROM. This works fine for what it
> does in NOS, which is decide wether the high resolution timers are
> available and whether high numbered IRQs are allowed, but cannot tell
> the difference among non-XT machines (80286 vs. 80486DX, for example).
Some care should be taken using the machine ID byte. Some old XT-s
have random data there (and accidentally it can be same as AT ID).
Other way AT can be distinguished: DMA channel 0 is used for memory
refresh on XT and not on AT or better - read count or address register
several times and check if it changes (note need disable interrupts
and read twice 8 bits to get both low and high byte; on XT at least
one of these bytes will change every 18us, on AT they are stable).
High resolution timer: can reprogram 8259 channel 0 from mode 3
(Square Wawe Rate Generator) to mode 2 (Rate Generator), this works OK
(at least worked OK on every computer I tried); no need to bother
about distinguishing AT or reading 8254 status register.
CPUID (you probably know it well, but idea of detecting CPU bugs may
be interesting, note there is known bug in 80386 32-bit multiply):
80286/8 - first on which push SP pushes old SP
80186/8 - first on which SHL AL,CL with AL=0xFF,CL=0x21 doesn't set ZF
V20/30 - REPZ SEGES LODSB (initial CX=0xFFFF) executed completely
8/16 bit recognized by prefetch queue length - >6 => 16-bit
NDP check: FNINIT; JMP; FNSTCW cw; JMP; JMP; CMP Hi(cw),3; NZ => no NDP
8087/287: FDISI; FSTCW cw; TEST cw,1 SHL 7; Z => 80287, NZ => 8087
(distinguish by interrupt disable flag set by FDISI)
Errors detected: INT 1 after POP SS possible - need replace CPU
BIOS don't know about NDP - need flip SW1-2
My CKCPU (nothing interesting):
I tried to use code PUSH CS; SIDT [BP-8] - the SIDT is decoded by
8088/188 as POP CS; ADD [BP-8],CX. From 80188 POP CS is illegal
opcode, this allows to distinguish 8088, 80188, 80286 (or better).
80286/386 can be distinguished by LOCK RET - illegal on 80386.
(but use of the illegal opcode trap isn't good method).
Your program checks setting/clearing FLAGS bits (I know this method
but didn't knew it 4 years ago when was writing my program). Probably
it is enough to try set NT bit (1 SHL 14) and check value of bits 15
and 14: 11-8088/188, 00-80286, 01-80386/486. Don't forget to restore
original NT on 80386 - or it can cause problems with multitasking.
Example program may be: PUSH CX; PUSHF; POP AX; PUSH AX; AND AH,7Fh;
PUSH AX; XOR AH,40h; PUSH AX; POPF; PUSHF; POP AX; POP CX; POPF;
MOV CL,0Eh; SHR AX,CL; SHR CX,CL; XOR AL,CL; POP CX.
Result: 2 for 8088 or V20, 0 for 80286, 1 for 80386 or 80486.
(can SUB AL,2; SBB AL,0; INC AX; AND AL,3; to get 1/2/3)
73's, JT
------------------------------
Date: Wed, 6 Jan 1993 22:17:03 -0500 (EST)
From: MIKEBW@ids.net (Mike Bilow, <MIKEBW@ids.net>)
Subject: CPU ID test update
To: tcp-group@ucsd.edu
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.
By the way, I received a couple of private mail suggestions that I
look at the code in some of the later versions of NOS that sets the
"isat" flag automatically, the am_i_an_AT() function in PC.C. First,
I wrote that routine. Second, all that routine does is look at the
machine ID byte in the system BIOS ROM. This works fine for what it
does in NOS, which is decide wether the high resolution timers are
available and whether high numbered IRQs are allowed, but cannot tell
the difference among non-XT machines (80286 vs. 80486DX, for example).
The test program I sent out yesterday directly manipulates the CPU,
and should be fairly reliable.
-- Mike Bilow, <mikebw@ids.net> (Internet)
------------------------------
Date: Wed, 6 Jan 93 18:36:50 PST
From: "Roy Engehausen (8-457-2712)" <enge@almaden.ibm.com>
Subject: DPMI mode
To: TCP-GROUP@UCSD.EDU
I have started playing with Turbo Pascal's DPMI mode. This puts the
computer into 286 mode and allows use of more than 640K. In addition,
overlay management is all automatic. I converted 95% of my BBS
program to it and it is real neat.
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
------------------------------
Date: Wed, 6 Jan 93 16:15:35 MST
From: Larsen Karl VAL-C 678-3145 <klarsen@wsmr-emh73.army.mil>
Subject: Echo systems
To: tcp-group@ucsd.edu
I am a sysop of a Fido Net bbs and we have about 200 "echo"
areas we can run. Internet is said to have no less than 10,000 echos and
this is one of them. Over the past year I have asked several questions
and received many direct repies with help. This is not in itself bad but
it does defeat the main use of echos.
As a teacher, when a student asks a question I drop everything
and answer that question from as many ways as possible. This is because
if a student asks a question, 99% of the class SHOULD have asked the
same question.
So when I ask if anyone has ever got nos working with a 3 com
505 card, I expect many answers. I also expect that others on this echo
are looking for the same answers...
73, karl k5di@k5di.nm.usa.na
------------------------------
Date: Wed, 6 Jan 93 12:46:47 EST
From: crompton@NADC.NAVY.MIL (D. Crompton)
Subject: forwarding ax.25 bulletins via smtp
To: nos-bbs@hydra.carleton.ca
Jack,
This gets right back to the 'smtp gateway yourself' argument!
Here is how I do it (from memory)
smtp gateway myself
in rewrite ---
*@wa3tsw* bbstsw
in forward.bbs ---
wa3tsw
ax25 wa3tsw - or whatever
wa3tsw
bbstsw
---------
This is obviously a very simplified picture of my files. WA3TSW is
a full service BBS (not NOS) that I routinely send and receive messages
from. Users on my system or connected to my system can send mail to
a user on his system with the send line 'SP w3xxx@wa3tsw.bbs' the
suffix .bbs can be anything - the complete '.epa.usa.na' or whatever.
It does not matter since his system does not care and the rewrite with
the trailing '*' will take anything. Another example of areas is:
in rewrite ----
qst@arl* ARL_QST
in alias ----
ARL_QST arl_qst !arl_qst
An area call arl_qst is setup. An incoming bbs sends mail to match
qst@arl. It is rewritten to ARL_QST. Alias then sends it to the arl_qst
mailbox locally and to NNTP locally. I have MANY entries in my rewrite
file to satisfy all of the possible combinations. The last entry being
a catch all so that I can find things I missed!
USERS that use ME as a server set there 'smtp gateway' to ME. Therefore
if they enter mail to xxx@wa3tsw.bbs or anything else that is not locally
resolved it comes to me and goes thru my rewrite/alias rules. I can act
as both an SMTP and BBS mailserver in this way. BBS's send mail to my
system which is then usually POP'ed via TCP or in the case of bulletin
areas mostly NNTP'ed.
The argument has been to either keep the servers job simple and let
the user enter some complicated xxx%xxx@xxx.xxx.xxx or some simplified
name that is resolved at a server. I opted for the later because if you
make things to complicated for the users they won't use it. Not that they
are dumb or incapable but more because of laziness! It's human nature.
The other gotcha that you have to be careful of is sending large
distributions via alias to BBS's.
If your alias has..
ALL w3eee@w3eee.ampr.org w3rrr w3ttt@w3ttt etc.
It will fail because BBS mail can only have one address and what will
happen is that the 'to' address to w3rrr (a bbs) will be the w3eee@w3eee.
ampr.org address (actually it will be the LAST address in the group it
gets scanned backwards).
The quick answer is to use the forward.bbs to forced the proper address.
in forward.bbs ----
w3rrr
ax25 w3rrr
w3rrr w3rrr@w3rrr <<< change the 'to' address when sending
-----------
So you would need a forward.bbs entry for EACH specific station in
this case. Another BBS/SMTP compatability problem.
Doug
------------------------------
Date: Wed, 6 Jan 93 8:01:34 CST
From: andyw@aspen.cray.com (Andy Warner)
Subject: Message CC's and SNR...
To: tcp-group@ucsd.edu (TCP Group)
Doug wrote:-
> I just had a complaint about sending personal mail CC'ed to the
> TCP-GROUP. It kinda hit a nerve because first of all many return
> addresses appearing on this group are bogus. The only way in many
> cases to return info is to send it to the group.
>
> Actually well before this I was thinking somewhat the opposite.
> Many times I send a message that could have broad interest and
> I get personal return mail which really would be of interest to
> [...]
> am sure it is with others. Free flow of information is what it is
> all about. If we all had our own private dialogs there would be no
> reason for a group to begin with.
It was me that sent Doug that note. I have no problem with
CC'ing stuff to the group, I only suggested he count to 10
before doing it.. The particular note that pushed me over the
edge was :-
> Dave,
>
> I checked UCSD and the last BM is dated July 1991 in the BM directory.
> Is this the one you are talking about?
>
> Doug
Which is (without any context) pretty meaningless. This was a bad
example for me to pick, since the return address was bogus..
Since I know tcp-group gets a very wide distribution, over some
very low-bandwith links, I just thought a little prudence would
be a good idea. I know it takes 2 secs to read it & delete it, but
it takes a lot longer to deliver it sometimes..
So, please, everyone, CC to the group where appropriate, but just
ask yourself if it passes that test first.
--
andyw. (N0REN/G1XRL)
andyw@aspen.cray.com Andy Warner, Cray Research, Inc. (612) 683-5835
------------------------------
Date: Wed, 6 Jan 93 10:58:15 EST
From: Steve Urich <steve@zero.com>
Subject: Message CC's and SNR...
To: TCP-Group@UCSD.Edu
Hello Doug you wrote:
> I just had a complaint about sending personal mail CC'ed to the
> TCP-GROUP. It kinda hit a nerve because first of all many return
> addresses appearing on this group are bogus. The only way in many
> cases to return info is to send it to the group.
Lets give Doug a break, he's at a .mil site. Everyone thats in the
know knows that .mil .gov sites do not handle uucpmaps therefore
all those none domain addresses .uucp etc will bounce back. You
generally have to have a domain name type address in order for
these sites to return mail. If I'm wrong well, sorry no flames
please :-)
Steve
--
|Stephen Urich| Internet:steve@zero.com | "Cattle mutilations |
|NIC: SU2 | UUCP:uunet!beyonet!steve | are up!" --Sneakers |
|ARS: WB3FTP | Packet:WB3FTP@WB3FTP.#EPA.PA.USA.NOAM | ax25<->PBBS<->IPGATE|
|Bensalem, PA |Radio:wb3ftp@wb3ftp.ampr.org[44.80.8.44]| TCP/IP-FTP-SMTP-UNIX|
------------------------------
Date: Wed, 6 Jan 1993 22:00:00 -0500 (EST)
From: MIKEBW@ids.net (Mike Bilow, <MIKEBW@ids.net>)
Subject: Message CC's and SNR...
To: steve@zero.com, tcp-group@ucsd.edu
I don't think Brian much minds MIL sites or anyone else using UCSD.EDU
as a remailer for TCP Group replies if necessary. I often reason that
the original message found to UCSD, so there is a decent chance that
UCSD knows how to get the mail back. For example, a site that could
not resolve addresses in the UUCP domain might be able to send mail to
the UUCP indirectly: steve%beyonet.UUCP@ucsd.edu.
-- Mike Bilow, <mikebw@ids.net> (Internet)
------------------------------
Date: Wed, 6 Jan 93 16:46:38 PST
From: "Jerzy Tarasiuk" <JT@zfja-gate.fuw.edu.pl>
Subject: New version of NOS!
To: Phil Karn <karn@unix.ka9q.ampr.org>
> Date: Tue, 5 Jan 93 02:14:30 -0800
> From: Phil Karn <karn@unix.ka9q.ampr.org>
> Message-Id: <9301051014.AA01805@unix.ka9q.ampr.org>
> s930104.zip - ZIP archive of latest versions of sources extracted from RCS
> for those without RCS (you'll probably have to hack the makefile
> to remove references to the RCS files)
For those without RCS: on zfja-gate (148.81.6.100) is RCS55.ZIP (both
source and executable for DOS, 387k) in guest login directory - can get
it by FTP (or try by mail to listserv@zfja-gate.fuw.edu.pl, but it'll
produce over 0.5MB mail file - can it pass through network ?).
> 2. I've found another good use for the MD-5 hash function. The FTP
> server now supports the experimental XMD5 command. It takes a file
> name as an argument and returns the 16-byte MD5 hash value for that
> file in hex. The client uses XMD5 to support several nifty new
> features: the "compare" and "mcompare" commands, and the "update"
> flag.
It would be good idea to compare length/date/time of files first, if
remote file we want to retrieve is older than local and has same size
it is surely same file... (assuming we are retrieving only the file,
not putting it on remote server; date/time gives no information if
we could both put file on remote server and get it from it in past).
> Comments are invited on the behavior of the scrollback feature. For
> example, when a screen clear sequence is sent, should the screen be
> written into the scrollback file? I don't do this right now, although
It can be quite useful when NOS is used for connection to VM host in
fullscreen mode - the VM host displays full screen of data and requires
user to press CLEAR key, then it sends clear-screen sequence and
displays next data. However, I have a program usable in way like TSR
which recognizes when VM host wants to send more data, saves screen to
a file and sends the CLEAR key code... Was useful for plain text file
transfer before our VM (PLEARN.BITNET=plearn.edu.pl) got TCP, FTP...
> Well, have at it, and have fun.
One question: how much of computer memory it needs now ?
73's, JT
------------------------------
Date: 07 Jan 1993 02:07:14 -0500 (EST)
From: "Brian A. Lantz" <BRIANLANTZ@delphi.com>
Subject: XSPAWN.... Revisited and fixed
To: tcp-group@ucsd.edu
Well, after following all of the XSPAWN thread, I figured that I should
find out whether XSPAWN was fix-able and, if so, incorporate it into
TNOS before the initial release.
I pulled the JNOS107b sources off Wednesday afternoon and looked them over
tonight. Well (sorry it took so long), here is the fix ;-)
(Did that sound as obnoxious as I think it did?)
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!
-----------------------------------------------------------------
Modify main.c:
Add the following to main() IMMEDIATELY after the local variable declarations
so that they are set up FIRST
#ifdef XSPAWN
/* These vectors WILL be intercepted by NOS in COMMAND.ASM
Go ahead and tell XSPAWN to save their current state, now.
Vector 0x23 is also used by NOS, but is ALREADY being preserved
by the XSPAWN routines */
addvect (8, CURRENT);
addvect (0x10, CURRENT);
addvect (0x13, CURRENT);
addvect (0x1b, CURRENT);
addvect (0x21, CURRENT);
addvect (0x24, CURRENT);
addvect (0x28, CURRENT);
#endif
-----------------------------------------------------------------
Modify pc.c:
The setirq() function needs a few additions. It is included here complete.
int
setirq(irq,handler)
unsigned irq;
INTERRUPT (*handler)();
{
/* Set interrupt vector */
if(irq < 8){
#ifdef XSPAWN
addvect(8+irq, IRET); /* tell XSPAWN to ignore this vector */
#endif
setvect(8+irq,handler);
} else if(irq < 16){
Isat = 1;
#ifdef XSPAWN
addvect(0x70 + irq - 8, IRET); /* tell XSPAWN to this one */
#endif
setvect(0x70 + irq - 8,handler);
} else {
return -1;
}
return 0;
}
-----------------------------------------------------------------
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]
------------------------------
End of TCP-Group Digest V93 #7
******************************
******************************