Today's Topics: *.doo PICTURE FORMATS ARJ? Golf sims Install an app for two diff filetypes, term with IBM graphics option? LHARC 2.01E VS ZOO 2.1: SOME lharc 2.01e vs zoo 2.1: some tests (2 msgs) People dumping machines (was.. Atari Mega 2 system.. for sale) PEOPLE DUMPING MACHINES... Populous / Powermonger Railroad Tycoon Needs File (2 msgs) SLM804 laser printer Spectre GCR/System 7/A/UX 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 06:24:24 GMT From: munnari.oz.au!goanna!minyos.xx.rmit.oz.au!t821431@uunet.uu.net (Richard Clarkson) Subject: *.doo PICTURE FORMATS To: Info-Atari16@naucse.cse.nau.edu What programs are available that allow one to draw/paint in *.doo picture formats? I am chasing a program that does such format! Many thanks in Advance Richard Clarkson ------------------------------ Date: 1 Oct 91 14:49:17 GMT From: noao!asuvax!cs.utexas.edu!convex!rosenkra@arizona.edu (William Rosenkranz) Subject: ARJ? To: Info-Atari16@naucse.cse.nau.edu In article blackbox@pfunk.hanse.de writes: >In <1991Sep22.175916.104@convex.com>, William Rosenkranz writes: >>pfx is nice. i do use it on occasion. i plan to use it more now that i > >What does that mean ? Why do you have to get the source of pfx before you >pay the shareware fee ??????? DM 20.- (About US$ 12.-) isn't much for a >powerfull tools like the extended pfxpak+, so why should TQ deliver the >source. If I write a program, I don't want everybody to extend their own >programs by including my sourcecode. If you use pfxpak, you have to pay, >if you want the source, you have to pay more ( I think, TQ will perhaps >behave like that ). well, as i explained countless times, although the argument is certainly weaker with pfx, i don't use any archiver at all unless i have source to it. i want to insure that i can get at any datafile i have on any future system i have. with packed executables, this is less of a problem because they will generally only run on an ST. that is unless i go and load up the .ttp file with other files as well. so far, i have used pfx on exactly 3 executable files out of hundreds. it does not make even a tiny dent in my disk usage. i can (and have) disassemble it since it is not that big. unfortunately, when my system crashed when trying to get lharc to work with MW/ARGV extended args, it took my ramdisk along with it (where i had the disassembled source temporarily - VERY temporarily in this case :-). and no, i do NOT intend to give the disassembled source to anyone. it is for my own use, for insurance. i have on occasion, with software i use often, supported shareware. usually with PC programs (PC write, AM Tax, etc). on the ST there are fortunately lots of software, with source, where the author or or person doing the port ask for nothing. i have never asked for a single penny with codes i post here which i know more than a few people use (nroff, mgif, man/manpager, etc). nor did the person porting zoo 2.1 for that matter. i have no problems with people wanting to make a buck for their labor. i just don't tend to use s/w on the ST that is not either of my own writing, or PD or whatever. and archivers, for the reasons i outlined, i treat differently than any other sort of program. when i post code, i generally always post source. and i place no restrictions on its use at all. i generally don't even include a copyright. and the code i write ends up in some odd places (nroff became the text formatter for minix, tho i did not even write it for that purpose, not do i even have an operational minix system). i just don't care that minix is distributed (for profit) with one of my codes in source form. requesting the source, in this case, will save me the time of disassembling it, correcting the disassembled source, reformatting it, and annotating it. pfx is small enough that this is no more than a couple hours work so it is not a big deal. and if i intend to make widespread use of this program, i WILL disassemble it, and have source anyway. i don't think there is any law on the books that prohibits me from doing this, especially if it goes no further than my system, which it won't. it is a simple request to save me some time. with 80 MB of disk at my disposal, the couple of MB it will save is not a huge benefit anyway. i would not disassemble a spreadsheet, database, or any other sort of program. but for me, archivers are different. -bill rosenkra@convex.com -- Bill Rosenkranz |UUCP: {uunet,texsun}!convex!rosenkra Convex Computer Corp. |ARPA: rosenkra@convex.com ------------------------------ Date: 1 Oct 91 17:41:38 GMT From: cis.ohio-state.edu!turtle.cis.ohio-state.edu!thompson@uunet.uu.net (jeffery d thompson) Subject: Golf sims To: Info-Atari16@naucse.cse.nau.edu A little while ago I bought Jack Nicklaus' Greatest 18 Holes of Golf and I was wondering if there are any course disks or course builders available. Any information is greatly appreciated. Jeff thompson@cis.ohio-state.edu ------------------------------ Date: 1 Oct 91 14:21:18 GMT From: mcsun!unido!horga!presto!dc@uunet.uu.net (David Channing) Subject: Install an app for two diff filetypes, term with IBM graphics option? To: Info-Atari16@naucse.cse.nau.edu In article <6446.28e738d9@miavx1.acs.muohio.edu> rlcollins@miavx1.acs.muohio.edu (Ryan 'Gozar' Collins) writes: > > 1. Is there anyway to install an application for more than one filetype? > filetype. Well, it won't let you do that under 1.4 :*( So I tried to > edit the desktop.inf file adding the required lines to install the > application for two filetypes. Well, my ST just crashed on boot up You must have messed up your desktop.inf file editing it. Here are the relevant lines from my desktop.inf which works with no problems: #F FF 04 C:\BIN\ARCLOAD.PRG@ *.ARC@ #F FF 04 C:\BIN\ARCLOAD.PRG@ *.LZH@ #F FF 04 C:\BIN\ARCLOAD.PRG@ *.ZOO@ -- dc@presto.ruhr.de dc@presto.ruhr.sub.org ------------------------------ Date: 1 Oct 91 16:09:47 GMT From: noao!asuvax!cs.utexas.edu!convex!rosenkra@arizona.edu (William Rosenkranz) Subject: LHARC 2.01E VS ZOO 2.1: SOME To: Info-Atari16@naucse.cse.nau.edu In article <686311578.2@fquest.FidoNet> Philip.Durgin@fquest.FidoNet.Org (Philip Durgin) writes: >One thing you forgot to take into account, If you optimize your HD before you >run any of those tests, the amount of time need to add or extract a file is >significantly different. We use LHarc201d.ttp as part of our Network software. >We found that many things can change how fast a file may be extracted or added >to a file. Your test bed is flawed, a strict ram disk would have show a better >corrilation of the true speed for extracting or adding a file. I will try it on >our board and upload the differences. i did not fail to take this into account. i did discuss the HD issue. i have also pointed out that unless a partition is clean, i very well could produce wildly differing results if significant i/o takes place. at least the ramdisk offers equal footing, if you do alot of archive manipulation in ramdisks (which i do, BTW). i know that this test may not be representative of many situations, that, in effect, i cancelled i/o from the equation (which i realize could be EXTREMELY significant). i did mention this, however. at any rate, the test does point to the actual compression speeds, minimizing i/o since it is MUCH faster to go to memory than disk. if i had an empty partition (if i EVER have an empty partition :-) i would have done the test in both the ramdisk and the HD. i would have compared the relative speed ratio ramdisk/hd for each program. note that with zoo, i could also have profiled the code and isolated the routines where most of the time is spent. i believe bill shroka did that when he ported zoo 2.1. i look forward to seeing a thorough test, similar to the one i did, but in HD partitions. just be aware of these potential variables, however: - disk access speed (run both with similar disks) - disk interleave - amount of pre-existing data in the partition and the amount of fragmentation. ideally, you want to run these tests in the same empty partition. - location of temporary files. ideally, and i am not even sure this is ideal, you would want the temporary files to be located in the same partition as the test. be careful with environment variables called "TMP" or "TEMP". if these point to a ramdisk and one of the programs use this while the other does not, your test is biased. or at least point out that one has this feature and the other does not. that would be a signifiant plus, IMHO. i tried to eliminate all of these by simply working in a ramdisk for the first cut. i would tend to think that both programs do similar amounts of i/o, so the program that uses bigger buffers and/or inlined i/o will probably win. i don't know which one that is. if you can do this over a network, that would be another interesting set of datapoints. however, in equal environments, i would expect both codes to function about the same. good luck. please post the results... -bill rosenkra@convex.com -- Bill Rosenkranz |UUCP: {uunet,texsun}!convex!rosenkra Convex Computer Corp. |ARPA: rosenkra@convex.com ------------------------------ Date: 1 Oct 91 15:47:27 GMT From: noao!asuvax!cs.utexas.edu!convex!rosenkra@arizona.edu (William Rosenkranz) Subject: lharc 2.01e vs zoo 2.1: some tests To: Info-Atari16@naucse.cse.nau.edu In article <9606@mcshh.hanse.de> the.fawn@mcshh.hanse.de (Thomas Quester) writes: >LHarc is only partly written in assembly-language. Some parts i am sure the parts in assembler are the parts that are highest on the profile. zoo does its thing in 100% portable C. the same code i run on a supercomputer will compile and run on my ST with little if any changes. and it will run about as fast as lharc and will produce files of similar size. >of the coder itself are in C. It only is a long hand hard way >to produce a higly optimzied version of about 1000 lines of >nearly undocumented source. The rest of the coder and decoder >will be written in assembly language some times later. It took >some version to make 1.13 four times faster. tho i laud your efforts in making (your) lharc scream, i still cannot unpack lh5 archives on non-atari (eg unix, VMS, etc) systems. it sounds like the original C for lharc was really bad. i do contend, however, that it would have been far better to 1) restructure the C, 2) profile the code, isolating hot spots, 3) find the reason why it is slow and remedy (try inlining, register variables, -O in gcc, etc), and 4) provide the source. zoo does exactly that. the changes made to zoo to get it to run and to run fast are minimal. >>i tried: >> >> lharc a lll * >> >>and my system crashed! lharc does NOT handle extended args. and what's more > >It does handle the ARGV, but only up to 200 filenames. I bed >you to retype your command, maybe someting went wrong earlier. i did not have 200 file names. more like 15, but longer than the 125 or so chars Pexec handles. this is obviously a bug in your ARGV which is appearently not capable of handling MW-style ARGV. zoo (actually GNU C) ARGV support does. >> - nitpicking: zoo lists files one per line. it is easier to grep >> things out for more specialized uses (like making lists of all >> .c files with their statistics). > >Why not use lharc l archiv? ok, i will. this was a minor detail. with virtually every other archiving system, the syntax "xxx v archive" gives me one line per file format. lharc uses 2 lines. it is not consistent with arc and zoo. and it is a VERY minor detail (nitpicking). i only mention this because i sometimes do use the archive listing for other purposes than listing it to the screen. it is not a big deal. >> - zoo 2.1 can extract files from ANY zoo archive of equal or >> lesser version. older versions of zoo can list any zoo archive >> even if made with a newer version. if a newer version is needed >> to extract files, the older zoo tells you what version you need. > >So Lharc does. It will not say the version number, but give a >message "unknown method". Though there are some versions of >LHarc availbe without this test (for example unlzh). no. some older versions of lharc will die and crash the system on some other (newer) lharc formats. what i was saying is that zoo 2.01 (?) will list a zoo 2.1 high compression archive, but it can't extract files, but it 1) tells you the version you need to do so, 2) will not crash. the big difference is that rahul dhesi takes an active part in zoo. yoshi does not appear to, at least in the US. and like i've said a zillion times, there is only one zoo. responsible people doing ports send the changes back to rahul so he can sanction them and incorporate the changes for the next release. this, from what i can tell, does not happen with lharc. there are many, many incompatible lharc programs, as you of course know. that means there is no standard lharc on every platform. yours may be standard on the ST, but it is far from universal (like zoo or arc). there are unix and VMS versions of these. there are none for lharc 2.01e (because of the assembly language). again, i offer to port it to unix where it may run slow, but it will at least run. do u understand the differences i try to point out here? the ST is not the center of the universe with respect to archivers. i think if ARJ is as good as people say, then both lharc and zoo will die anyway. so perhaps i am wasting my time. -bill rosenkra@convex.com -- Bill Rosenkranz |UUCP: {uunet,texsun}!convex!rosenkra Convex Computer Corp. |ARPA: rosenkra@convex.com ------------------------------ Date: 2 Oct 91 02:32:18 GMT From: arizona.edu!cerritos.edu!nic.csu.net!usc!zaphod.mps.ohio-state.edu!sol.ctr.colu mbia.edu!ira.uka.de!THD-News!news@arizona.edu (WALLMANN, GEORG) Subject: lharc 2.01e vs zoo 2.1: some tests To: Info-Atari16@naucse.cse.nau.edu 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. 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 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: # update with subdirectories #DIRUP=aun// 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) Nat! ------------------------------ Date: 1 Oct 91 23:34:21 GMT From: noao!asuvax!cs.utexas.edu!qt.cs.utexas.edu!zaphod.mps.ohio-state.edu!magnus.acs .ohio-state.edu!usenet.ins.cwru.edu!yfn.ysu.edu!ysub!psuvm!cunyvm!jokhc@arizona .edu (Joshua Kronengold) Subject: People dumping machines (was.. Atari Mega 2 system.. for sale) To: Info-Atari16@naucse.cse.nau.edu In article <1991Oct1.122126.22170@rhrk.uni-kl.de>, herzling@rhrk.uni-kl.de (Alexander Herzlinger [Informatik]) says: > >In article <91274.024720JOKHC@CUNYVM.BITNET> JOKHC@CUNYVM.BITNET (Joshua >Kronengold) writes: >.... >>Sorta. It IS a 32mhz proc in a 16mhz architecture with a cache, but if you >>have TT-ram, the TT ram is counted as cache. So most applications that use the >>high speed will fit entirely in the 'cache,' acting as if it was a 'true' 32m z >>machine.(animation is an exception, but I suspect the Blitter might help with >>that). So, most of the time it will act faster than the 'true 25mhz 68030'. >> >>Someone correct me if I've said anything disasterous. >Which part of the architecture is based on 16Mhz ? Please be a little more >specific. TT-Ram is normal ram that is organized 32Bit width and can be >accessed via burst mode. In my opinion a cache is something different, >e.g. having a 'syncronized' (sorry I am no technican so this might be the >wrong word for it) memory like in the ST (or the so called ST-Ram in the TT) >and this does not let you access more than it is build to. If you want to >use fast prozessors but have only this type of ram every ram access would be >slowed down, so you use a small piece of high speed ram (the cache) wich >maps often access areas of the normal memory. >But programms running in TT Ram do not need to access ST-Ram (they >could if they want of course) and therefor run all the time in fast TT-ram. >So if you speak of 16Mhz Architecture this means for me that parts of the >computer are slowed down due to some 16Mhz clock. The only thing I can think >of what is slowed down is the 64Bit width ST-ram bus. There the videologic >has to access the bus very often so the 68030 has to wait until the video- >logic has finished their access-cycle. >So in my eyes the TT has fast TT-Ram and a big video/multipurpose ram >>hich can be used by programms too, and I do not see any big disadvantages. >ciao, > Alex >-------------------------------------------------------------------------- >Alexander Herzlinger University of Kaiserslautern >E-Mail: herzling@rhrk.uni-kl.de correct me if I am wrong >-------------------------------------------------------------------------- Well, that is what I said, after all, 'has no effect except for animation' and /o. I can also see no major disads though it might have an effect on real-time ni, though, like I said, if the blitter can speed up bit-block transfers, it might be able to surmount that problem. ~~~~~~~~~~~~~~~~~~~ of course it can, I meant bettween TT and ST ram. ------- < Joshua Kronengold > < "Oh Lord, what fools these mortals be!"-Robin Goodfellow > < "Never underestimate man's potential for stupidity" > < -Woodrow Wilson Smith > ------------------------------ Date: Wed, 02 Oct 91 21:21:01 SST From: "S. Suthipuntha" Subject: PEOPLE DUMPING MACHINES... To: INFO-ATARI16@naucse.cse.nau.edu A close look at the NeXT motherboard I saw a SIM socket not unlike a ~~~~~~~~~~ socket for the SIM ROM on the Mac IICi. Thus I guess that they probably ~~~~~ use 512K 'clean 32-BIT' SIM ROM or at least the 256K Mac SE30 SIM ROMs. How these SIM ROM can be obtained is yet remain to be seen. Just to clearify these 2 points. These SIM socket on NeXT motherboard is an empty socket of extra SIM not the NeXT OS ROMs. they refer to those who are now writing the Mac Emulator at MIT not the NeXT ~~~~ computer. I am wondering when Dave Small's will start worrking on the Spectre 256. Bye, S. Suthipuntha, School of Architecture, National University of Singapore AKISUJAR@NUSVM.BITNET ------------------------------ Date: 2 Oct 91 11:36:26 GMT From: mcsun!uknet!ukc!bcc.ac.uk!ucacmsu@uunet.uu.net (Mr Stephen R Usher) Subject: Populous / Powermonger To: Info-Atari16@naucse.cse.nau.edu 1) Yes Populous does work on the STe (and on the TT if you turn off the sound within the game as soon as it starts). 2) I don't know. Steve Addresses:- JANET ucacmsu@uk.ac.ucl or ford@tharr.uucp@uk.ac.uknet Internet ucacmsu@ucl.ac.uk or ford@tharr.uucp@uknet.ac.uk ------------------------------ Date: 1 Oct 91 16:02:12 GMT From: noao!ncar!asuvax!cs.utexas.edu!wupost!micro-heart-of-gold.mit.edu!bloom-beacon! eru!hagbard!sunic!chalmers.se!dtek.chalmers.se!dxper@arizona.edu (Per Anders Olausson) Subject: Railroad Tycoon Needs File To: Info-Atari16@naucse.cse.nau.edu seattle@triton.unm.edu (David G. Adams) writes: >I just recieved Railroad Tycoon from Sideline Software (Friday to be exact). >Problem. The install program choked when it couldn't find the file named >COLOUR.LBM. I talked to Sideline (They're not at fault in anyway) and the >representative said he had the file and I'd need to mail him my disks so he >could copy the file to them and mail them back. Big long time spent in >transit over the country (Albuquerque to Ft. Lauderdale and back). I, too, experienced this problem when trying to run it on a hard disk. In order to fix this I just copied first disk one and then disk two to the directory on the hard disk. When doing disk 2 it asked me if I wanted to overwrite the files present (which came from disk one) and this I did. Naturally you wonder if the dupes on the disk were important but I've been playing the game for a week now and it didn't seem to do any harm. pao -- .............................Andrew Olausson................................ ............................Systems Architect............................... ..........................dxper@dtek.chalmers.se............................ ..............................pao@proxxi.se................................. ------------------------------ Date: 1 Oct 91 16:06:35 GMT From: noao!ncar!asuvax!cs.utexas.edu!wupost!micro-heart-of-gold.mit.edu!bloom-beacon! eru!hagbard!sunic!chalmers.se!dtek.chalmers.se!dxper@arizona.edu (Per Anders Olausson) Subject: Railroad Tycoon Needs File To: Info-Atari16@naucse.cse.nau.edu Roger.Sheppard@actrix.gen.nz (Roger Sheppard) writes: >But the chap that wrote the article in ST-Report suggests that all >owners of Railroad Tycoon send there disks back and ask for there >money back, he states that there are far to many Bugs in ST the port >of this game.. There is a lot of bugs present when you have lost a game etc but I still haven't found myself trapped when *in* the game. In other words I don't think the external bugs have any counterparts when running the game itself. It sure is the first buggy Microphrose game I've owned anyway and I don't like it at all, they used to produce stuff that were better tested than this. pao -- .............................Andrew Olausson................................ ............................Systems Architect............................... ..........................dxper@dtek.chalmers.se............................ ..............................pao@proxxi.se................................. ------------------------------ Date: 2 Oct 91 08:14:56 GMT From: noao!asuvax!cs.utexas.edu!swrinde!elroy.jpl.nasa.gov!news.claremont.edu!jarthur .claremont.edu!dcrevier@arizona.edu (Dan Crevier) Subject: SLM804 laser printer To: Info-Atari16@naucse.cse.nau.edu I recently got a SLM804 Atari laser printer, and I have a few questions. 1. Using Pagestream 1.8 (I don't have the money to upgrade at the present), I cannot get it to print with the DMA version, but the other version using the Diablo emulator works. However, selecting manual feed does not seem to have any effect. I have used the manual feed in Ultrascript sucessfully, so I know it is a problem in the SLM drivers in Pagestream, not something I am doing wrong. I can always output the files into a disk file as postscript and then print them out with Ultrascript, but it would be much more convenient to print directly. Does anyone know if there is a newer SLM printer driver for pagestream? Mine say beta version. 2. I purchased Ultrascript, and it has a folder called NUFONTS that contains files with extensions .QFM and .OTL. It never mentions the existance of this folder, or of these file types in the manual? What are they? Also, does Ultrascript replace Tymes-Roman with Lucida normally? If not, can it be made to? Thanks Dan ------------------------------ Date: 2 Oct 91 19:19:01 GMT From: aahs.no!data3d@ucbvax.berkeley.edu (Karl Anders 0ygard) Subject: Spectre GCR/System 7/A/UX To: Info-Atari16@naucse.cse.nau.edu 1 simple question: Does Spectre run System 7 and A/UX? Karl Anders Oygard - Karl A Oygard ------------------------------ End of Info-Atari16 Digest ******************************