Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Path: utzoo!mnetor!uunet!husc6!hao!ames!ucbcad!ucbvax!UOFMCC.BITNET!Postman From: Postman@UOFMCC.BITNET Newsgroups: comp.sys.atari.st Subject: Undelivered mail Message-ID: <8711140759.AA17053@ucbvax.Berkeley.EDU> Date: Sat, 14-Nov-87 02:02:00 EST Article-I.D.: ucbvax.8711140759.AA17053 Posted: Sat Nov 14 02:02:00 1987 Date-Received: Sun, 15-Nov-87 16:34:36 EST Sender: daemon@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 438 Your mail was not delivered to some or all of its intended recipients for the following reason(s): 5001 mailbox invalid -> CHARLTO@UOFMCC.BITNET ---------------------------------------------------------------------- Date: Sat, 14 Nov 87 01:02 CST To: CHARLTO@UOFMCC.BITNET From: Info-Atari16 Digest Subject: Info-Atari16 Digest V87 #412 Received: by CANADA01 (Mailer X1.24) id 5738; Fri, 13 Nov 87 22:09:35 EDT Date: Thu 12 Nov 87 12:30:49 PST Reply-To: Info-Atari16@Score.Stanford.edu Sender: INFO-ATARI16 Discussion From: Info-Atari16 Digest Subject: Info-Atari16 Digest V87 #412 To: Name Unknown , Jim Charlton , MIKE CHARLTON , Werner Ens , Name Unknown Info-Atari16 Digest Thursday, November 12, 1987 Volume 87 : Issue 412 This weeks Editor: Bill Westfield Today's Topics: Double-Click Software re: why doesn't Freeterm 2.0 work with Magic Sac Re: new user asking for help.......? Lies (was: Re: Atari/Perihelion Transputer Machine Spec) Re: midi to rs232? PD Smalltalk on AMIGA/ATARI-ST Problems with new Midi ACIA Transmit Interrupts.... Re: Zmodem. (no <> in P.Partner fonts, GULAM) Re: high density 3.5" disks Re: high density 3.5" disks Re: Mega STs C++ on th ST Re: External Keyboard Worst product name award ---------------------------------------------------------------------- Date: Tue, 10 Nov 87 21:41:01 EST From: Flash%UMass.BITNET@forsythe.stanford.edu Subject: Double-Click Software To: Info-Atari16@score.stanford.edu Hello, I recently received the COLOR version of the Double-Click Software Formatter, version 2.21. Is it possible for someone to send me the MONO versions of this? What other software is available from these guys? I used to have the Double-Click Corner Clock, but alas, it doesn't work with the new roms, so I got rid of it. Any other stuff I should be aware of? Rick Flashman 1040 N. Pleasant Street, #381, Amherst, MA 01002. (413) 549-0173 Flash@UMASS.BITNET -or- Flash%UMASS.BITNET@WISCVM.WISC.EDU R-FLASHMAN on GEnie ------------------------------ Date: Wed, 11 Nov 87 07:56 PDT From: Subject: re: why doesn't Freeterm 2.0 work with Magic Sac To: Info-Atari16@score.stanford.edu X-Original-To: Info-Atari16@Score.Stanford.EDU, CS47011 I don't claim to be an expert on the Sac, though I am pretty familiar with Macs in general. I imagine that Freeterm 2.0 isn't working because it has been upgraded to work better with the Mac Plus's 128K ROMs. If routines from the new ROMs are being called, it just ain't going to work with the Sacs older 64K ROMs. Best advice would be to continue to use Freeterm 1.8. Failing that, buy a Mac! Kelly M Hall CS47011 @ IDCSVAX . BITNET 1> Never go first. 2> Never go last. 3> Never volunteer for anything. ------------------------------ Date: 10 Nov 87 16:45:44 GMT From: dalcs!water!ljdickey@uunet.uu.net (Lee Dickey) Subject: Re: new user asking for help.......? To: info-atari16@score.stanford.edu In article <5417@jhunix.UUCP> ins_ajcn@jhunix.UUCP (Julio Cesar Navas) writes: > > Hey folks! I'm very much new to all of this ... > 1. UUDECODE - I take it from my perusals of the network that UUDECODE is way > different from ARC - but how different? ARC is several things at once... It can combine several files into one file, gives you a check sum, and, unless you force otherwise, will compress them according one or another data compression method. UUENCODE, is a program that takes as input any file (such as a ".TOS" file or an ARC file, for instance) and produces another that contains only printable characters. UUDECODE is the inverse of UUENCODE. If I understand correctly, the use of XMODEM requires use of all 256 8-bit characters to do a transfer. This may be OK if you are calling from your computer to another via one direct phone link, as well as in some other circumstances. However, some networks, for their own purposes, respond to control characters, and for that reason, folks have settled on schemes that move only printable characters. (Hence UUen- and UUde-code.) Even this has caused some problems because *some* machines that come in BLUE boxes and use EBCDIC codes are a bit out of sync with these that use ASCII codes. > 2. UNITERM - I've seen this mentioned a few times. > From what I see it seems to be pretty good. Does it have KERMIT? Yes it is great, and yes, it has KERMIT. All our mainframes here run KERMIT, even those that come in BLUE boxes. -- L. J. Dickey, Faculty of Mathematics, University of Waterloo. ljdickey@watmath.UUCP UUCP: ...!uunet!watmath!ljdickey ljdickey%water@waterloo.edu ljdickey@watdcs.BITNET ljdickey%water%waterloo.csnet@csnet-relay.ARPA ------------------------------ Date: 11 Nov 87 01:27:03 GMT From: pollux.usc.edu!papa@OBERON.USC.EDU (Marco Papa) Subject: Lies (was: Re: Atari/Perihelion Transputer Machine Spec) To: info-atari16@score.stanford.edu > Permission to reprint or excerpt is granted only if the following line >appears at the top of the article: Sorry, but this is plain advertising. NO WAY I'll quote the real thing. It should have been: Jack TRAMIEL, COPYRIGHT 1987. REPRINTED BY PERMISSION >workstations. A single transputer can deliver over ten times the power of >an IBM PC AT. However, there's even greater strength in numbers. You can >connect two, 10, 100 or even MORE transputers to create a relatively >low-cost computer workstation with the power of a supercomputer. False. The "standard" number of Transputers on the ABAQ system is 1 (ONE). The maximum is 13. >No firm delivery >date is set, but late 1988 seems to be the most talked-about time frame. >From a first-hand view, the crisp, vibrant graphics (such as four separate >pictures running simultaneously) were drawing crushing crowds. Not Really. I dropped in twice at the ATARI booth and the smallest crowds were at the ABAQ setup. Both times I was able to talk with Tim King, since NOBODY else was around. -- Marco ------------------------------ Date: 11 Nov 87 00:24:01 GMT From: imagen!atari!jwt@ucbvax.Berkeley.EDU (Jim Tittsler) Subject: Re: midi to rs232? To: info-atari16@score.stanford.edu In article <8711100411.AA12628@ucbvax.Berkeley.EDU>, AIPS@BRANDEIS.BITNET (Greg Lindahl [chimps@brandeis.bitnet]) writes: > > if the MIDI port is run by some sort of ACIA and is actually some fancy > sort of rs232 port, could it possibly be reprogrammed a bit to be a > "normal" rs232? > The MIDI port and the ikbd line are each provided by (Motorola) 6850 ACIAs. They are being clocked with a 500 kHz signal. The MIDI port uses the divide-by-16 mode of the 6850 to produce 31.25 kbaud, and the ikbd port uses divide-by-64 to produce 7812.5 baud. The things that make your suggestion a tad messy: 1. The baud rate divisors provided by the 6850 have no finer granularity than /16 and /64. This precludes getting "standard" baud rates. (Unofficial hint: If you were willing to hack up your hardware, you could separate the MIDI 6850's TxClock and RxClock lines from the 500 kHz signal and provide them with your own baud rate clock. If you were willing to live with the restriction that the "MIDI" port would always have the same baud rate as the MFP serial port, you could probably get away with stealing the clock from the MFP's timer D output which is used as the MFP baud rate generator.) 2. There are no modem control lines available on the MIDI output connectors. 3. You will have to convert the MIDI current loop to RS-232C (or whatever your terminal expects). Jim Tittsler {ames, imagen, pyramid}!atari!jwt ------------------------------ Date: 9 Nov 87 13:53:54 GMT From: clyde!watmath!utgpu!bnr-vpa!mike@rutgers.edu (Mike Norman) Subject: PD Smalltalk on AMIGA/ATARI-ST To: info-atari16@score.stanford.edu I'm interesting in finding out if a public domain Smalltalk (source preferred, of course!) exists for either the Amiga or the ST? Thanks in advance, ------------------------------ Date: 11 Nov 87 00:54:54 GMT From: clyde!watmath!utgpu!utcsri!lansd@rutgers.edu (Robert Lansdale) Subject: Problems with new Midi ACIA Transmit Interrupts.... To: info-atari16@score.stanford.edu I have just recently finished writing new Midi Transmit and Receive interrupt drivers for the ST. Testing revealed a problem with the Transmit side. The test routine would fill up the transmit Midi buffer with 128 Midi notes (3 x 128 bytes), and would program the Midi ACIA to start interrupting if there were no data in the buffer previously to the new data being added. While the buffer was being filled, the ACIA would start interrupting and buffering the Transmit buffer out to the Midi port. This is what should happen. What actually happens is that the Midi ACIA Tx interrupts just stop coming in, even though there is data in the TX buffer. After spending about a week looking into this problem I realized that this random behaviour was due (I think) to other interrupts coming in - in particular the 200 hz system timer and mouse/keyboard interrupts. It seems to me that these other interrupts, which are also handled by the MFP chip, are causing the MFP to drop the Midi ACIA's Tx interrupt request, so my software never sees it. How do I get around this problem? I solved it, in a crude way, by enabling the Tx interrupts EVERY time I write a byte into the TX buffer, but this slows the program down from 26ms (only enable them when 1st byte is written) to 156ms. The cause of the slow down is my program going into supervisor mode on each call to enable the ACIA Tx interrupts. So either I fix this problem or resort to non-buffered Midi output. I am open to the wildest suggestions! ------------------------------ Date: 9 Nov 87 13:45:06 GMT From: clyde!watmath!utgpu!utcsri!juancho@rutgers.edu (John Buchanan) Subject: Re: Zmodem. (no <> in P.Partner fonts, GULAM) To: info-atari16@score.stanford.edu In article <801@sbcs.sunysb.edu> lean@sbcs (Lean L. Loh) writes: > Latest (and greatest) version of GULAM is out. I believe Jim Turner Post it. !Post it. !Post it. !Post it. !Post it. !Post it. !Post it. ! John W. Buchanan Dynamic Graphics Project Computer Systems Research Institute (416) 978-6619 University of Toronto juancho@toronto.CSNET {allegra,cornell,decvax,ihnp4,linus,utzoo}!utdgp!juancho -- John W. Buchanan Dynamic Graphics Project Computer Systems Research Institute (416) 978-6619 University of Toronto juancho@toronto.CSNET {allegra,cornell,decvax,ihnp4,linus,utzoo}!utdgp!juancho ------------------------------ Date: 10 Nov 87 22:28:17 GMT From: unisoft!hoptoad!dasys1!schuster@ucbvax.Berkeley.EDU (Michael Schuster) Subject: Re: high density 3.5" disks To: info-atari16@score.stanford.edu In article <2923@hcr.UUCP> miken@hcr.UUCP writes: > >Does anybody out there in netland know anything about these little wonders, >aforementioned hardware, and most importantly, how I can make my ST >use these disks? These diskettes write 80 tracks x 18 sectors/track. They require a special drive mechanism whose write bias is adjusted by a special pin on the cardedge. Similar to the way AT clones enable the 1.2MB 5.25" drives. A friend and I recently tried an external high density drive (made by NEC) designed for AT clones. It could read 720K diskettes but little else. It could not read 1.4 MB PS/2 diskettes at all. Probably the controller is incapable of recognizing this format - DiskMech said the tracks were blank. Perhaps these beasties could be run through a hard disk controller, like Supra's 10MB floppies. If not - I fear it may be hopeless. -- l\ /l' _ Mike Schuster {sun!hoptoad,cmcl2!phri}!dasys1!schuster l \/ lll/(_ Big Electric Cat schuster@dasys1.UUCP l lll\(_ New York, NY USA DELPHI,GEnie:MSCHUSTER CIS:70346,1745 ------------------------------ Date: 10 Nov 87 22:15:27 GMT From: tektronix!sequent!mntgfx!dclemans@ucbvax.Berkeley.EDU (Dave Clemans) Subject: Re: high density 3.5" disks To: info-atari16@score.stanford.edu The difference between the current ST floppies and the 2 megabyte ones is similar to the difference between the floppies on an IBM PC-XT and a IBM PC-AT. Basically the clock rate is doubled, letting you pack in twice as much information. The consensus among the hardware people I've talked to is that the WD 1772 that's currently in the ST can't handle a higher clock rate. However if you removed the 1772 from the motherboard and replaced it with a daughter board with appropriate clocks, controllers, etc. you could get the hardware set up correctly. The software incompatibilities you'd see would include: the desktop disk formatter and copier probably wouldn't work (but there are public domain versions of both of these available) nothing knows about "switching" densities; i.e. you'd have to invent some way to dynamically change clock rates dgc ------------------------------ Date: 10 Nov 87 21:54:50 GMT From: tektronix!sequent!mntgfx!dclemans@ucbvax.Berkeley.EDU (Dave Clemans) Subject: Re: Mega STs To: info-atari16@score.stanford.edu There are two major causes of incompatibility with the blitter rom's (as used in the Mega ST's) Essentially all of the "undocumented" low memory locations have moved. A MAJOR bug in the read portion of the floppy driver was fixed. This bug had two symptoms that people might have encountered: error status might not be correctly reported after a read that got an I/O error If running a program that used BIOS calls to directly access the floppy (for performance), multi-sector reads were not reliable (assuming that the BIOS listing ATARI sent me as part of the developers kit accurately represented the old ROM's, the bug was caused by mis-using a WD-1772 sector read command). From what I've heard, the floppy read bug fix is what has caused most compatibility problems; it seems some manufacturers of copy protected software (mainly games) based their copy protection on a side-effect of the bug. Based on my experience the other areas aren't as major; the only packages I know of that were affected were the "twister" formatter that came from STart and possibly GFA basic. ============= How much memory you want depends on what you do now, and what you might want in the future. My system (4 megabytes) normally runs with slightly under 2 megabytes free. The rest is taken by a 800K ram disk, a LARGE disk sector cache, a large printer buffer, auto-loaded programs, desk accessories, etc. The whole conglomeration boots in under 30 seconds, including the time to load about 400K of files into the ramdisk. There are also software packages that want memory; the laser printer driver, Smalltalk-80, OS-9, IDRIS, etc. dgc ------------------------------ Date: 10 Nov 87 16:04:28 GMT From: ihnp4!homxb!homxc!jdn@ucbvax.Berkeley.EDU (J.NAGY) Subject: C++ on th ST To: info-atari16@score.stanford.edu Does anyone know of a C++ compiler for the Atari ST computers? Jonathan Nagy {ihnp4|allegra|harvard}!homxc!jdn (201) 615-4349 ------------------------------ Date: 10 Nov 87 22:22:00 GMT From: cca!mirror!datacube!ftw@husc6.harvard.edu Subject: Re: External Keyboard To: info-atari16@score.stanford.edu Your comments prompted me to look at the bottom of the LK-201 keyboard I'm typing on right now. Indeed, it does have a warning about using only "approved" cables for keyboard attachment, otherwise, "excessive overheating may result in abnormal conditions.". Thanks for pointing that out. I can picture a really cheap cable catching fire if the +5 to the keybaord gets shorted for some weird reason. As for number of wires, I'm glad I said _maybe_, since I don't have a 520 to take apart, old or new. ;-) Farrell T. Woods Datacube Inc. Systems / Software Group 4 Dearborn Rd. Peabody, Ma 01960 VOICE: 617-535-6644; FAX: (617) 535-5643; TWX: (710) 347-0125 INTERNET: ftw@datacube.COM UUCP: {rutgers, ihnp4, mirror}!datacube!ftw ------------------------------ Date: 11 Nov 87 01:09:41 GMT From: spdcc!m2c!applix!scott@husc6.harvard.edu (Scott Evernden) Subject: Worst product name award To: info-atari16@score.stanford.edu Moses PromiseLAN ? ??? ------------------------------ End of Info-Atari16 Digest ************************** -------