Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Path: utzoo!mnetor!uunet!seismo!husc6!think!ames!ucbcad!ucbvax!FINGATE.BITNET!MAILER-DAEMON From: MAILER-DAEMON@FINGATE.BITNET (Mail Delivery Subsystem) Newsgroups: comp.sys.atari.st Subject: Returned mail: Unable to deliver mail Message-ID: <8707150247.AA15549@ucbvax.Berkeley.EDU> Date: Tue, 14-Jul-87 22:48:57 EDT Article-I.D.: ucbvax.8707150247.AA15549 Posted: Tue Jul 14 22:48:57 1987 Date-Received: Fri, 17-Jul-87 01:53:24 EDT Sender: daemon@ucbvax.BERKELEY.EDU Distribution: world Organization: The ARPA Internet Lines: 546 ----- Transcript of session follows ----- 554... Unknown fudec host name : sampo ----- Unsent message follows ----- Received: by santra.UUCP (5.51/6.4.TeKoLa) id AA06376; Tue, 14 Jul 87 15:24:59 +0300 From: Message-Id: <8707141224.AA06376@santra.UUCP> Received: by fingate Tue Jul 14 15:24:55 from MAILER@FINHUTC.BITNET via rscs BSMTP. Received: by FINHUTC (Mailer X1.24) id 4104; Tue, 14 Jul 87 05:03:56 FIN Date: Sat 11 Jul 87 23:14:37 PDT Reply-To: Info-Atari16@Score.Stanford.edu Sender: "Atari ST users forum (INFO-ATARI16)" Original-From: Info-Atari16 Digest Subject: Info-Atari16 Digest V87 #272 To: , Original-To: , Info-Atari16 Digest Saturday, July 11, 1987 Volume 87 : Issue 272 This weeks Editor: Bill Westfield Today's Topics: Query on Magic Sac status... MODULARS232 (long) - easy serial communications cabling IBM emulator Re: NL-10 Printer loses characters at End-of-Page Re: Computer Aided Voicing (Product Announcement) Supra 20Meg HD Quirks Re: Disk R/W times for large files ---------------------------------------------------------------------- Posted-From: The MITRE Corp., Bedford, MA To: info-atari16@score.stanford.edu Subject: Query on Magic Sac status... Date: Mon, 06 Jul 87 14:49:43 EDT From: jhs@mitre-bedford.ARPA A friend of mine is very interested in the possibility of buying an Atari ST and Magic Sac as an alternative to buying a Mac. Can anybody give me a current status report on: (a) Software that will and will not run with Magic Sac; and (b) Estimated price and availability date for the rumored Data Pacific Macintosh-compatible floppy drive for the ST? Is there any other source for an ST drive that can read/write Mac disks? Any other information on advantages or disadvantages of an ST with Magic Sac would be appreciated. -John Sangster / jhs@mitre-bedford.arpa ------------------------------ Date: 6 Jul 87 18:33:22 GMT From: braner@tcgould.tn.cornell.edu (braner) Subject: MODULARS232 (long) - easy serial communications cabling To: info-atari16@score.stanford.edu [This is not specific to comp.sys.atari.st. If you know the most appropriate group please tell me.] My friend Richard Furnas has devised a wonderful solution to the age-old DCE/DTE dichotomy. Devices set up to fit his standard are all the same, and any two can talk to each other with the same cable. And his method uses compact, positive-locking but easy to (dis)connect, inexpensive, widely available connectors and cables. I am posting this for him since he has no access to Usenet. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Handy Dandy Serial Connections with Modular Connectors ------------------------------------------------------ By Richard Furnas For some time now I have been evolving a system for connecting RS232 serial devices using modular connectors. The arrangement I am reporting here is the result of much thought and experimentation. I have been delighted with the elegance of the modular connectors ever since they appeared and hope this adaptation of them does justice to the elegance of the design of the connectors themselves. Rationale for the setup: ======================== When I first looked closely at modular connectors and the way that telephone extension cords are wired, I thought it was all very sad. While the connectors are polarized (can only plug in one way), the usual extension cord flips things over seemingly ignoring the polarization in the plugs! I knew the phone people spoke of RING and TIP but from my experience with playing with installing my own phone lines in my house, it never seemed to matter which way things were hooked up, they always worked anyway (Diodes no doubt). It wasn't until I started to think about the RS232 application that I realized the simple elegance of the modular adapters and plugs: All devices are the same, and the cables do the swapping so RING and TIP retain their identity. While the RED and GREEN lines in the building may remain true to which is which (they are installed by professionals who know their colors and maybe even carry voltmeters), the cables are 'smart' enough not to care. The minimal Serial connection requires 3 wires, Ground, data in and data out of each device. This is a symmetric situation: ______ ______ | |====Data===>| | |device|===Ground===|device| | |<===Data====| | ------ ------ At first I knew that 95% of the direct connections I wanted to make would be 3-wire connections and so wanted to set things up to be able to use ordinary phone cabling. But which lines to use and how? I took a tip (TIP?) from the phone setup: Make all devices the same and let the cables do the thinking. If we are to use telephone-style connectors, it is important to protect the computer devices from the higher voltage of the phone line in case the cable is plugged into a phone outlet by mistake. Most simple telephone lines have 4 wires and only the center two have the higher voltage of the phone line. The outer two are either totally unused or have a lower voltage for lighting your princess phone. Therefore I short the center two lines together and use them for the signal ground. This solves two problems. If the connector gets plugged into the typical phone outlet, it merely "takes the phone off the hook" and does no damage to the computer device. It also makes the cable symmetrical. The outer two lines can be used for the data lines. If two devices are configured identically at their respective connectors, an ordinary telephone-to-wall cable will serve as the 'null modem' cable for a three wire connection between the devices. But there is more to serial data transfer than just three wire connections. Many serial printers prefer a hardware handshake. This requires another wire and hardware handshake can naturally be symmetrical as well. Talking to a printer is usually a one-way affair but two computers may want to talk that way on occasion as well. (Ever want to capture EXACTLY the output intended for a printer and put it in a file?) The standard modular line cord (NOT handset cord) uses a 6-position connector with only the middle four of the positions actually occupied by wires. This is called "6-4". "6-6" versions of the connectors along with the 6-conductor cable are harder to come by but can be had from several of the parts vendors that advertise in the back of BYTE or Computer Shopper. This extra pair of wires preserves the symmetry of the connection and means that once again the business of swapping lines can be done by a uniform, standard cable. The 6-6 setup may not provide adequate handshaking for use with some modems and modem programs since they actually use the additional handshake lines to determine the progress of the call. MODULARS232 Specifications ========================== Imagine (if necessary) that you are sitting at a desk, and you have a standard modular desk telephone on the desk. Rotate it 180 degrees so that you see the connector on its back. Unplug the cable. Look into the socket. It will most likely have the wires on the top and the notch for the locking clip on the bottom. (If it doesn't, turn it upside down.) Now imagine that this phone is actually a computer (or printer or graphics tablet or...). If it conforms to the "MODULARS232" standard, the wires, as you're looking at them, are wired as follows (the mnemonics are introduced here): A T G G R Q __+_+_+_+_+_+__ (Acknowledge) handshake signal coming out | | | | | | | | (Transmit) data coming out of this box | | Ground | | Ground | | (Receive) data going into this box | | (Query) handshake signal going into this box ----- ----- | | (looking into the socket from outside the box) --- If, when this socket is vacant, you can measure live voltage (12V) between the ground wires and the R or Q wires then you got it reversed: "coming out" means the box applying voltage to the outside world, "going in" means sensing the voltage that is arriving. For the time being we have to live with existing equipment, so the MODULARS232 set-up has to be achieved by making "adaptors". I have set up this system for communications between arbitrary pairs of the following devices, using the pin assignments given below. The lists are the numbers of the pins (in the conventional connectors mentioned) that should be wired to the A,T,G,G,R,Q wires respectively inside a modular socket to make the correct adaptor. Basically DTE Devices: ====================== IBM PC-XT Clones (DB25P Connector on Chassis) 20,2,7,7,3,5; Jumper: 4-6-8 on DB25S (Note 1) IBM PC-AT Clones (DB9P Connector on Chassis) 4,3,5,5,2,8; Jumper: 1-6-7 on DB9S (Note 1) TRS-Model 102 (DB25S Connector on Chassis) 20,2,7,7,3,5; Jumper: 4-6-8 on DB25P (Note 1) HP-IL to Serial Convertor (DTE Setting, DB25P on Chassis) 20,2,7,7,3,5; Jumper: 4-6-8 on DB25S (Note 1) HP Thinkjet (TM) serial printer (DB25S on Chassis) HP 7475 (TM) Serial Plotter (DB25S on Chasis) 20,2,7,7,3,5; Jumper: 4-6-8 on DB25P (Note 1) Basically DCE Devices: ====================== Prometheus Promodem (TM) 1200 (to Eagle w/ MITE and to MAC) 8,3,7,7,2,20 (Notes 2,3) Intectra Serial to Parallel Converter 5,3,7,7,2,20 DTE or DCE? Who cares, here's the connection: ============================================== Eagle (TM) II CP/M Computer 4,3,7,7,2,5; (Note 2) Macintosh with DB9 Socket Mac+ with mini8 to DB9 Socket converter Imagewriter II with mini8 to DB9 Socket converter 6,5,3-8,3-8,9,7; (Note 2) Note 1: ======= For many applications it is not necessary to jumper pins 4-6-8. Especially in direct connect applications which are using software handshaking, the driver software often will ignore the status of the hardware handshake pins anyway. Note 2: ======= Some devices (notably some computers) do not support proper hardware handshake on data input. (Note this is the 'A' line on which the computer could output a signal saying it is full for the moment.) The Eagle II and Macintosh fall in this category. The connections above are compatible with driving printers and all 'three wire' connections and even allow the same connectors to be used to the Prometheus modem. (The MAC just has the +12V line connected signalling the MAC is as ready as it will ever be.) Note 3: ======= The best way to drive an honest to gosh modem if you have a device which supports the modem handshake lines properly (e.g. a PC clone), is with a cable with more wires in it than this modular setup. Practical hints =============== In practice what I have done is wire a cable for each of my desktop machines which has the DB-whatever connector on one end and a modular PLUG on the other. (If I need to connect something I'm going to need some length of cable as well so might as well build it into the adaptor.) Then I just need a double female modular connector to establish the connection. On highly portable devices, I have the DB- whatever and a modular socket. Actually I have cut holes in them and installed the socket in the chassis without any jumpering (so the port can still be fully functional). The modular plug on any of the desktop machines now goes to the socket I have built in my Model 102 for example. To summarize pictorially looking into the socket: _Handshake_ ... Hardware handshake support with 6-6 | _DATA__ | ... 3-wire connection with ordinary 6-4 | | GND | | ... take phone off hook-won't fry device | | | | | | A T G-G R Q ... Our new mnemonics R T G-G R C } T X N-N X T } ... RS232 (DTE) Signal names (sort of) S D D-D D S } | | | | | | out in ... this side accepts input signals out in ... the other side puts out signals | | ^ ^ v v | | ___ - Just a reminder: /_ Standard flat cable _\ d__=============/ /=============__b And for troubleshooting, if your connection does not work, you will find this cable useful: /_ Inverting cable d__=====================---p --/ I have a 3 inch cable like this I use for troubleshooting (with a double-female on one end). With a 3-wire (6-4 modular) connection this will serve to swap the data transmit and receive lines just in case you got them backwards. Recommendation: If that solves the problem, FIX YOUR CONNECTORS. Otherwise you'll be haunted by the incompatible setup until you do. I suggest using crimp pin DBxxx connectors so that the pins can be easily moved if you get something backwards. Richard E. Furnas Microcomputer Power 111 Clover Lane Ithaca, NY 14850 (607) 272-2188 CompuServe ID 76556,3444 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ - Moshe Braner ------------------------------ Date: 2 Jul 87 16:23:00 GMT From: pyramid!prls!philabs!hhb!rob@decwrl.dec.com (Robert R Stegmann) Subject: IBM emulator To: info-atari16@score.stanford.edu [] Hi all, I just read in the August issue of Compute! magazine about an IBM PC emulator (in software) for the ST. It is called "pc-ditto" from Avant-Garde Systems, 381 Pablo Point Dr., Jacksonville, FL 32225. (The brief article is on page 118, in the News & Products column.) The article says the program costs $89.95, isn't copy protected, supports 3.5"/80-track or 5.25"/40-track formats, monochrome or color, and runs (quote) "virtually all of the major IBM programs, such as Lotus 1-2-3, Multiplan, Symphony, Flight Simulator, Dollars&Sense, Sidekick, DAC Easy Accounting, Turbo Pascal, and many others." Can anybody out there who has any experience with this product or company comment? Does this emulator run at speed, or is it slow? Is it real or vapor-ware? It sounds interesting enough to buy, but life can be full of little disappointments, can't it? I called Florida information and got a phone number for Avant-Garde, which turned out to connect me with some company that refuels Navy jets! I explained to the man who answered the phone that I was trying to reach a software company to ask about their product, but instead of simply telling me he didn't know what I was talking about, he gave me another number! I tried THAT number several times, but it was always busy, so I haven't been able to contact Avant-Garde. I suspect they may be employees of the refilling company who are moonlighting. P.S. What about the "MS.EM" package from Paradox? I heard it was poorly done. Does anybody know if it has been improved? [Please note that I am in no way affiliated with any of the above-mentioned organizations, neither do I endorse any of the above-mentioned products.] rob Robert Stegmann {allegra,ihnp4,decvax}!philabs!hhb!rob I in no way represent my employer in this matter. ------------------------------ From: David MadenTo: Digest Subject: Re: NL-10 Printer loses characters at End-of-Page Return-Receipt-To: David Maden A couple of weeks ago, I wrote ... > I have a Star NL-10 printer connected to my 1040STf via the printer port. The > plug-in unit on the Star-10 is a so-called Parallel Interface-Steckmodul. My > problem is that, when I manually feed in single sheets of paper to the printe > to get a print-out of a file from the desk-top (i.e. double-click the file an > then select the "print file" option), I lose characters (the number that get > lost appears random but is usually about 16) when changing sheets of paper. > Etc .... Thanks to help from Holger Brieger in Berlin, I have been able to fix the fault. The problem is the Version of the EPROM in the NL10 Plug-in Cartridge. You can see the version number by invoking the printer's self-test feature. Mine was P1.4 and is now P1.5 and works much better. On changing sheets of paper, though, I now have to press the on-line button as well which was not the case before (but I guess this could be a feature rather than a bug since you then have a chance to check that the paper is straight!!). Since I have seen this same fault on many printers in the shops in this part of Switzerland, there may be other Atari users out there in need of the same upgrade. David Maden, maden@czheth5a.bitnet Swiss Institute for Nuclear Research, CH-5234 Villigen ------------------------------ Date: 7 Jul 87 06:39:00 GMT From: well!csz@lll-lcc.arpa (Carter Scholz) Subject: Re: Computer Aided Voicing (Product Announcement) To: info-atari16@score.stanford.edu > Message-ID: <784@sask.UUCP> > Date: 2 Jul 87 20:53:34 GMT > Organization: University of Saskatchewan, Canada > Product Announcement July 2, 1987 > Synchro-Systems presents DXMATE, an integrated Computer Aided I thought Usenet policy forbade for-profit commercial announcements here. ------------------------------ Date: Tue, 7 Jul 87 08:21:26 EDT From: csrobe@icase.arpa (Charles S. Roberson) To: info-atari16@score.stanford.edu Subject: Supra 20Meg HD Quirks I have had a Supra Hard Disk for about 4 months (90 day warranty, of course) and it is starting to make some unusual sounds, and do some disquieting things. The first thing I noticed was that it occassionally 'burped' during the power on sequence. Normally, I would hear a cresendo whir followed by two beeps. Then I noticed an occassional: whirrrrrrrr beep BURP beep beep but everything worked fine. Then the big-time hit, the machine had been on for several hours (4 or 5) and was quite toasty. I had micro-emacs load a file, the disk started to spin up for a read and it never stopped! It got faster and faster. I had to turn the drive off to stop it. By this time my heart was pounding and I was sweating bullets. Well, it started again, it burped again, and everything seemed ok for about 4 mins then it took off again. I let the machine sit idle for a couple of days while I moved. Then I hooked it up again, and it whirred, beeped, BURPED, and beeped some more. EVERY TIME I started it. In comes SUPRA! I called their tech support line and the guy I talked to said that a loose power cord could cause the whir-up problem and that the BURP didn't mean anything as far as diagnostics go. I was skeptical but what could I do? I tested the power cord, started the machine, and started to work. My disk is partitioned into 4 5meg logical disks, with the fifth one a Scratch disk. I decided to run the Supra Hard Disk Utility to "Map out bad sectors" on that logical disk (5). At about 2400 of the 10100 and some sectors the disk did its magical whirr. I reached to check the power cord again, but before my had was half way there the disk drive reset itself and started the power up sequence. (Whirrrrrrrr, beep, BURP, beep beep). The utility said I had a bad sector, GEMDOS said I that the data on the drive may be damaged, and that the drive needed to be connected correctly. I replied to cancel the operation, the GEM diaglog box disappeared but the utility started mapping at the next sector. The mapping completed without another hitch. I am worried and scared to use my machine. I have almost $600 invested in that disk. A *MAJOR* investment on my part, and I don't like the idea of it flaking out after only 4 months! In about a month and a half I am going to start doing research for my Master's Thesis and I can't afford to have my machine freak and my data flung into the bit-bucket. I am also not so pleased with SUPRA's response to my inquries, nor with their documentation. So i leave you with this general plea: # # ###### # ##### # # # # # # # # ###### ##### # # # # # # # # ##### # # # # # # # # ###### ###### # # Chip Roberson csrobe@icase.arpa (ARPANET) $csrobe@wmmvs.bitnet (BITNET) ...seismo!gmu90x!wmcs!csrobe (UUCP) ------------------------------ Date: 7 Jul 87 00:08:43 GMT From: imagen!atari!apratt@ucbvax.Berkeley.EDU (Allan Pratt) Subject: Re: Disk R/W times for large files To: info-atari16@score.stanford.edu in article <383@uop.UUCP>, exodus@uop.UUCP (Greg Onufer) says: > > Anybody care to explain what's wrong here? > > I used GULAM's timing function to time misc. file copies onto several > formats of disk. The tables should explain: > Big files will copy fast only if big reads and writes are used. If your copy program reads one sector, writes it to the floppy, then reads another sector, you'll lose. The shell we shipped with the developer's kit a while ago, called COMMAND.PRG, used a 1000 (not 1K) byte buffer. This is a real problem. Big reads are optimized to read a whole track at a time (for instance). When this is the case, sector skewing will LOSE, because it takes multiple revolutions to read the whole track. For operations like file copy, the lesson is to use as big a buffer as you can. Don't create a static 8192-byte array: instead, determine how much memory you have available and use all of it. Here is a little code in Alcyon C (this depends on the variable _break, set up by gemstart and changed when you use gemlib's malloc). It returns the number of bytes available starting at _break, and that stays valid as long as you do no function calls (especially not to gemlib's malloc()). long freemem() { extern long _break; long dummy; /* &dummy is something near the current sp */ return (&ret - _break - 512); /* 512 is a chicken factor */ } If you have used Mshrink to return memory to the operating system (which is the case if you set the STACK variable in gemstart.s to 0, 1, 2, or 3), you may have more memory than this available using Malloc (the OS call). Malloc(-1L) returns the largest Malloc request which can be satisfied. If you Malloc this, use it as a disk buffer, then Mfree it, you will not run into trouble. /----------------------------------------------\ | Opinions expressed above do not necessarily | -- Allan Pratt, Atari Corp. | reflect those of Atari Corp. or anyone else. | ...lll-lcc!atari!apratt \----------------------------------------------/ (APRATT on GEnie) ------------------------------ End of Info-Atari16 Digest ************************** -------