Info-Atari16 Digest Thu, 3 Oct 91 Volume 91 : Issue 524 Today's Topics: Atari 1040STf with hard drives for sale C on the ST GhostScript and all that Good places to anon-ftp atari-pd-software from lharc 2.01e vs zoo 2.1: some tests lharc source... lharc vs. zoo (my correction) lharc vs zoo (my correction) Mega2 questions Questions on PC-Speed SIM CITY - STe Compatible???? SST for 1040STe's ?? STE simms Using gcc/g++ to cross compile for the ST ZOOSHELL 0.6 Welcome to the Info-Atari16 Digest. The configuration for the automatic cross-posting to/from Usenet is getting closer, but still getting thrashed out. Please send notifications about broken digests or bogus messages to Info-Atari16-Request@NAUCSE.CSE.NAU.EDU. Please send requests for un/subscription and other administrivia to Info-Atari16-Request, *NOT* Info-Atari16. Requests that go to the list instead of the moderators are likely to be lost or ignored. If you want to unsubscribe, and you're receiving the digest indirectly from someplace (usually a BITNET host) that redistributes it, please contact the redistributor, not us. ---------------------------------------------------------------------- Date: 2 Oct 91 23:04:11 GMT From: noao!asuvax!cs.utexas.edu!milano!cactus.org!covert@arizona.edu (Richard Covert) Subject: Atari 1040STf with hard drives for sale To: Info-Atari16@naucse.cse.nau.edu FOR SALE: 1040STf with 2.5 megs RAM, dual TOS 1.0/1.4 Atari SM124 monochrome monitor Tweety board (not installed) IMG SCAN scanner Asking $550 for the computer system. Also two hard drive systems: Atari MegaFile 30 $300.00 30 megabyte hard drive TOADFILE 85 $600.00 85 megabyte hard drive. Room for a second 85 meg drive in cabinet. 130 megabyte home built hard drive. This is kinda upgly as the original power supply burned out and I replaced it with a larger power supply that wouldn't fit in the cabinet. So, I have the two Seagate 65 meg drives with the ICD host adapter and the power supply sitting in an open cabinet. Asking $500 for this one. Also, Panasonic KXP4450 laser printer with 1.5 megs RAM, dual paper trays, 11 pages per minute printout (heavy duty office quality laser printer) $1000.00 (you pay shipping). The KXP4450 is cheap to use as the toner kit only costs about $45 from any office supply store. I use Hurrican Office here in Austin. I have some software I might be talked into including as well, just ask. -- Richard E. Covert covert@cactus.org CACTUS ..!cs.utexas.edu!cactus.org!covert ------------------------------ Date: 2 Oct 91 23:27:35 GMT From: noao!asuvax!cs.utexas.edu!swrinde!zaphod.mps.ohio-state.edu!uakari.primate.wisc .edu!unmvax!uokmax!kllove@arizona.edu (Kenneth L Love) Subject: C on the ST To: Info-Atari16@naucse.cse.nau.edu Okay, I've posted this question before, but I lost my reply file. I'm looking to get C for my Mega 2, but I need something that can be used from a floppy based system (I have to DS/DD drives). Is Sozobon any good? Will it work with the above condition? I bought called 'A Book on C' by ??? and Ira Pohl. It seems to have quite a good discussion on C (for IBM/Unix systems :( ), but I couldn't find anything about how to check the mouse or anything about graphics. Is there an Atari specific book that talks about this? Oh yeah, I want to convert a BASIC program to C, but I need to know how to do PEEKs and POKEs in C. I'm not sure what the ST Basic command "vdisys(1)" does, but I gather it has something to do with the mouse (based on the context of the program). What the "chain" command is and how it works would also be nice to know. Please respond by e-mail as I don't keep up with this newsgroup on a regular basis (messages are gone in 2 days around here and I read r.g.frp, r.a.startrek, and r.a.drwho before this one). Thanks in advance, Kenneth Love ------------------------------ Date: Thu, 3 Oct 91 15:51:35 WET DST From: "Ian McCall (Scorpion)" Subject: GhostScript and all that To: Info-Atari16@naucse.cse.nau.edu I've been hearing quite a bit about GhostScript recently, and it sounds very interesting. But it's part of GNU or something, isn't it? Could somebody post up exactly what I'd need to do, from scratch, to get a working version of GhostScript? Also, I now own a Mac LC as my main machine, but I've heard you can get GNU for the Mac too. Is GhostScript around for that, and if so, would I just follow the same procedure with Macintosh versions of the files as I would for setting up the ST version? Thanks in advance, Ian McCall (csd015@uk.ac.lancs.cent1) ------------------------------ Date: 2 Oct 91 15:27:27 GMT ------------------------------ Date: 2 Oct 91 18:36:52 GMT From: garfield!odie.cs.mun.ca!david10@uunet.uu.net (David Churchill) Subject: lharc 2.01e vs zoo 2.1: some tests To: Info-Atari16@naucse.cse.nau.edu In article <1991Oct02.023218.28662@infoserver.th-darmstadt.de> DE7B@br1.hrz.th-darmstadt.de (WALLMANN, GEORG) writes: >Following the discussion I tried three archiver programs >to backup 151 files worth 700KB of data. The data consisted >almost entirely of documentation (ASCII) and C source. > >Machinery: ST-1MB w/40MB ST-251-1 >I did NOT clean my partition for this test, why should I? I >never evacuate any partition just for arcing things up. So >I think this is more true to life, than any more 'scientific' >setup. I did the test twice, which didn't change any of >the timing values significantly and gave every program >a 'fair' chance on a equally fragmented harddisk. Fragmentation >is more of an issue when unpacking anyway. Fair enough. > >Results: > >ARC 6.02 > Size: 304048 bytes Time: 3:48 > >ZOO 2.1 > Size: 307207 bytes Time: 4:45 >after issueing a pack command for an additional 2:20 > Size: 307151 bytes ~~~~~~ Hmmm, something fishy here . . . zoo 2.1, using the high compression scheme, should be closer to LHARC than this. > >LHARC 2.01d > Size: 218964 bytes Time: 6:13 > >(my) conclusions: > So guess what, good old ARC is by far the fastest, > LHARC is the tightest, > And ZOO well the -um- most compatible... > > >And they way I called them (thru make) > >#ARC=arc ># update >#UPDATE=u ># update with subdirectories >#DIRUP=uz > >#ARC=zoo ># update >#UPDATE=aun: ~~~ Yup, this is a zoo 2.01 compatible archive, not a 2.1 archive. To use the high compression method, the command line should be 'ahun', not 'aun'. ># update with subdirectories >#DIRUP=aun// Ditto for here. > >ARC=lharc ># update >UPDATE=u -s -wf:\tmp ># update with subdirectories >DIRUP=u -r2 -p -s -wf:\tmp > >GSOURCES=*.h *.c *.tlk *.s *.y make*.* memo > >backup: > $(ARC) $(DIRUP) arc\backup support doc lib header demo > $(ARC) $(UPDATE) arc\backup $(GSOURCES) It's a good test (in a real-world sense), but to be fair to Zoo 2.1, it can compress files MUCH better than what this test has shown, along with being more compatible across platforms. > Nat! Later, Dave C -- Dave Churchill DoD #266 * * * CS Undergrad (Class of '92) david10@garfield.cs.mun.ca * * * Memorial University of ar473@freenet.cleveland.edu * * * Newfoundland. My opinion is just that - mine! * * * St. John's, NFLD Canada ------------------------------ Date: 2 Oct 91 22:53:13 GMT From: noao!asuvax!cs.utexas.edu!convex!rosenkra@arizona.edu (William Rosenkranz) Subject: lharc source... To: Info-Atari16@naucse.cse.nau.edu since i have received numerous requests for lharc 2.01e source in anticipation of actually getting it, let me try and put an end to these requests. i have just received the source from thomas (infinite thanx, that wasn't so hard now was it?). however, i also agreed that i would NOT distribute this source, or any derivative source and i will abide by that agreement. please don't bother asking me. i cannot and will not post it or mail it or in any other way distribute it. i will ignore all requests for same. i gave my word. with that in mind, however, when/if i have time, i do intend to return this particular version BACK to 100% C, in fact 100% portable ANSI/POSIX (32-bit int) C. i will focus on the portions of the code in assembler, returning them to C. i will profile the code (even vectorize it!) and optimize the C performance as much as i care to so that i will be satisfied with its performance. i will also fix the bugs in it. this will not happen for several months. after that, i will return this portable version to thomas for his own use. if he chooses to release it, he can. if he chooses to continue that work, i will applaud him. if he moves it to /dev/null, that is fine, too. oh, and i'll go further: i will not post/mail/etc a BINARY ST version either which would be as bad (actually worse). i might be persuaded, however to distribute a convex executable image, if anyone out there has a convex :-). so, i guess i am happier now about the lharc situation. TQ's version does seem to be the best version on the ST. and i will eventually (finally) have a unix version to boot. henceforth, i shall retire from most all public discussions on portability of archive formats. i still don't think i can recommend lharc as a universal archiver, but at least i have done something for myself to remedy some of the problems i have with it. i still think at this point in time, zoo is about the best overall archiving system available across the board (i.e. independent of platform). a close second would be compressed tar files, i think. then arc, and then possibly lharc. lharc _could_ rise to the top of my short list by having all lharc developers get together and decide on a standard. i just don't ever see that happening. i think someone mentioned that the amiga version also uses the lh4 format, which i am not sure 2.01e supports. so some amiga .lzh files would not be extractable on an st. of course, at some future time, there will probably be an new lh* format. then i am again back to bitching... thank you all for your support during this effort. now we can proceed with other issues :-) -bill rosenkra@convex.com -- Bill Rosenkranz |UUCP: {uunet,texsun}!convex!rosenkra Convex Computer Corp. |ARPA: rosenkra@convex.com ------------------------------ Date: 3 Oct 91 14:59:11 GMT From: europa.asd.contel.com!darwin.sura.net!Sirius.dfn.de!math.fu-berlin.de!mailgzrz! opal!unido!mcsun!news.funet.fi!sunic!chalmers.se!dtek.chalmers.se!dxper@uunet.u u.net (Per Anders Olausson) Subject: lharc vs. zoo (my correction) To: Info-Atari16@naucse.cse.nau.edu DE7B@br1.hrz.th-darmstadt.de (WALLMANN, GEORG) writes: >As two people have pointed out I lost 'cause I oversaw the 'h' option >on Zoo 2.1. I ran the tests again and sure enough the results of ZOO >came very close to Lharc. Which makes conclusion wise ZOO as good >as Lharc really. I found when using ZOO V2.1 from my backup program (which can use any compression utility) that ZOO V2.1 still wasn't completely error free. Unfourtunately I don't remember what the implications were, but since then I use LHarc. Both ZOO and LHarc are the only, known to me, which accepts hidden and system files so for me that's the only choice. Also note that the earlier LHarc V2.01? versions quite a lot of bugs which could trash compressed data. pao -- .............................Andrew Olausson................................ ............................Systems Architect............................... ..........................dxper@dtek.chalmers.se............................ ..............................pao@proxxi.se................................. ------------------------------ Date: 3 Oct 91 22:53:34 GMT From: noao!asuvax!cs.utexas.edu!convex!rosenkra@arizona.edu (William Rosenkranz) Subject: lharc vs zoo (my correction) To: Info-Atari16@naucse.cse.nau.edu In article <1991Oct03.183321.13105@infoserver.th-darmstadt.de> DE7B@br1.hrz.th-darmstadt.de (WALLMANN, GEORG) writes: >I/O. The cleverer the buffering strategies and the less i/o done (in ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ >most cases) the better. If you just do I/O on ideal devices (clean RAMdisk), >you are punishing programs who use more clever i/o in order to circumvent >the ususal everyday pitfalls. yes. agreed. and i did eliminate this from the test as well, tho not for the reasons that people thought ("he hates lharc so he wants to make sure zoo wins"). you are correct that a comprehensive test would have sought out these strategies as a desirable trait. i did mention this in the original post as well. my hypothesis going into the test was that both were going to be pretty equal on all fronts. my evidence was that zoo was compiled with GNU C by someone whose previous (excellent) work i was familiar and that lharc was well tuned by conversion to assembler. to be fair to me, however, and those with similar situations, i generally either extract a new archive into a ramdisk to "check it out" or when creating an archive of something on hard disk i write to an archive file in ramdisk. in both cases, which constitues maybe 75% of my archiving, maybe more, the only cleaverness is how the original files are read and the disposition of any temporary files (i.e. is the program smart enuf to recognize i am ususally smart enuf to make $TEMP a ramdisk?). i think the fact that your equally limited tests, tho perhaps more realistic for your particular use, shows little difference implies that as far as IO is concerned, both are about as smart (or dumb). i suspect smart because i know of at least one tiny modification (which bill shroka did in fact do) which improves zoo's performance. i have not had a chance to examine lharc, tho i suspect it handles things pretty much the same. >As devices get faster, I/O importance lessens. another important point which can be broadened futher: as cpu's get faster, archiver tuning lessens in importance. as disks and communications get cheaper and faster, compression ratio lessens in importance. >BTW: A better test would be to setup partitions of various sizes and fragmen- >tation on several different devices and then do the tests again >(just in theory, who's got the time..) - and - Just because a result is repro- >ducable, doesn't make it automatically the most meaningful result. yes, but it DOES make it reproducable, in itself desirable over something both non-meaningful and non-reproducable. one is subjective, the other objective. your definition of meaningful may not be meaningful to someone else. and even if it were, if it could not be reproduced, it would resort to hearsay. there are ALWAYS better tests. i think mine was fair for what i did. i tried to point out some of the weaknesses in the test that i saw. and i think that there can be no question that it is valid if all your archiving is done in ramdisk. except that i did not necessarily use "calibrated" files. i did, however, give a source for the files at least in one of the tests (portions of the MiNT distribution) so it could be reproduced. > Nat! (using ZOO [with 'h'] more often nowadays) EXCELLENT!!!! ciao -bill -- Bill Rosenkranz |UUCP: {uunet,texsun}!convex!rosenkra Convex Computer Corp. |ARPA: rosenkra@convex.com ------------------------------ Date: 3 Oct 91 21:40:06 GMT From: europa.asd.contel.com!darwin.sura.net!haven.umd.edu!uflorida!mailer.cc.fsu.edu! open!boyd@uunet.uu.net (Mickey Boyd) Subject: Mega2 questions To: Info-Atari16@naucse.cse.nau.edu In article , kenneth@matt.ksu.ksu.edu (Kenneth W Samson) writes: >I have three questions for those outthere that have Mega2s... > >2) I know that Mega2 will go to 4 meg of memory, but will it > go all the way to 16 with standard simms on the motherboard? > This is not true. Some Mega2's have the traces and sockets for more memory (none of them use SIMMS, by the way). Some have the traces, but no sockets. The newer ones not only have no traces or sockets, but they have an MMU that only allows for 2mb. You can upgrade any Mega2 with a third- party board, but you may need a new MMU also (they are not all that expensive). Four megabytes is all the Mega's can handle unless you do strange things (which would undoubtedly cause a lot of software to bomb). Dave small reports that he has a 16meg 1040 for Spectre testing purposes. Also, I read once that there are a select few Mega2's out there that have 4 megs in them, but are jumpered (or trace-cut) to only access 2megs. The reason for this (reputedly) is that if a Mega4 fails quality control, they jump/cut it and test it as a Mega2. If it works, it gets packed up and sold. One poster to this group (about two years ago, I seem to remember) was shocked to find this out. After tracing down the bad chip, he replaced it and un-jump/cut the motherboard to get a Mega4. Ahh, the stuff dreams are made of . . . -- ---------------------------------+------------------------------------- Mickey R. Boyd | "Come to your senses professor FSU Computer Science | Fernberg. You did not transcend Technical Support Group | the time-space continuum. You email: boyd@nu.cs.fsu.edu | got drunk in a topless bar." ---------------------------------+------------------------------------- ------------------------------ Date: 3 Oct 91 21:09:31 GMT From: arizona.edu!cerritos.edu!orion.oac.uci.edu!usc!zaphod.mps.ohio-state.edu!unix.c is.pitt.edu!dsinc!netnews.upenn.edu!eniac.seas.upenn.edu!efaskha@arizona.edu (Eli Faskha) Subject: Questions on PC-Speed To: Info-Atari16@naucse.cse.nau.edu Help. I've had a PC-Speed for some time, but haven't really taken full advantage of it. I know it can recognize the Atari ST mouse as a Microsoft Mouse, but I can't get it to do it... Also, what's the latest revision of the software? I have revision 1.3, and I think there might be a new one out. Where can I get in touch with Talon Technologies? Anyone know a net address or phone number? Thanks, Eli ------------------------------ Date: 3 Oct 91 02:05:23 GMT From: noao!asuvax!cs.utexas.edu!swrinde!zaphod.mps.ohio-state.edu!pacific.mps.ohio-st ate.edu!linac!unixhub!ditka!slacvm!reeves@arizona.edu (Terry Reeves) Subject: SIM CITY - STe Compatible???? To: Info-Atari16@naucse.cse.nau.edu Sim City runs just fine on my STE, a 4meg 520 STE. The TOS version is 1.62. Terry Disclaimer: The above opinions are my own, and mine alone. ------------------------------ Date: 3 Oct 91 03:29:46 GMT From: noao!asuvax!cs.utexas.edu!swrinde!zaphod.mps.ohio-state.edu!cis.ohio-state.edu! udecc.engr.udayton.edu!blackbird.afit.af.mil!lonex.rl.af.mil!longj@arizona.edu (Jeffrey K. Long) Subject: SST for 1040STe's ?? To: Info-Atari16@naucse.cse.nau.edu Can anyone tell me if Dave Small will make a version of the SST that will work with 1040STe's?? I remember reading something about it several months ago, something to the effect that if STe sales warranted, then an adaptor to connect to the square 68000 in STe's. I sure hope the answer is yes! I am about ready to upgrade somehow, and the thought of being able to get an '030 box that might be able to run UNIX and still have my beloved atari stuff close at hand is intoxicating!! If yes, when and about how much will such a beast set me back? Jeff -- ---------------------------------------------------------------------------- Capt Jeff Long Rome Laboratories, Griffiss AFB, NY longj@lonex.rl.af.mil (preferred) Network Design Laboratory jlong@cassiopeia.rl.af.mil (315)330-7751 or (DSN)587-7751 ------------------------------ Date: 2 Oct 91 12:39:08 GMT From: aahs.no!data3d@ucbvax.berkeley.edu (Karl Anders 0ygard) Subject: STE simms To: Info-Atari16@naucse.cse.nau.edu [Wayne Martinez writes] >Can I just go out and purchase some simms, crack the case, >and plug them in? Obviously. At present I've got 4 9-bits 70ns 1Mb simms installed in my STe, giving me a total of 4megs. I got the simms 9-bits (8-bits will pass, I think) and 70ns (100ns should be enuf?) so that I'd be able to use them on a PC or a Mac, should I decide to do so. Mind you, all of this may be wrong. Correct me if it is. ;) Karl Anders Oygard - Karl A Oygard ------------------------------ Date: 2 Oct 91 23:25:45 GMT From: noao!asuvax!cs.utexas.edu!convex!rosenkra@arizona.edu (William Rosenkranz) Subject: Using gcc/g++ to cross compile for the ST To: Info-Atari16@naucse.cse.nau.edu >I'd like Unix zoo 2.1 source too, been too lazy to go looking myself. atari.archive.umich.edu:atari/archivers/zoo21src.* (forgot if zoo or arc). >I'm a little hazy on the MiNT support in the current version of gcc. >It causes the mint libraries to be loaded before the regular libraries, >but the mint library docs say "use this instead of the regular gnu >libraries." Some agreement/clarification would be nice. sure, howard: it took me a couple of tries myself. however, is is not too bad. i think the makefile in the t100 terminal emulator i recently posted has this. let's see if i can remember (for GCC 1.40, gmake 3.60, mint lib PL 10, i think - gmake contains some of my own hacks to get it to work for me): # makefile from t100 (compiled for mint) CC = gcc OPT = -O # -v=verbose, -Wall=all warnings, -z=errs to compile.err, -I->mint *.h CFLAGS = -v -Wall -z -Ig:/mint/include $(OPT) # -nostdlib is the key. also explicit crt0.o LDSPECIAL = -nostdlib g:/mint/lib/crt0.o # -L->mint *.olb LDFLAGS = -v -Wall -z -Lg:/mint/lib $(LDSPECIAL) # both gnu.olb and iio.olb must be specified as a byproduct of -nostdlib LIBS32 = -lgnu -liio LIBS16 = -lgnu16 -liio16 # if -mshort, use LIBS16... LIBS = $(LIBS32) TARGET = (your .ttp file here...) OBJS = (your program .o files here...) $(TARGET): $(OBJS) $(CC) $(LDFLAGS) -o $(TARGET) $(OBJS) $(LIBS) there is probably a better way, but something along this lines should work. i keep "normal" gnu libraries and includes in g:/gcc/{lib,include}. -bill rosenkra@convex.com long live GCC... -- Bill Rosenkranz |UUCP: {uunet,texsun}!convex!rosenkra Convex Computer Corp. |ARPA: rosenkra@convex.com ------------------------------ Date: 3 Oct 91 20:06:40 GMT From: noao!asuvax!cs.utexas.edu!qt.cs.utexas.edu!zaphod.mps.ohio-state.edu!caen!spool .mu.edu!cs.umn.edu!thelake!steve@arizona.edu (Steve Yelvington) Subject: ZOOSHELL 0.6 To: Info-Atari16@naucse.cse.nau.edu I recently shipped ZOOSHELL 0.6 off to atari.archive.umich.edu, and (naturally) a bug surfaced quite quickly. The bug is fairly obvious in the code, which also is available at a.a., so if you have Sozobon C and want to fix it, change the following in main(): strcpy(zoottp,p); to if (p != NULL) strcpy(zoottp,p); This bug surfaces only if ZOOSHELL can't find ZOO.TTP in the current directory or with a PATH search. If you use an environment-setting utility (which I wholeheartedly recommend for Desktop users) you'll never encounter this one. I intend to release a newer version of ZOOSHELL, but at the moment I'm bogged down in the process of writing ARGV-compatible startup and process-control code so that ZOOSHELL can pass very long arguments to ZOO. (I also am doomed to work for a living, which interferes with recreational pursuits.) -- Steve Yelvington, Marine on St. Croix, Minnesota steve@thelake.mn.org (In winter we walk on water) ------------------------------ End of Info-Atari16 Digest ******************************