FIDONEWS -- 07 Oct 85 03:02:43 Page 1 Volume 2, Number 34 7 October 1985 +----------------------------------------------------------+ | _ | | / \ | | - Fidonews - /|oo \ | | (_| /_) | | Fido and Fidonet _`@/_ \ _ | | Users Group | | \ \\ | | Newsletter | (*) | \ )) | | ______ |__U__| / \// | | / FIDO \ _//|| _\ / | | (________) (_/(_|(____/ | | (jm) | +----------------------------------------------------------+ Publisher: Fido 107/7 Chief Procrastinator: Thom Henderson Review Editor: Andy Foray Fido Utility Review Editor: Ben Baker Regional Bureau Chiefs: Network hosts everywhere Fidonews is published weekly by SEAboard, Fido 107/7. You are encouraged to submit articles for publication in Fidonews. Article submission standards are contained in the file FIDONEWS.DOC, available from Fido 107/7. Disclaimer or don't-blame-us: The contents of the articles contained here are not our responsibility, nor do we necessarily agree with them; everything here is subject to debate. We publish EVERYTHING received. NEC SCHMEC The NEC v20 and v30 chips certainly seem to have hit a responsive cord. I guess there's a lot of appeal to the idea of boosting the speed of your computer for only a few dollars. I can well understand it. When I first started working on the PC I found it annoying that system response time didn't get any better after five o'clock. A salesman for one of our clients would claim that a major advantage of using a PC was "consistent performance". Our usual response was, "Yeah, consistently bad." These days I just suffer along, and keep a book handy for those long compiles. It's still nothing like having a Honeywell 6640 at your beck and call, but I've gotten used to it. FIDONEWS -- 07 Oct 85 03:02:46 Page 2 Oh, it's not all bad, by any means. At least I own my own hardware now. I no longer have to worry about moving all my stuff every time I change clients. Still, it could be faster. By all appearances I'm not the only one who feels that way. There certainly seems to be quite a market for "accelerator boards". Greater speed also seems to be the main reason people want AT's. And now all this fuss over the NEC chip. It's understandable. An old maxim among programmers states that "there's no such thing as enough." Everybody will always want more speed, more memory, more disk space. Any time you put a limit on anything, someone will hit that limit and complain about it. A side note and example: We once worked on a project where there was supposed to be an exceptions table. The client said to allow room for ten exceptions, since he'd never really need more than three or four, but wanted to play it safe. We nodded our heads, and made room for a hundred. A year later we were called back to expand the size of the table. As for the NEC chip, there seems to be some disagreement on how well it really works. I'll let you read the reports and decide for yourself. I also hear that Intel is suing NEC, claiming that it's a straight copy of the 8088. If this is true, then how could it be faster? Not being a lawyer, I don't know. I find it amusing, though. You see, a few years back Datapoint was suing Intel, claiming that the 8008 was a straight copy of a Datapoint machine -- the exact same logic circuitry, just etched on a single chip. (I've since heard it rumoured that they settled out of court.) People will always want more, and vendors will always claim to give it. There will always be a faster machine, a bigger disk, and so forth. As my partner keeps reminding me, if you don't want your equipment to become obsolete in a month, you're in the wrong business. FIDONEWS -- 07 Oct 85 03:02:47 Page 3 ============================================================ NEWS ============================================================ THE COMPUTER UNDERGROUND pre-publication preview This is a pre-publication, and off-the-wall review of the the hottest and most realistic treatment of computer crime (mainly getting unauthorized mainframe access) I've seen. Not only do they have the logic of how to do it, they have sample program listings!!!. Most stuff came from pirate BBS systems. COMPUTER UNDERGROUND has stuff on ARPANET, MILNET, VAXs, IBMs, Telenet, Tymnet and even a program listing for how to crack Dialog passwords! Most folks running mainframes say it can't happen to them. COMPUTER UNDERGROUND shows it can not only happen to them, as portrayed on TV, but shows how incredibly simple it is because of sysop stupidity/laziness. Even the government should read this book and give it to the FBI as part of its training on busting crashers and data pirates. The book exposes some of the weakest links in datacom security at major corporations. This book is from the same publisher who brought you how to get a new identity, how to make bombs in your kitchen, etc. Send for information to the publisher: Loompanics Unlmited P.O. Box 1197 Port Townsend, WA 98368 If you think this book is as dangerous and revealing as I think it is, you'll get your friends to read it and upgrade their mainframe systems. Get ahold of Computer Underground and show folks what is really going on. Please pass on this notice. We are talking really big databases here!!! Best, Sophie Tucker from Spiv's FidoNet in San Jose. ------------------------------------------------------------ FIDONEWS -- 07 Oct 85 03:02:49 Page 4 A Modest Proposal Kurt Reisler SYSOP FIDO 109/74 & 109/483 Recently I have been receiving a lot of inqueries about where to obtain copies of the latest version of FIDO. Although I maintain both the DEC Rainbow and the IBM PC versions for downloading on FIDO 109/483 (Wash-A-RUG), and I know that they are also available on FIDO 100/22, 101/27 and 125/1 (of course), I would like to be able to direct these individuals to the nearest "distribution" nodes. So, I would like to propose the following. I would like to build a list of "distribution" nodes, their locations, phone numbers, and versions of FIDO that the maintain (ie DEC, IBM, SANYO, etc.). Those of you who are maintaining FIDO distributions on line, please let me know via FIDOMAIL, and I will compile all of this information into a list which can be published in the FIDONEWS, as well as distributed via UUCP/USENET to the rest of the world. So, please send the requested information to me (SYSOP) at FIDO 109/74 (The Bear's Den), and I will get started compiling this FIDO distribution list. Thanks - Kurt ------------------------------------------------------------ FIDONEWS -- 07 Oct 85 03:02:50 Page 5 Submitted by Donald Larson, Node 115/333 *** MORE REGARDING THE NEC V20 MICROPROCESSOR CHIP *** Downloaded from another Chicago BBS system The following note appeared recently on USENet (net.micro). It seems to be the best summary so far of the NEC V20/30 - iAPX86/88 controversy. I'm posting it in it's entirety: From: tweten@AMES-NAS.ARPA (Dave Tweten) Subject: Re: NEC V20 ---> 8088 Date-Received: 16 Sep 85 08:45:42 GMT I recently bought an NEC V20 and installed it in my Z-151, which I am using to write this message. When I pried the 8088 out from next to my 8087, I noticed that it too had been a NEC part. Contrary to earlier comments in this forum about NEC 8088s not working with 8087s, it had worked flawlessly with my 8087 for the previous year. Preliminary experience is that the V20 speeds up some programs noticably, and has no effect on others. That is to be expected. If a program is 8087 limited or I/O limited, speeding up the 8088 will do no good. It has worked at least as well as the 8088 for any program I have tried. The only "negative" effect of the V20 is it causes Zenith's disk-based diagnostics for CPU-board crystal frequency, and for floppy-disk driver crystal frequency to fail. I presume the tests compare crystal cycles against a wait-loop counter. Since the NEC V20 "waits faster" the tests fail. Sorry, no time yet to do benchmarks. From: Charles R. LaBrec I haven't really heard many specifics of the NEC V20. Is it really a case of design stealing or just a case of duplicating the 8088 instruction set? Would someone care to enlighten me? I don't presume to be an engineering law expert, but by no strech of my imagination can I conceive to the V20 being an 8088 carbon copy, either legal or illegal. The following information was gleened from Intel's "iAPX 88 BOOK" and from the NEC document titled "V20, uPD70108, HIGH-PERFORMANCE 16- BIT MICROPROCESSOR, PRELIMINARY INFORMATION", dated May 1985. The time for a register-to-register ADD is quoted as three clocks for the 8088, two clocks for the V20. NEC's literature claims that is due to dual 16-bit on-chip busses for the V20, as opposed to a single bus in the 8088. That supposedly permits two-cycle register-register instructions (get both operands, return result), where the 8088 uses three (get one operand, get the other, return the result). FIDONEWS -- 07 Oct 85 03:02:52 Page 6 A quick scan through the respective instruction timing charts indicates that the relationship holds for all trivial two-register instructions (this obviously doesn't apply to multiply and divide). Intel's register-register 16-bit operand, 32-bit result multiply is quoted at 118-113 clocks. NEC's is quoted as 41-47. The equivalent divide times are 165-184 cycles for Intel and 38-43 for NEC. Yes, I too noticed that NEC claims to divide faster than they multiply, and I can't explain it either. NEC claims to use a separate address resolution unit on the chip, instead of using the arithmetic unit. Their effective address calculation time is two cycles for any mode. Intel's ranges from 5 to 12, depending on mode. The NEC chip has an expanded instruction set. By my estimation, it includes all the 80186 set plus several more. It has bit-field insert and extract (perhaps useful in low level graphics?). It can test and manipulate individual bits in memory. It has packed decimal string add, subtract and compare. It has a BCD digit rotate instruction. Those are the highlights (as I see them); there are several more instructions I haven't mentioned. There is also a complete 8080 emulation mode which interests me not at all. In summary, it appears to me that if the V20 is a "pirate" 8088, then the Z-80 was a "pirate" 8080. Is our chauvinism showing? ------------------------------------------------------------ ------------------------------------------------------------ 18:33:11 9/17/1985 NEC V20 CPU chip Triple 8088 speed. The NEC V20 CPU chip is an 8088 CPU chip replacement. Speed improvements of 10-40% have been claimed for the chip. It may be that these percentage increases in speed understate the actual improvement attributable to the chip alone, since they may include disk operations or other operations that are not CPU-intensive. The program CPU.COM tests the speed of a CPU with minimal RAM access and no disk I/O. The speed of the CPU is almost TRIPLE the speed of the native Intel 8088: ------------------- C>cpu CLOCK SPEED CHECKER (minimal RAM access), please wait... Execution time should be 10.00 secs if 4.77 Mhz clock & no WAITs on RAM access Actual execution time here was 03.35 seconds FIDONEWS -- 07 Oct 85 03:02:54 Page 7 Effective clock speed = >.23 Mhz C> ------------------- The above effective clock speed of ">.23 Mhz" is 14.23 Mhz. Evidentally the program CPU.COM did not anticipate double- digit clock rates. The above test was performed on an IBM Portable PC. This chip can be purchased from JDR Microdevices for about $20. See a recent issue of Byte for their ad. Zider Brothers, San Francisco. 17:17:40 9/23/1985 NEC V20 CPU chip PPC 70% speed improvement. Further to the earlier note on the NEC V20 chip. Tested with the system speed test SI in the Norton Utilities Version 3.0 on an IBM Portable PC. Factor of 1.7 times the PC: ------------------------ C>si SI-System Information, Version 3.00, (C) Copyright 1984, Peter Norton IBM/PC Built-in BIOS programs dated Monday, November 8, 1982 Operating under DOS 2.00 4 logical disk drives, A: through D: The operating system reports 512K of memory A test of random access memory (RAM) finds: 512K from hex paragraph 0000 to 8000 32K from hex paragraph B800 to C000 (some may be phantom memory) BIOS signature found at hex paragraph C800 Programs are loaded at hex paragraph 1AF2 following 110,368 bytes of system memory Computing performance index relative to IBM/PC: 1.7 C> ----------------------------------- Zider Brothers, San Francisco. 17:21:44 9/23/1985 NEC V20 CPU chip - Pfaster286 Incompatible with Pfaster286 board. FIDONEWS -- 07 Oct 85 03:02:55 Page 8 According to a telcon with Phoenix Software Associates, the NEC V20 chip is incompatible with their Pfaster286 coprocessor board. The Pfaster286 software uses the PUSHA (Push All) instruction to determine if the chip in use is the 80286 or the 8088. The 8088 gives an error if this instruction is attempted. But the NEC V20 has implemented this instruction (80186 instruction set) and gives no error. A revision to the software (or hardware?) will be coming Real Soon Now. Zider Brothers, San Francisco. ------------------------------------------------------------- Just thought I'd add some further wood onto the fire regarding the NEC V20. Although I do not support the issue of hardware piracy, if the information above regarding instruction set and architecture is correct, I must admit that I too fail to see how one could claim it as a copy. Instruction set compatability has been around since the System 360 series came out. Also, regarding the issue of selling below cost as a method of attempting to destroy competitors was discussed in the last issue. Although I can't prove that it applies in this case, Japanese firms tend to make decisions based on long term planning. Although any chip is expensive while a firm is "ramping up", the cost is driven down by high demand and improvements which cause higher yields. American history in chip building bears this out. Zilog introduced the Z-80 series at about a tenth of the Intel product cost and managed to survive over the long run. Although I'm not trying to create a war, I would really like to find out the straight story from someone who is more of a student of MPU architecture and associated micro-code regarding the issue of whether the V20 is an illegal copy or not. Please feel free to enter any and all rebuttals in this forum or on Node 115/333 directly (312-397-6888) or via Fidomail. Donald Larson Sysop Node 115/333 Attache Node ------------------------------------------------------------ FIDONEWS -- 07 Oct 85 03:02:57 Page 9 PRIVATE or PUBLIC An ongoing debate by Karl Schinke, (sysop of The Wizards Tower, 107/16) There has been a debate here at The Wizard's Tower, and on other boards, Fido and non-Fido, as to whether to be public, private, semi-private or whatever. The question is this: we as Sysops of our boards are responsible, and may in fact be legally liable, for the content of our boards. As much as we may desparage the current legal thinking, it seems real enough that we have some obligation to keep our boards legal. The problem, of course, is that there is no known way for a program to sieve the messages and files on a board for their content, to determine if they represent "shady" activities, so the Sysop must manually scan the stuff periodically. But even then, what do you do? You kill the message, remove the file, etc. but by then, damage may have been done, and you, dear sysop, have been unwitting accessory to whatever. And what recourse do you have? I spoke to my lawyer when I started the board. He suggested posting a disclaimer (which we did) and close scrutiny (which we do), but didn't think the disclaimer would actually hold up in court, if it came to that. We here at "The Tower" do not have a terrific answer to share with you, but a policy which has (so far) seemed to work: we register our users. We don't care what username people log in with, thereby preserving anonymity from other users, but we require that users register their real names, addresses, and vox phone numbers with us before they may download or leave messages. The questionnaire explains the policy, and promises not to use the information (sell a mailing list) or disclose it to other users. Unregistered users may read public messages, list the files directory, etc... basically snoop around, and decide whether they like the place before registering. Initially, this was all we did. But we determined, by spot-checks, that some users were lying- gave non- existant addresses, phone numbers of people who didn't know a computer from a cigarette machine, and so forth. Consequently, we altered our policy to a verification scheme, we call registrants by voice phone. The premise, of course, is that if anyone misbehaves, we've "got their number" and can point the fickle finger. So far, all our users have been well behaved. Of course, since the vast majority of BBS'ers are honest, well behaved people, they may have been anyway. We can't actually tell if we discouraged any "unwelcome guests". A few one-time callers have left messages to sysop with scatological or otherwise disparaging comment, but in the main, folks seem to go along with us. The one problem, of course, is the trouble we have of making those darn phone calls! FIDONEWS -- 07 Oct 85 03:02:59 Page 10 If anyone has an idea how we can protect ourselves without all this hu-hu, please drop us a line, or a rebuttal in this newsletter. ------------------------------------------------------------ FIDONEWS -- 07 Oct 85 03:02:59 Page 11 Corporate Nets and Nodes As many of you realize, Fido has spread far beyond the wildest imagination of any of the original planners whose intent was to develop a hobbiest network. Fido and FidoNet have caught the attention of many Fortune 500 Corporations. Some are obvious from the nodelist and others are buried under disquised names, some have 1000 series private nets and others are out there doing their own thing. Since the beginning of nodelist administration in St. Louis I have attempted to keep records of the corporations that have obtained Fido. We would like to share this list with our users with the intent that perhaps we can obtain more information for our database. If you have information on these or other Fortune 500 Fido's that you would like to pass on to 1/0 I would appreciate the data. The list I currently have, which is not all verified, is as follows: 3M Bendix Boeing COMPAQ Computer CONTEL Department of Commerce Dupont Environmental Research Laboratory GMCC General Motors Georgia-Pacific Grumman Honeywell Hughes Aircraft Internal Revenue Service L5Net Gateway McGraw Hill and BYTE Magazine Mountain Bell (or whatever their new name is) NASA NOAA National Park Services Phoenix Software Southwestern Bell Telephone Co. TWA US Professional Golfers Association USRobotics Ziff-Davis and PC-Week plus many many more which I don't know about... We would like to hear from our Corporate Fido's. Please send a message to Ken Kaplan at 1/0 (314-576-2743). Thanks for your support and keep spreading the word, Ken Kaplan FIDONEWS -- 07 Oct 85 03:03:01 Page 12 FidoNet Administrator National Net (1/0) ------------------------------------------------------------ FIDONEWS -- 07 Oct 85 03:03:01 Page 13 Tom Jennings Fido 125/1 30 Sept 85 NEC 'V' Series Processors: A review I purchased a NEC V30 (the 8086 replacement; the V20 is the 8088 replacement) this past month, and was a bit disappointed with the results I got. The V20 is actually an 8088 pin compatible 80188 minus the onboard IO devices, and V30 ditto 8086. The instructions marked "Enhanced" in the NEC documentation are the new, Intel, 8018x instructions; the ones marked "Unique" are unique to the NEC series. I have not compared clock cycles V30 vs. 80186, etc, but I would bet they are the same. I was told of wondrous speed increases, though the range was given as "5 - 80%", which of course means down in the 5% range is what you get; this is of course what I found. I have a Multibuss based machine running an Intel SBC86/12A processor card, which uses an 8086, and modified to run at 7.3MHz. I run MSDOS 3.05 on it. I use it for all my work, including compiling Fido, documentation, etc. I use the Lattice compiler, which is a fine program though on the slow side. I figured that if I could get a real life 20% speed increase I'd be very happy. It is not possible to do "seat of the pants" testing with something like this; you have to set up SOME sort of test. I did all testing on an empirical basis. I do not use the Seive of Erasthenes, bubble sorts, or other arcane things day to day. I edit, compile, and other things like most everyone else. One thing I do not do is use spreadsheets or other "math intensive" programs. The V series chips will NOT necessarily speed up programs that use (or could use) the 8087 coprocessor. You will hear that the V series chips are substantially faster doing "math" than the Intel parts. This is absolutely true, however, you will rarely see the advertised speed increases supposedly possible. The reason for the less than advertised speed increase is that even in a program such as a spreadsheet, the number of non-math instructions (jumps, logical operations, bit testing, register and stack manipulation, etc) that any CPU does far outnumbers the math type instructions (multiply and divide mostly). Even if multiply and divide took zero time, your programs would not take zero minutes to execute. This is not to say that there are not isolated FIDONEWS -- 07 Oct 85 03:03:03 Page 14 incidents; this means that plugging in this chip, or any other real or fictional device, will not get you monstrous speed increases. The tests I did are admittedly systems oriented tasks, though they are very applicable to estimating the performance you will get in normal, daily use. The tests are as follows: (a) Fido Compile. This consisted of a Lattice compile of a number of Fido BBS modules, ones that it was convenient (and easily repeatable) to cause a recompile. (I use a MAKE type system, and I need to fool it.) This test was the "all around" test; Lattice seems to spend less than 1/4th its time doing disk IO, mostly it seems to be "working" with the program source in memory. Lattice is a predominantly compute bound program. (b) LISTGEN NODELIST.256. This is definitely compute bound; compiled BASIC string manipulation. (c) ZAPLOAD FIDO_FID.EXE F FOO.HEX . ZAPLOAD is a program that generates Intel HEX format. (ASCII representation of a file.) It should be IO bound, but is not due to poor programming. (What can I say?) (d) SCAVENGE A: SCAVENGE reads all blocks of a disk and maps out bad sectors. My A: is a 10 meg hard disk, an extremely fast one. This is definitely IO bound, with very optimal drivers. This is a "control" test, and should not vary, since the speed of executions is limited by the disk not the processor. (e) Assemble the Multibuss BIOS. The BIOS of my Multibuss box is about 20 .ASM source files. MASM.EXE is very definitely compute bound. (Which by the way is the worst assembler anyone will ever see. It should be IO bound!) I performed these five tests first with the 8086 installed, then after replacing the 8086 with the V30. No other changes were made. Timing was done by a special program that keeps a millisecond counter that I use for general benchmarking, and is highly accurate and repeatable. here are the results: TEST 8086 V30 Change (a) Compile Fido BBS 43:10 40:53 5.5% (b) Listgen 04:23 04:08 6.0% (c) Zapload 08:36 08:42 -1.1% (d) Scavenge 04:14 04:14 0% (e) Assemble BIOS 05:23 05:07 5.2% The results are pretty clear, and are verifiable. FIDONEWS -- 07 Oct 85 03:03:05 Page 15 SCAVENGE is SCAV23X.COM, LISTGEN is John Warren's program, ZAPLOAD should be out there somewhere, Lattice and MASM you can find. I cannot account for the ZAPLOAD test. It should not have slowed down. It may be an anomaly. Anyone who uses MASM knows that it is terribly slow, and for some unknown reason compute bound. (An assembler?!) It is written in Microsoft Pascal, so I guess that's it. An 8087 will NOT speed up when using the V30/V20 series. It runs at its own clock rate. ------------------------------------------------------------ FIDONEWS -- 07 Oct 85 03:03:05 Page 16 Robert Lederman Met-Chem Fido 16/42 NEW FIDO SYSOP UTILITIES FOR YOU ---=----=-----=---------=---=--- I have written two pretty slick Fido SYSOP utilities that can save you an enormous amount of time in maintaining your system. Come and get 'em! SHUFFLE redirects files and their corresponding FILES.BBS entries among download directories. SHUFFLE also permits rudimentary editing of file entries a la EDLIN, and will incorporate "orphan" files into FILES.BBS. I think SHUFFLE is far superior to similar programs available elsewhere. READQUES reads ANSWERS.BBS (or ANEWUSER.BBS if the bug in Fido 11 is ever fixed), displays the caller's statistics from USER.BBS along with the questionnaire responses, and prompts the sysop to upgrade the caller's access or mark that record for deletion. Admitting new users to semi- private systems is now a breeze. Both programs can be used either locally using ANSI.SYS or remotely using ANSI/VT100/VT52 emulation. This is key for people like me who live far away from the Fidos they maintain. You can get SHUFFLE (v1.3) and READQUES (v1.1) by calling the Met-Chem BBS at 203/281-7287 (2400/1200 baud). Robert Lederman sysop, 16/42 FIDONEWS -- 07 Oct 85 03:03:07 Page 17 ============================================================ COLUMNS ============================================================ A long time ago... on a node far, far away (from PDPvax) XXXXX XXXXXX XXXX X X X X X X X XXXXX X X X X X X X X X X XXXXX XXXXXX XXXX X X XX XXXXX XXXX X X X X X X X X X X X X X XXXX X XX X XXXXXX XXXXX X XX XX X X X X X X X X X X X X XXXX The even further adventures of Luke Vaxhacker Episode n+2 The Milliamp Falcon hurtles on thru system space... Con Solo finished checking the various control and status registers, finally convinced himself that they had lost the Bus Signals as they passed the terminator. As he returned from the I/O page, he smelled smoke. Solo wasn't concerned--the Bookie always got a little hot under the collar when he was losing at chess. In fact, RS232 had just executed a particularly clever MOV that had blocked the Bookie's data paths. The Bookie, who had been setting the odds on the game, was caught holding all the cards. A little strange for a chess game... Across the room, Luke was too busy practicing bit-slice technique to notice the commotion. "On a word boundary, Luke," said PDP-1. "Don't just hack at it. Remember, the Bytesaber is the weapon of the Red-eye Night. It is used to trim offensive lines of code. Excess handwaving won't get you anywhere. Listen for the Carrier." Luke turned back to the drone, which was humming quietly in the air next to him. This time Luke's actions complemented the drone's attacks perfectly. Con Solo, being an unimaginative hacker, was not impressed. "Forget this bit-slicing stuff. Give me a good PROM blaster any day." "~~j~~hhji~~," Said Kenobie, with no clear inflection. He fell silent for a moment, and reasserted his control. "What happened?" asked Luke "Strange," said PDP-1. "I felt a momentary glitch in the FIDONEWS -- 07 Oct 85 03:03:09 Page 18 carrier. It's equalized now." "We're coming up on user space," called Solo from the CSR. As they cruised safely thru stack frames, they emerged in the new context only to be bombarded by freeblocks." "What the..." gasped Solo. The screen showed clearly: /usr/alderaan: not found "It's the right inode, but it's been cleared! Twoie, where's the nearest file?" "3 to 5 there's one..." The Bookie started to say, but was interrupted by a bright flash off to the left. "Imperial TTY fighters!" Shouted Solo. "A whole DZ of them! Where are they coming from?" "Can't be far from the host system," said Kenobie. "They all have direct EIA connections." As Solo began to give chase, the ship lurched suddenly. Luke noticed the link count was at 3 and climbing rapidly. "This is no regular file," murmered Kenobie. "Look at the ODS directory structure ahead! They seem to have in a tractor beam." "There's no way we'll unlink in time," Said Solo. "We're going in..." TO BE CONTINUED??? FIDONEWS -- 07 Oct 85 03:03:10 Page 19 ============================================================ NOTICES ============================================================ The Interrupt Stack 27 Oct 1985 2 AM - Change from Daylight Savings Time to Standard time. You should change your system clock before mail hour this date. 27 Nov 1985 Halley's Comet passes closest to Earth before perihelion. 24 Jan 1986 Voyager 2 passes Uranus. 9 Feb 1986 Halley's Comet reaches perihelion. 11 Apr 1986 Halley's Comet reaches perigee. 19 May 1986 Steve Lemke's next birthday. 24 Aug 1989 Voyager 2 passes Neptune. If you have something which you would like to see on this calendar, please send a message to Fido 107/7.