Path: utzoo!utgpu!jarvis.csri.toronto.edu!rutgers!tut.cis.ohio-state.edu!ucbvax!DFNGATE.BITNET!RIOVM From: RIOVM@DFNGATE.BITNET Newsgroups: comp.sys.atari.st Subject: (none) Message-ID: <8908050158.AA24423@ucbvax.Berkeley.EDU> Date: 5 Aug 89 01:58:15 GMT Sender: daemon@ucbvax.BERKELEY.EDU Organization: The Internet Lines: 447 X-Unparsable-Date: Sat, 05 Aug 89 03:54 CET Added from the X.400/EARN-Gateway: Undeliverable Mail Notification message, may be wrong recipient Received: from DEARN.BITNET by DFNGATE.BITNET.DBP.DE (Mailer R2.03B) with BSMTP id 7010; Sat, 05 Aug 89 02:46:39 EST Received: by DEARN (Mailer R2.01) id 5098; Sat, 05 Aug 89 02:46:33 EST Date: Fri, 4 Aug 89 15:44:37 PDT Reply-To: Info-Atari16@Score.Stanford.edu Sender: INFO-ATARI16 Discussion Comments: Warning -- original Sender: tag was Info-Atari16-request@SCORE.STANFORD.EDU Comments: Warning -- original Sender: tag was INFO-A16@MARIST From: Info-Atari16 Digest Subject: Info-Atari16 Digest V89 #366 To: Robert Weissenfels Info-Atari16 Digest Friday, August 4, 1989 Volume 89 : Issue 366 This weeks Editor: Bill Westfield Today's Topics: evnt_keybd DVT VCR Hard Drive backup FOR SALE... GNU Tar sources Re: GNU-Emacs 18.51 for Atari ST (TOS) posted to comp.binaries.atari.st 1MB piggyback details - how to [LONG] Re: putchar() getchar() problem? Re: Amiga vs. Atari ST Re: Amiga vs. Atari ST gnuemacs needed (sections 13-18) Re: Mega2 hardware questions... Packed executables ---------------------------------------------------------------------- Date: 27 Jul 89 19:36:19 GMT From: jwd@iuvax.cs.indiana.edu (Jon Dunn) Subject: evnt_keybd To: info-atari16@score.stanford.edu This may be a dumb question, but how to I convert the scan code returned by the AES evnt_keybd() function to an ASCII code? Thanks! Jon Dunn jwd@iuvax.cs.indiana.edu ------------------------------ Date: Thu, 27 Jul 89 17:10:33 EDT From: Brian Holmes Subject: DVT VCR Hard Drive backup To: Atari Newsgroup I received my DVT VCR HD Backup device and software yesterday. I ordered it from Computability as advertised in START for $209.00 Currently the software only supports file backup, no image backup, though the software could easily support it. In START it's advertised is as storing 8 megabits/minute which would be 1 megabyte/minute right? I backedup my 'C' partition which contained c12meg of files and it took 35 minutes, which would average out to 333K/minute right? They also advertised that it stores up to 360 megabytes (per tape I'm assuming). Using a 120 minute tape, I will only be able to store c48Megabytes/tape. They must have been using one big tape. They suggest using SP mode, which is the fastest playing mode (i.e. record 2 hours/tape). For $209 I guess I got my money's worth, I just hope they come out with an image backup utility. Brian Holmes CSC Operating Systems & Communications SNAIL : Wayne State University, 5925 Woodward, Detroit MI 48202 U.S.A. BITNET : BHOLMES@WAYNEST1 INTERNET : Brian_Holmes@UM.CC.UMICH.EDU UUCP : {UMIX|ITIVAX}!WAYNE-MTS!BRIAN_HOLMES ------------------------------ Date: 28 Jul 89 01:00:49 GMT From: brutus.cs.uiuc.edu!wuarchive!swbatl!texbell!uhnix1!uhnix2!uace0@tut.cis.ohio-st ate.edu (Michael B. Vederman) Subject: FOR SALE... To: info-atari16@score.stanford.edu A friend is trying to sell his complete Mega 4 system. Here is what he has: Mega 4 Monochrom monitor Megafile 30 Laser printer Ultrascript + Extended font package Spectre 128 + ROMs Calamus Page Stream Time Works DTP He would like $3600 for everything, and is hoping to get rid of everything by July 31!!! He is willing to break up the set. Please give him a call if interested, day or night. His name is SAM, and his number is 713-493-5160. -- for (;;) : Use ATARINET, send an interactive do_it(c_programmers); : message such as: : Tell UH-INFO at UHUPVM1 ATARINET HELP University Atari Computer Enthusiasts : University of Houston UACE ------------------------------ Date: 27 Jul 89 22:03:25 GMT From: attcan!lsuc!jimomura@uunet.uu.net (Jim Omura) Subject: GNU Tar sources To: info-atari16@score.stanford.edu I was collecting the GNU Tar source set and Part 7 apparently didn't arrive. Could someone contact me by mail if they have it? Thanks. Cheers! -- Jim O. -- Jim Omura, 2A King George's Drive, Toronto, (416) 652-3880 lsuc!jimomura Byte Information eXchange: jimomura ------------------------------ Date: 28 Jul 89 03:26:46 GMT From: att!chinet!saj@ucbvax.Berkeley.EDU (Stephen Jacobs) Subject: Re: GNU-Emacs 18.51 for Atari ST (TOS) posted to comp.binaries.atari.st To: info-atari16@score.stanford.edu I know, we were told not to expect much from GNU EMACS with only 1 Meg, but after determining that it only used about 300 K text+data+bss I gave it a shot. Just start it, read some stuff in and push a few keys, nothing serious. Impressive hardly describes it. Looks just like on the VAX, only it starts up faster. But I have a couple of ???-s. The start-up seems to crash rather than finishing normally (something about invalid argument stringp null, as I remember). Control Z gives a kind of no-op (the bottom line flashes 'program terminated' ever so briefly, then I'm back in EMACS. And dired seems to be getting confused, probably by the $HOME environment variable in \ form (rather than / form) which is really there for the use of the shell, msh, rather than EMACS. But the program runs fast, and there's a tremendous amount there. This is going to be fun to explore. I hope the diffs from a widely available source distribution show up on the net. Steve J. ------------------------------ Date: 27 Jul 89 13:39:44 GMT From: mcvax!ukc!acorn!moncam!emmo@uunet.uu.net (Dave Emmerson) Subject: 1MB piggyback details - how to [LONG] To: info-atari16@score.stanford.edu Aaagh! Is it just my imagination, or does 10% of the mail in this group really consist of requests for details of piggy back expansions? Perhaps if I reply, they might desist? OK peeps, you asked for it.. First off get hold of 16 DRAMs in Dual In Line packages. These look like the ones already fitted along the front right of your ST, if in doubt, quote the section of the device marking which includes the number 256, and ask for an equivalent part. There are far too many to list them all, but basic specs are : 256K x 1 page mode DRAM, 150 nanoseconds or faster, preferably in plastic package (cheaper!), 16 pin DIL outline. They're not cheap, and prices vary enormously, so shop around. Each chip has a notch at one end, to show which way up it is fitted. With the notch uppermost, pin 1 is to the left of the notch, pin 8 is at bottom left, pin 9 bottom right, and pin 16 top right. Armed with this information, find pins 4 and 15 on each of your new chips in turn, and bend them CAREFULLY through 180 degrees without breaking them off. Bend them as close to the body of the chip as you can. These are the RAS and CAS pins which work as chip select lines. The chips will normally be supplied in black anti-static foam. Try to keep them there while you bend the pins. Now, one at a time, sit a new chip on top of one of the built-in DRAMs, with the notch at the same end (!!) and solder each of the other 14 pairs of pins together. Make sure the chips are accurately lined up, use only the minimum of fine multicore solder, and watch out for 'bridges' of solder between adjacent pairs of pins, and solder splashes on the PCB. This takes care of all the address, data, power, and read/write_ lines. Lastly, locate the MMU chip. This is a square, 68 pin device, U15 on early machines, and probably the one nearest the DRAMs on all versions. This has a pip in the middle of one side to indicate pins 1 & 68. From the top of the board, they are numbered anticlockwise. Attach one end of a short (300mm or so) length of thin INSULATED wire to each of pins 18 (RAS1), 21 (CAS1LOW), and 22 (CAS1HIGH). Prototyping wire is ideal, particularly the "solder-wrap" type sold in the UK as "Verowire" (R) for around 5.5 pounds. Don't connect directly to the MMU, take the wires through a suitable hole, and trace the pins to the underside of the PCB. The wire from RAS1 should be soldered to pin 4 of ALL the new DRAMs. If you are skilled enough to do it, a 33 ohm Resistor should be used in series as near to the MMU as possible to dampen reflections on all 3 of these wires, but its omission is unlikely to cause problems. The wire from CAS1LOW should be soldered to pin 15 of the LEFTmost 8 new DRAMs, and that from CAS1HIGH to the RIGHTmost 8. That's it. Depending on your confidence and proficiency, it should take about half to 2 hours. DO try to do it all in one session, and avoid touching the chips as much as possible, they are static sensitive. A use ful tip - DISCONNECT the power supply, and attach a lead from the ground rail around the edge of the board to your metal watch strap. keep the chips in their foam sitting on a bare area of the ground rail. I'ts not a static safe workstation, but it's as near as most of you will get. If you have a hard disk, unhook it before you first try out your handiwork! If it doesn't work : don't blame me! If your ST runs, but still only with 0.5 MB, check for unsoldered pins, suspect duff chip(s). If it goes crazy, check for solder shorts, check correct pins used on MMU, take it to your nearest hardware wiz with a print of these 'destructions'. Finally, piggybacking 1Mbit DRAMs instead of 256K for 2.5Mbytes : This is MESSY, the pinouts don't match up well, and several pins need to be bent through impossible angles. You will need to connect another flying lead for the extra address from MMU pin 64 to A9 on ALL the 1M drams. Again the 33 ohm resistor aught to be included as before. The relevent pinouts follow, I won't go into more detail as I hold the view that if you can't figure it out from here, you shouldn't attempt to do it. A useful hint though, apart (perhaps) from A9 (for refresh considerations), the address pin numbers can be swapped around anyhow you like, ie A0 can be used as A1 etc.. Viewed from above: 256K DRAM pinout 1M DRAM pinout notch notch 1 A8 16 Vss 1 Data in 18 Vss 2 Data in 15 CAS_ 2 Write_ 17 Data out 3 Write_ 14 Data out 3 RAS_ 16 CAS_ 4 RAS_ 13 A6 4 UNUSED 15 A9 5 A0 12 A3 5 A0 14 A8 6 A2 11 A4 6 A1 13 A7 7 A1 10 A5 7 A2 12 A6 8 Vcc 9 A7 8 A3 11 A5 9 Vcc 10 A4 The above is submitted in good faith, but you use it at your own risk. If you spot any mistakes, please post to this group first, flame me later! Dave E. ------------------------------ Date: 27 Jul 89 13:25:13 GMT From: oliveb!pyramid!prls!philabs!ttidca!woodside@apple.com (George Woodside) Subject: Re: putchar() getchar() problem? To: info-atari16@score.stanford.edu In article <2829@tahoe.unr.edu> mikew@wheeler.UUCP (Mike Whitbeck) writes: >HELP ! >I seem to get extra \r's from putchar()!!!! (or getchar()?) >I am using MWC 3.0 to port BR's splay compression program to the >ST. The program works fine under UNIX(SUN) and IDRIS (PE7300) >but on the ST I get extra 0x0D's (\r) in the output! This is speculative, but I haven't seen any other suggestions: putchar and getchar are macros. They expand to putc(c,stdout) and getc(stdin), respectively. Both stdin and stdout are already opened as ASCII files when your program begins execution. The insertion of 0x0D into your data streams is most likely due to the high level handler attempting to add a carriage return (0x0D) when it sees a line feed (0x0A) in the stream. You can eliminate this by opeing binary input and output files (use "rb" or "wb" as the second parameter in the fopen() call), and use the putc and getc calls directly with the appropriate file handle. -- *George R. Woodside - Citicorp/TTI - Santa Monica, CA *Path: ..!{philabs|csun|psivax}!ttidca!woodside ------------------------------ Date: 24 Jul 89 23:03:00 GMT From: mailrus!jarvis.csri.toronto.edu!dptcdc!tmsoft!masnet!canremote!david.megginson@ purdue.edu (DAVID MEGGINSON) Subject: Re: Amiga vs. Atari ST To: info-atari16@score.stanford.edu I suggest that you look at the software as well as the computer itself. Consider Calamus and DynaCadd on the ST, and compare them to whatever is available on the Amiga. --- * Via ProDoor 3.0R ------------------------------ Date: 28 Jul 89 15:43:19 GMT From: janus!mitchell@ucbvax.Berkeley.EDU (Evan Mitchell) Subject: Re: Amiga vs. Atari ST To: info-atari16@score.stanford.edu In article <89072707200427@masnet.uucp> david.megginson@canremote.uucp (DAVID MEGGINSON) writes: >I suggest that you look at the software as well as the computer itself. >Consider Calamus and DynaCadd on the ST, and compare them to whatever is >available on the Amiga. >--- > * Via ProDoor 3.0R This is true. However, consider Professional Page (full Postscript color seperations (4096 soon to be 16 mil)) and X-Cad. And remember you can run both of them at the same time, and you can add an '030 to your system (A2000 without hacking) and a math co-processor (68882) and lots of good NTSC compatible video software available, and... Don't kid yourself, this isn't an easy choice. I chose to go with the company with the least amount of vaporware... -Evan _______________________________________________________________________________ | Evan Jay Mitchell EECS/ERL Industrial Liaison Program | | mitchell@janus.berkeley.edu University of California at Berkeley | | Phone: (415) 643-6687 | | "Think, it ain't illegal...yet!" - George Clinton | ------------------------------ Date: 28 Jul 89 11:51:51 GMT From: ncrlnk!ncrcam!system!mike@uunet.uu.net (mike) Subject: gnuemacs needed (sections 13-18) To: info-atari16@score.stanford.edu I recently received the GNU emacs binaries posting. I missed sections 13 through 18 though. They just never showed up. Could someone email these to me. Please make sure someone else has not yet sent them so I don't end up with more than one copy. Thnaks mike ------------------------------ Date: 27 Jul 89 15:04:25 GMT From: att!mtuxo!mtgzz!drutx!druwy!dlm@ucbvax.Berkeley.EDU (Dan Moore) Subject: Re: Mega2 hardware questions... To: info-atari16@score.stanford.edu in article <8907250426.AA12717@jade.berkeley.edu>, WSCART01@ULKYVX.BITNET says: > I bought a mega2 about 4 months ago. (Yes, out of warrenty.) I've had some > disk compatablitiy problems. Nothing big, but it seems that my RPM is a bit > on the high end of the scale. I've adjusted drive speeds before, but I > couldn't on the Mega2. I couldn't find a control pot for the motor. There > was a small variable pot but it seemed to be hooked to the stepper moter. > (I tried it anyway, but it didn't make any difference.) There was a bunch > of resisters on the board, i'd hate to think that the speed is hard wired. > Tell me is isn't so! (If it is, which one controls the speed?) Most of the better 3.5" drives use a phase lock loop to control the drive RPM. They are supposed to be calibrated at the factory (the drive company's, not Atari's) and that is it. Most of them do not have any way to adjust the drive speed after they leave the factory. These are the best drives since they have very stable speeds. It takes a lot of extra drag (eg. pushing very hard on the disk media while spinning) to make them change RPM. But if they aren't correctly calibrated they stink. Atari has started using some less expensive drives, belt driven instead of direct drive, most of them do have adjustments for the drive speed. You might try contacting the company that built the drive and asking if (and how) the drive RPM can be adjusted. Depending on which company you may or may not get any cooperation. > There was a little magnet along with, i guess, a magnetic sensor. What is > this for? (Is the drive speed, chip controled?) That is probably the drive speed sensor for the PLL. If so then there is probably nothing you can do to adjust the drive RPM. Dan Moore AT&T Bell Labs Denver dlm@druwy.ATT.COM ------------------------------ Date: 27 Jul 89 14:00:25 GMT From: mcvax!ukc!etive!hwcs!neil@uunet.uu.net (Neil Forsyth) Subject: Packed executables To: info-atari16@score.stanford.edu With respect to the recently posted pack/unpack programs posted to the binaries group I have thought about a few problems that might result when packing executables:- * How does GEMDOS feel about loading a program with a header that does not properly reflect the program that will be run? Even if the base-page is set up accordingly, GEMDOS has seen the weird one first and may have already set up some internal variables. * Also when a program is loaded it is given the largest free area of memory. If there is not enough memory Pexec returns an error. Programs that run bigger than their header states will cause problems here (stack trampling, screen corruption, bus errors etc). * The unpacker that is glued on to the program will have to relocate the host program itself. Possible future uses of the currently unused odd relocation values will be lost here. * It will also break if a TOS patch ever has to modify the program before executing it. Personally I am not happy with the idea. Compacting data files is fine and I like it, but not executable programs. I invite Atari themselves to to comment on this because they probably know of even more horror stories that could result (and I can also ask them to post the Pexec cookbook they promised us long ago). +-----------------------------------------------------------------------------+ ! DISCLAIMER: Unless otherwise stated, the above comments are entirely my own ! ! ! ! "I think all right thinking people in this country are sick and tired of ! ! being told that ordinary decent people are fed up in this country with ! ! being sick and tired. I'm certainly not and I'm sick and tired of being ! ! told that I am!" - Monty Python ! ! ! ! Neil Forsyth JANET: neil@uk.ac.hw.cs ! ! Dept. of Computer Science ARPA: neil@cs.hw.ac.uk ! ! Heriot-Watt University UUCP: ..!ukc!cs.hw.ac.uk!neil ! ! Edinburgh, Scotland, UK ! ------------------------------ End of Info-Atari16 Digest ************************** -------