Info-Atari16 Digest Sun, 29 Sep 91 Volume 91 : Issue 515 Today's Topics: ARJ? K.I.S.S.! Is Maple still available? lharc 2.01e vs zoo 2.1: some tests (3 msgs) Oh boy, more Atari bashing... PEOPLE DUMPING THEIR MACHINE.... Sozobon > 1.2 WANTED: chart/broker program 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: 28 Sep 91 16:46:50 GMT From: noao!asuvax!cs.utexas.edu!convex!rosenkra@arizona.edu (William Rosenkranz) Subject: ARJ? K.I.S.S.! To: Info-Atari16@naucse.cse.nau.edu In article <3089@atari.UUCP> kbad@atari.UUCP (Ken Badertscher) writes: >rosenkra@convex.com (William Rosenkranz) writes: >True. The problem I have with the archiver situation in the TOS world, >though, is that so darned many of them exist. TOS versions of Arc have >long been surpassed in performance by more efficient compressors. Yet >a lot of the archives I see on BBS's and elsewhere are still ARC format. >I find LZH situation depressing. I personally have had little luck >getting a single LZH tool that would deal with the variety of LZH >formats out there. i am glad to see a semi-official position on this, ken! i have added respect for you (and your company :-). but then you _knew_ i would say that :-). like it or not, ARC is far more universal than anything else. EVERYONE has a copy of it. it has been around forever, it seems. i know i used it in 1985 and it probably goes back at least a dozen years. the "fortran of archivers": no matter how you try, you just can't get away from it :-). >This is why I was happy to see ZOO version 2.1 appear, with its high- >performance option that beats or matches LZH compression. The main >reason I like zoo is for its superior directory handling and "novice" >command set. exactly. the best of all worlds: easy for experts, easy for novices. feature-rich. high performance. the best thing since...never mind :-). >Having ARJ available will be even better. After using it under DOS, it >became apparent to me that it merges all the best features of the >different archivers I've used. Its compression is phenomenal (you want >fast? ARJ does fast... you want tiny? you can get that too; slower, >but not unreasonably so). It has a complete set of options for handling >directories and for creating self-extracting archives, split-volume >archives, etc. ad inf. i, too, look forward to ARJ. i don't particulary love zoo, tho i definitly like it more than lharc for the reasons u mentioned as well. however, i forsee the same problem with ARJ as lharc: lot's of people porting it, and worse, _changing_ file formats and compression schemes. the only possible salvation would be for Atari Corp. to step up and either do the port or sanction the port. this body here is far to democratic when (in this case) totalitarianism is needed. i realize this poses significant problems, however, not the least of which could be legalities. i do have faith that in a race, if ARJ is POSIX compliant, anyone using GNU C would win, and would _certainly_ beat a port to assembler :-). >Because the compression beats the competition (and after all, that's >the bottom line in archivers, no?), people will likely latch onto it. no, it is NOT. it is portablility _and_ speed/size/etc, in that order. i think we have a rare opportunity here: actually _plan_ the introduction of a potentially widely used piece of publically available code. "think of the colors...:-)". >If, as an added bonus, it has a user-friendly face, more people will >want to look at it. If it's the best archiver in terms of compression >vs. speed tradeoffs, and flexibility in file handling, it'd sure be >nice if it were also the best in terms of ease of use. agreed. >Also, while it's true that programs bloat a bit when GEM features are >added, the rewards are worth the few extra K of disk space consumed. agreed. i have no problem with GEM-izing anything as long as it is done with care. that means it should NOT effect non-GEM use, its original purpose in the first place. >The extra effort can make a program useful to thousands more people. As >an example, wiring a non-trivial GEM UI into MicroEMACS costs adds only >about 20K of disk space to a 100K or so program. That 20% increase in >size makes the program much, much easier to use (in my experience, and >in the experience of EMACS users, both novice and pros, on whom I >foisted the bug-ridden hack :). not THIS emacs user. i rarely use the mouse in ME. i have no mouse at work with gnuemacs. even when i did, i didn't use it. the trouble with relying on special features is when they are not available, you can't function. i tell this to people at work when the extole the virutes of X terminals over my arcane vt100 clone. i casually mention a common scenario: go to do some work at a customer site who does NOT have any X terminals for you to use. double presure: customer watching+can't use tools u know=much egg on face :-). oh, and as bammi pointed out, i,too, may have made a significant error in my code example that checks the number of args to decide which main to use. if i said "if (argc < 1) do_gem()" i _really_ meant "if (argc < 2) do_gem()". i would not suggest using my example anyway since i can no longer claim expertise in GEM programming. it has been years since i wrote GEM code, tho when i did, i wrote a LOT of it (a 60,000 line application for starters...). the idea, however, should be ok. thanx for your comments, ken... -bill rosenkra@convex.com -- Bill Rosenkranz |UUCP: {uunet,texsun}!convex!rosenkra Convex Computer Corp. |ARPA: rosenkra@convex.com ------------------------------ Date: 28 Sep 91 16:44:05 GMT From: noao!asuvax!cs.utexas.edu!samsung!noose.ecn.purdue.edu!vivaldi.ecn.purdue.edu!y egerleh@arizona.edu (James D Yegerlehner) Subject: Is Maple still available? To: Info-Atari16@naucse.cse.nau.edu Hello Everyone, Once a long time ago someone in Canada posted that he had bought "Maple" for his ST at a school bookstore. I have never seen this program advertised for the ST; does anyone know if it is still available? Is it a full GEM implementation? As I understand it, Maple is a math program like Mathematica that does symbolic and numeric manipulations (as against something like Mathcad which is entirely numeric). Any comments are welcome, Jim -- __ __ | | \ / __ __ __ __ | __ |__ __ __ __ Jim Yegerlehner \/ |--'| ||--'| ||--'| || ||--'| 1132 Hawkins Graduate House | `-- `--|`-- | |`-- | || |`-- | W. Lafayette IN 47906 ------------------------------ Date: 28 Sep 91 15:18:37 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 mforget@ersys.edmonton.ab.ca (Michel Forget) writes: >I can't be positive about this, but I am fairly sure. Gulam uses the >Mark Williams C Extended Argument Passing system, which is close to the >system that ARGV uses. It *ISN'T* ARGV though, so that may be why Gulam >crashes. gulam _does_ use the MW scheme and it is close to the ARGV spec endorsed by atari. however, the fact that zoo worked and lharc did not means that the port of zoo was designed for use by the desktop and in shells like gulam. lharc was appearently not tested before it was released the way i did. you cannot disguise the fact that it DID crash my machine as configured. and there were not TSR/DA problems (i only use AHDI, FOLDRXXX, and a ramdisk and no DAs, not even control panel, and no funky hardware setup). zoo was compiled with GNU C 1.40 which has a nearly-POSIX compliant library. the gnu library has been painstakingly worked on by a number of people (bammi, dale schumaker, eric smith, etc), quite a collection of ST talent. it has also been well tested in a number of environments, including gulam, desktop, bash, MiNT, etc. it may not be 100% bug free, but then neither is TOS itself. and it gets updated more often :-). part of the test was to dispell the notion that to get decent performance you _must_ code in assembler. this is just not true (in this case). the optimizer in gcc seems to work pretty well. again a tribute to 1) the FSF (stallman et al), 2) bammi's port, 3) the C language itself. in fact, i'd say that using any compiler that has a solid runtime library is infinitely preferable over using one that does not and writing your own, no matter what the possible difference in performance might be. in gcc's case, it just so happens you get both: performance and portability. > Okami supports ARGV Parameter Passing, if you can figure it >out. I can't read German, so it hasn't been the easiest method to >use...:) i do not have okami, tho i hear it is quite good. i never said gulam was the greatest thing, tho a) it has been around for a long time, b) it is widely used by CLI types like myself. the fact that lharc does not work and play well with gulam IMHO makes it problematic because of the number of people it may effect. i can't read german any more either :-(. from this point on, i defer all comments about ARGV to experts in this matter. i am not. however, as i used the programs, within my particular environment, lharc crashed. and i clearly identified "my environment". the crash was totally unexpected as well. in fact, i lost some things in my ramdisk as a result :-(. if i have to, i _will_ read the complete ARGV spec, the docs regarding env_style mw in gulam, and the source for crt0.c and main.c in GNU C and _become_ an expert. however, this will still not make lharc work correctly with gulam. and the timestamp issue has nothing to do with gulam anyway. changing a file's timestamp is done with the GEMDOS Fdatime() function. if i had the source to lharc, i could track this down. >Lharc 2.01E works fairly well. it _does_ work _fairly_ well. just not as well as zoo IMHO. and i still have not heard about its failure to get the dates correct on unpacking, no matter how many times i read its manual. >these problems. All in all, though, Thomas Quester's programs are some >of the best available for the ST. Especially PFX Pack and AFX Pack. no dispute here. i _really_like_ PFX and i will even register it if thomas sends me the source so i don't have to disassemble it myself. i want the source before i use it because i want source to _any_ archiving system i might use. i figure it would take at _least_ an hour of time to disassemble it (correctly) and annotate it. it would easily be worth the $10-20 (or whatever) nominal registration fee. >I'll check to see how well Lharc 2.01E supports ARGV, but if the author >says it is supported it is a good bet that it is. please do check and let us know. it might support ARGV, but it does not support ARGV in a gulam environment. it should. zoo does. >I also read the >article containing the test, and it did seem very biased toward ZOO. The >writer perhaps should have read the documentation before complaining >about the program not being able to do certain things. The actual ok, i admit it. when i started the test, i was biased by the fact that lharc has had a bad reputation. but i _honestly_ did not know: 1) relative compression speeds 2) relative decompression speeds 3) relative archive sizes 4) bugs (tho i did suspect the timestamp problem) and i would have posted the test results even if lharc had beat the pants off of zoo. i truly did try and be objective by choosing unbiased tests, i.e. the sorts of things i think many people use archivers to do. you can either believe this or not. that is certainly your prerogative. further, i reported what i found. if you find bits and pieces of the report which indicate _extreme_ bias, it could just as easily be _your_ bias as well. however, the numbers (times, sizes, timestamps) do not lie nor did my dead ST after the "lharc a xxx *" test. the only possible bias could be in how i actually _used_ the programs, and the specific tests which i admitted (several times) where not exhaustive. i even complimented TQ on providing the best lharc on the ST. i could have easily wrote a report that said: 1) compression rates are similar, within 1% 2) archive creation time is similar, within %15 3) archive extraction time is nearly identical, though zoo was faster in one isolated instance 4) lharc could not unpack files and keep the same timestamp as the file in the archive 5) lharc crashed the computer (and describe the circumstances) i provided additional commentary which i thought would be percieved as reasonably fair by reasonable people. and i provided voluminous raw data by which you could draw your own conclusions, if need be. and you are certainly free to do your own (biased or unbiased) tests and report the results. even a terse report could be percieved as biased. so make up your own mind using your own tests. i even pointed out further tests which i thought were needed. i just can't see how this is _very_biased_. i could read until my eyes fall out of my head. it still won't stop the problems i mentioned. nor will it run faster nor will it make smaller archives. if the solution to the ARGV crash it to get another shell, this is _unacceptable_. perhaps you could show me how to get around the timestamp problem and the crash problem after reading the docs. i did skim them (after the report) and found nothing to indicate a way to correct the timestamp problem. i can probably work around the ARGV thing. but that is again not the issue. the code has bugs. PERIOD. and if the source were posted, we could help TQ find these bugs and fix them. i checked the original copyright notice from yoshi (original author of lharc). it explicitly states that if modifications to the source code are made, they MUST be distributed. even if that modification is changing C to assembler. if i wanted to be nasty, i'd say TQ has violated the terms of Yoshi's copyright by NOT providing source. >compression rates seemed fairly even, whih is a good thing. The next >sries of compression programs will all be trying to beat each other, so >we might see even better compression routines. There has to be a limit >on how good compression can be though... yes, the compression rates _are_ similar, as are the compression times and decompression times. similar enough to abandon lharc in favor of a more versatile, less buggy zoo... thanx for your comments. -bill rosenkra@convex.com -- Bill Rosenkranz |UUCP: {uunet,texsun}!convex!rosenkra Convex Computer Corp. |ARPA: rosenkra@convex.com ------------------------------ Date: 28 Sep 91 16:08:41 GMT From: noao!asuvax!cs.utexas.edu!sun-barr!cronkite.Central.Sun.COM!spdev!texsun!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 <1991Sep28.132241.17704@actrix.gen.nz> Roger.Sheppard@actrix.gen.nz (Roger Sheppard) writes: >One thing you did not test with both Archivers was full i/o, did you >not state that ZOO 2.1 has a problem with Disk i/o,? >if this is the case then none of your tests are valid. yes, i know this, and i mentioned this right up front. the problem with disk-based io is that it can be extremely hard to duplicate a test environment. i/o rates on nearly full partitions, especially highly fragmented ones, can be greatly different than on empty partitions. then there is also the issue of drive seek rates, interleaving, etc. a "proper" test would take this into account and further report the _EXACT_ configuration down to the size of sectors, fragmentation, etc. unfortunately, people rarely go thru this much trouble. i tried to side-step the issue by insuring at least an equal playing field. the comparison should be unbiased for the use of these programs in ramdisks. it does not, as you correctly point out, say anything about use on floppies or harddisks. however, i suspect that zoo (the GNU C version) would be rather efficient. bill shroka (who did the zoo port) confirmed the change in buffer size (which i also applied on my unix version) which significantly improved its speed. also, the GNU C i/o routines in my experience are at least as efficient as any other C compiler i have used on the ST (alcyon and sozobon). i say "at least" since the gcc stdio is derived from dlibs (i think) which is the prefered library for sozobon as well. bill further explained that zoo was ported in about an hour. the buffer size change is one line in one file. how long did it take TQ to port lharc from C to assembler? i would suspect considerably more than an hour. what i would suggest is that GNU C be tried on the ST on the original lharc C (only) sources. i would even except lharc if this was done in the first place way back when, before everyone and his brother got in the "let's port lharc to the ST" game. >I think that it would be far better if some one had done these test, >that was not that biased, you new of the new features in zoo 2.1, but >you did not bother to find out about any new features of LZH201X.. ok. i invite you to replicate this or perform your own. i really don't think it matters who does the test. in fact, i'll even offer to do whatever test you feel is necessary, within reason. you tell me the configuration, environment, command switches, etc. you want. i can't guarantee i will have the same hardware, however. the only restriction is that i use my own choice of zoo, which i will document explicitly by sending you the source, makefiles, even the frigging compiler! _what_ new features? did i use lharc incorrectly? there are only so many ways to pack an archive and i insured that lharc used it's highest packing algorithm, lh5. this happens to be the default. and still, i wish you would point out in the documentation where it shows how to unpack files from an archive and preserve the timestamp. i did not find it in my docs. nor did i find any mention of alternate methods to improve speed or packing ratio. please direct my eyes to the proper citation... >As far as ZOO is concerned, I find that ZOO is used on only >about 2-5% of the PD files that I get. i, however, find it is more like 60-70%. all GNU-derived software on the ST is packed with zoo. most comp.binaries.ibm.pc stuff is packed with zoo. once again you are telling us that just because you don't need it, none of the rest of need it either. >Also I have never made a ZOO archive, I had so many problems with >eXtracting ZOO archive that I don't use it as a archiver at all, there >are too many switches to understand, unless you have a Computer Science >Degree, so far from what I can see only used by Unix Freeks, they like >wearing key boards out..:-).. i did invite name calling, didn't i :-)... i have not had any problems with zoo (except porting it to a cray-2 :-). and "unix freeks" like being productive. that often means using our fingers on keyboards. for your information, there are about as many switches with lharc as with zoo (if _you_ read the docs :-). zoo also has "novice" switches. here is a summary of common ones: zoo -add archive files... add individual files to new/old arch zoo -backup archive directory recusive add zoo -extract archive extract all files from archive zoo -restore archive extract recursive zoo -list archive list files in archive zoo -test archive test files in archive is this _that_ difficult to comprehend? in fact i suspect the only ones you really need are -backup, -restore, -list, and -test for 99% of your needs. i think with little effort, i could teach my 3 year old nephew these few commands, if i could explain what an archive was to him :-). and last time i checked, he was bright, but had no CS degree :-). neither do i for that matter. the switches are _highly_ mnemonic. they are words for crissakes. this only poses a problem if you don't grok english. in that case you can resort to their equivalents: zoo a archive files... zoo a// archive directory zoo x archive zoo x//. archive etc... zoo has the added benefit of trying to extract files from damaged archives. i know of no such capability with lharc, tho i am willing to learn of one. -bill rosenkra@convex.com defender of the faith... (by the way, "grok" is not a unix command :-) -- Bill Rosenkranz |UUCP: {uunet,texsun}!convex!rosenkra Convex Computer Corp. |ARPA: rosenkra@convex.com ------------------------------ Date: 28 Sep 91 14:51:35 GMT From: noao!asuvax!cs.utexas.edu!wupost!zaphod.mps.ohio-state.edu!magnus.acs.ohio-stat e.edu!usenet.ins.cwru.edu!ncoast!bjsjr@arizona.edu (Bill Shroka) Subject: lharc 2.01e vs zoo 2.1: some tests To: Info-Atari16@naucse.cse.nau.edu In article jhenders@jonh.wimsey.bc.ca writes: >In <1991Sep26.064525.15427@convex.com>, William Rosenkranz writes: >> > < extensive zoo vs lharc test deleted > > > Thanks for an excellant test article. The only real world test you >missed was extraction of existing archives, where lharc is a considerable >improvement over it's predecesors. I'm sure zoo rates highly there too. > My one big gripe with zoo is that it breaks multiarc, a nice muli >archiver shell I discovered shortly before zoo 2.1's release. With the old >version of zoo, the command x// extracted all files recursively too >folders, now the only command that does this is -extract, which doesn't >fit on the multiacr command line. ( one problem with Gem dialogs is that >the programmer must anticipate the maximum length of any command ever to >be used. If he underestimates, something always comes along that is too >long. Another good example is Gus, which truncates long subject lines.) > Is my version of zoo broken, or is there a switch that I missed? > >-- > John Henders jhenders@jonh.wimsey.bc.ca > Vancouver,B.C or ubc.cs!van-bc!jonh!jhenders Zoo 2.1 defaults to extracting subdirectories. If you have an archive that contains pathnames in the archive entries, then any of the following commands will extract the full pathnames: zoo x foo.zoo zoo x// foo.zoo zoo -extract foo.zoo zoo -restore foo.zoo <- Atari ST version only zoo e foo.zoo zoo e// foo.zoo If the version of Zoo you have doesn't follow these rules, then you must not have the version that was posted to comp.[binaries/sources].atari.st. -- -------------------------------------------------------------------------- Bill Shroka bjsjr@NCoast.ORG uunet!usenet.INS.CWRU.Edu!ncoast!bjsjr ------------------------------ Date: 29 SEP 91 10:06:10 CDT From: Z4648252 Subject: Oh boy, more Atari bashing... To: Is there any possibility of an address being established so that posters such as Richard E. Covert can go and rake Atari over the coals, where these guys can scratch each other's backs as they siren the fact how much better other systems are than Atari? First, we had to put with the Amigoids coming here, telling us how to 'upgrade' to an Amiga and now Mr. Covert comes in, bashing the Atari laser (I always thought it was pretty fast, especially compared to the lasers in the Mac world). And now the guy is telling how sorry the Stacy was since it "never passed FCC Type C testing." For starters, there is no such thing as Type C approval for computers such as the Atari. Type A, and also Type B, but no Type C. Please, Mr. Covert, go to the Mac area and praise the Mac world there. Enjoy the amazingly expensive software and poor support by Mac software companies. Larry Rymal |>Atari ST Users of East Texas<| Stephen F. Austin State University, Nacogdoches, Texas ------------------------------ Date: Sun, 29 Sep 91 20:16:23 SST From: "S. Suthipuntha" Subject: PEOPLE DUMPING THEIR MACHINE.... To: INFO-ATARI16@naucse.cse.nau.edu Hello from Singapore, I normally prefer to read rather than writing a long message as it has to travel half round the world but I could not resist this time. In article <1991Sep27> Richard Covert writes: >So, if I get a Mac iici for $4000 ($3300 for a IIci with 5 mgs RAM, 105mg >hd) + $600 for color monitor/video board + $150 for keyboard I can use >my Sony SMO optical drive with it for free. then I can put AUX on my optical drive and run MAc off of my hard drive and off of the optical. >And for less than a TT030 with ATX would cost. The TT030 ATX package >.is going to cost $2,000 from what I hear. Has anybody ever check how much Apple charge for A/UX? I bought a Mac IICi since December '89 and then fitted with 5MB RAM and 105 Quantum hard disk. I still keep and using my 16 MHz Atari Mega4/Spectre (Both are on the same desk and Mac also sharing the Megafile 44 with Mega4). I bought Mac IICi to run color program such as Renderman, Strata Vision, Mac Architrion, which do not work on Spectre/Mega4. However other B & W Mac programs such as MiniCad+, MGM Station run as fast on my 16MHz Mega4 as when I run on Mac IICi in it 256 color mode. (Of course in B&W mode Ci will be faster). Although the total cost of my Mac IICi is still cheaper than the cost of Mac Architrion(which cost US$6800 here) I sold my Mac IICi 2 weeks ago (at the same price I pay for under AUC) after discovered how much I would have to spend if I going to buy Cache RAM card to speed up the color display and/or A/UX (the cheapest disk version is US$1320 here) and if I get the ethenet card big screen monitor+24-BIT card and struggle with a single button mouse while running UNIX (which needs 3 button mouse) on my Mac IICi. The total added-on cost including the cost of Mac IICi will be more than what I can buy a Silicon Graphics IRIS INDIGO which is a RISC workstation running at 30MIPS, comes with cache RAM, Virtual 24-bit graphics, 16" Sony Trinitron monitor, Ethernet, stereo sound build- in plus free UNIX and Showcase programs in spite of Silicon Graphics only give 30% educational discount comparing to 35% AUC prices here. NeXT Station Color also cheaper than Mac IICi with A/UX and it has 16-BIT color, Ethernet come with 17" Color Monitor, 2.88MB disk drive, UNIX and enough bundled softwares and using the 68040 CPU which will be used in the new Mac Quadra which will be released on October 21st. I am now waiting to see the new Mac Quadra before making final decision. I am very relieve to be able to get rid of my Mac IICi before its price will come down drastically when Apple released 6 new computers next month. I also feel good to have an opportunity to shop for a new computer again and enjoy using my Mega4/Spectre more than ever. What I would like to have are the Mac and Atari emulators for IRIS or NeXT. Anyone keens to write the emulators for these 2 machine? It would be nice if Dave Small will do it but I guess he is now too busy with his SST. Wonder why Atari never offer an educational discount though? It may be too late now anyway. Suthipuntha, School of Architecture, National University of Singapore AKISUJAR@NUSVM.BITNET ------------------------------ Date: 28 Sep 91 16:51:34 GMT From: noao!asuvax!cs.utexas.edu!qt.cs.utexas.edu!zaphod.mps.ohio-state.edu!rpi!news-s erver.csri.toronto.edu!bonnie.concordia.ca!daily-planet.concordia.ca!agostino@a rizona.edu (Agostino Deligia) Subject: Sozobon > 1.2 To: Info-Atari16@naucse.cse.nau.edu Hi, Anyone on the net know when the next version ( > 1.2 ) of Sozobon will be released? Someone mentioned a couple of weeks ago that it was going to be released in a couple of weeks :~) but nothing has shown up in comp.binaries.atari.st or atari.archive.umich.edu. Thanx for any info, ad -- Agostino Deligia agostino@concour.cs.concordia.ca It was the best of .sigs, it was the worst of .sigs... ------------------------------ Date: 28 Sep 91 18:50:38 GMT From: noao!ncar!elroy.jpl.nasa.gov!sdd.hp.com!think.com!snorkelwacker.mit.edu!ira.uka .de!fauern!faui43.informatik.uni-erlangen.de!lsmichae@arizona.edu (Lars Michael) Subject: WANTED: chart/broker program To: Info-Atari16@naucse.cse.nau.edu Hi folks, I need a program to visualize broker charts. Monochrome would be the best. I've scanned the atari.archive, but nothing found. Anything is welcome, --- Larry +----------------------------------------+----------------------------------+ | lsmichae@faui43.uni-erlangen.de | | | | | | Lars "Mr. GIF" Michael | | | | "Down with ATARI, | | Graduate Student of Computer Science | / | \ Long live the ST !" | | at University of Erlangen/Germany | / | \ | +----------------------------------------+----------------------------------| | Bones: "Damn it, Kirk, I'm a doctor, not a very good actor." | +---------------------------------------------------------------------------+ ------------------------------ End of Info-Atari16 Digest ******************************