Info-Atari16 Digest Sat, 5 Oct 91 Volume 91 : Issue 525 Today's Topics: ARJ? (3 msgs) For Sale : Help!?! Install an app for two diff filetype KR2ANSI lharc vs. zoo (my correction) Need disk cat prog. to show disk files & sizes, ask comments People dumping machines (was.. Atari Mega 2 system.. for sale) (3 msgs) Railroad Tycoon Needs File SOME (HOPEFULLY NOT REDUNDANT) INFO ON OTHER MAC EMULATOR (LONG!! Spectre GCR/System 7/A/UX Using gcc/g++ to cross compile for the ST WANTED: Suggestions for ST color monitor purchase 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 20:45:04 GMT From: mcsun!unido!mcshh!malihh!pfunk!blackbox@uunet.uu.net (Michael Kistenmacher) Subject: ARJ? To: Info-Atari16@naucse.cse.nau.edu In <1991Oct01.144917.1607@convex.com>, William Rosenkranz writes: >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 I pay high respect to your attitude, above all if I look on the products, you have added to the PD-section on the ATARI. But you have to realize that some people have to pay their rent with that money. Thomas is a student and his university demand a high contribution. I don't know anything about your profession but some people must earn money with their products. > >requesting the source, in this case, will save me the time of disassembling >it, correcting the disassembled source, reformatting it, and annotating If all people would thing think like that and every part of software would be free of charge, we would not have so much professional software for our computer. This might sound a bit fancy, but if I make a list of professional products for the ST, the amount of them from germany would perhaps be higher.(please don't get that wrong) >i would not disassemble a spreadsheet, database, or any other sort of program. >but for me, archivers are different. > But where do you make the difference ? OK, some hours against some weeks. Bye......Michael -- /------------------------------------\ | Michael Kistenmacher / blackbox | | 2000 Hamburg 61 / Schippelsweg 64 | | West Germany / ++ 49 40 552 37 66 | \------------------------------------/ ------------------------------ Date: 3 Oct 91 07:52:17 GMT From: mcsun!uknet!ukc!edcastle!hwcs!neil@uunet.uu.net (Neil Forsyth) Subject: ARJ? To: Info-Atari16@naucse.cse.nau.edu In article <1991Oct1.212652.15376@watdragon.waterloo.edu> cjherborth@rose.waterloo.edu (Chris Herborth) writes: >a) What's the problem with Malloc() inside an ACC? Beyond the possibility > of fragmenting your memeory, I can't imagine anything going wrong... Like I said, when you malloc memory from an acc, the memory belongs to the current process not the accessory. So if you are in an application when you malloc some memory, you'll lose it when that application terminates. The desktop doesn't terminate so you should do your mallocing then. I'm not sure about rez changes though. Perhaps the desktop 'quits' then. I guess you'd have to catch that. >The main point is, it's to be an EXTENSIBLE Screen Saver. You could have >2M of modules sitting in your XScreen folder (well, if it caught on and >lots of people wrote modules) and you wouldn't want to load them all when >you booted. You'd just want to load the one that was going to be >executed when the screen saver went off. When you were done (ie, work your >ST back up), it'd get deallocated. What I described was an EXTENSIBLE system. You might have to reserve memory for saver slots in advance though. >There's another problem --> I haven't got the assembler smarts to write >any sort of code that'll relocate and execure a module the way you >suggest, with a special header/whatnot. I can't even use XBRA without >the routines somebody else wrote and uploaded to a.a... Well you are going to have to learn about assembler anyway to write the saver in the first place. BTW I'm getting all this stuff in reverse so I'm replying without having seen Ken's message yet. No doubt I've made some more screw-ups! :-) +----------------------------------------------------------------------------+ ! DISCLAIMER:Unless otherwise stated, the above comments are entirely my own ! ! ! ! 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 "That was never 5 minutes!" ! +----------------------------------------------------------------------------+ ------------------------------ Date: 2 Oct 91 23:01:35 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: ARJ? To: Info-Atari16@naucse.cse.nau.edu You don't want to malloc in a desk acc inside a application, because once you are closed, anyone else can use that memory. A easy Idea, might be to make savers written in some type of interpred language,or script. If you distribute an interpreter with it, litera ly anyone can make up their own saver... To be really simple, the 'language' could just be an animation format... ------- < Joshua Kronengold > < "Oh Lord, what fools these mortals be!"-Robin Goodfellow > < "Never underestimate man's potential for stupidity" > < -Woodrow Wilson Smith > ------------------------------ Date: 3 Oct 91 00:49:34 GMT From: noao!asuvax!cs.utexas.edu!qt.cs.utexas.edu!yale.edu!ox.com!math.fu-berlin.de!fu b!dobag.in-berlin.de!obh.in-berlin.de!tyrell@arizona.edu (Stefan Haack) Subject: For Sale : To: Info-Atari16@naucse.cse.nau.edu For Sale : ATARI 'TETRA-TOWER' -Atari Mega ST 4 Board 4MB -AT-Speed C 16 (16Mhz) (MS-DOS Emulator) -Hypercash 16Mhz -Overscan -all Tetra Tool's(Printer, I/O, SCSI, LAN) -177 MB Seagate Harddisk (14ms 64KB Cache) -44 MB Syquest SQ44 -3 1/2 Disk -5 1/4 Disk -NEC 3D Multisync -ATARI SLM804 -Calamus DestopPub. Program and another Programs VB 9500.- DM (Deutsche Mark) without Shipping ! ------------------------------------------------------------------------ Voice Germany 030/3235284 Q Rigo Manikofski or Stefan Haack or mail me ! tyrell@obh.in-berlin.de ------------------------------ Date: Sat, 05 Oct 91 16:19:13 MEZ From: Wolfgang Ley Subject: Help!?! To: Atari ST users forum On Fri, 4 Oct 1991 21:17:00 MST said: >Hello, folks! > >I am new to Bitnet and Internet, and need a little help, if you can spare >it. > >I am interested in doing anonymous ftp to get some atari st software. I >tried a couple of the addresses on the list that was sent out in >yesterday's digest, but I couldn't get past the login. Is there some kind >of universal guest account or something? > >Thanks in advance! > >*Mf* Hi! There is indeed a special account: 1) you should login as "anonymous" (most of the ftp-sites also understand the userid "ftp", but "anonymous" is the best way...) 2) send your userid as password. Most server accept the name "guest", but normally you should send your own userid. Some even want the complete mailing address as password (like BWWL@ibm.rz.tu-clausthal.de) This should work... I hope this helps. Bye, Wolfgang. (bye the way: the most important ftp-site for atari is atari.archive.umich.edu (141.211.164.8) ) --------------------------------------------------------------------------- Wolfgang Ley e-mail: Teichstrasse 9 from BITNET : BWWL@DCZTU1.BITNET W-3392 Clausthal-Zellerfeld from Internet: BWWL@ibm.rz.tu-clausthal.de (West Germany) or BWWL@sun.rz.tu-clausthal.de Tel. 05323/82132 (voice) --------------------------------------------------------------------------- ------------------------------ Date: 2 Oct 91 19:55:04 GMT From: noao!asuvax!cs.utexas.edu!qt.cs.utexas.edu!zaphod.mps.ohio-state.edu!van-bc!jon h!jhenders@arizona.edu (John Henders) Subject: Install an app for two diff filetype To: Info-Atari16@naucse.cse.nau.edu In <5551365@presto.ruhr.de>, David Channing writes: >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@ > This only works until the next time you save a desktop.inf file from the desktop. The desktop seems to ignore the extra lines when writing the file, at least when I tried it. The best solution is Gemini, where you can do something like *.[ALZ][RZO][CHO] in the instal application dialog. I'd sure like to have Gemini run from a ROM cart. -- John Henders jhenders@jonh.wimsey.bc.ca Vancouver,B.C or ubc.cs!van-bc!jonh!jhenders ------------------------------ Date: 3 Oct 91 05:55:56 GMT From: bu.edu!bucsf.bu.edu!harryk@uunet.uu.net (Harry Karayiannis) Subject: KR2ANSI To: Info-Atari16@naucse.cse.nau.edu I just put kr2ansi.zoo on atari.archive. kr2ansi is a small utility that generates ANSI prototypes from K&R-style C source files. Using output redirection one can generate header files (the program puts an "extern" in front of every prototype line) with prototypes of all the functions present in the file read...with the appropriate #include lines in the K&R source code old-fashioned programs can be compiled with an ANSI compiler (thus taking advantage of the parameter-checking during compilation). If there's enough interest I can also send it to c.b.a.s and c.s.a.s have fun... =============================================================================== Author of ATZENTA2 Harry Karayiannis ________E-Mail_________ 15 N.Beacon, #316 Boston Univ. |INTERnet: ** || ATARI ** Allston, MA 02134 Computer Sc. | harryk@bucsf.bu.edu ** /||\ MegaST ** U.S.A. |BITnet: =======================================================| cscrzcc@buacca.bu.edu ----------------------- ------------------------------ Date: 3 Oct 91 13:25:41 GMT From: noao!asuvax!cs.utexas.edu!qt.cs.utexas.edu!yale.edu!ira.uka.de!THD-News!news@ar izona.edu (WALLMANN, GEORG) Subject: lharc vs. zoo (my correction) To: Info-Atari16@naucse.cse.nau.edu 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. As to the fragmentation issue, I don't still quite see the problem (but who cares ? (har)) since after erasing the produced files, the fragmen- tation ought to be the same as before (the allocated blocks being freed). BTW. Since all archivers ran on the same partition from the same /bin directory I don't see this comparable to running one from a floppy and one from a ramdisk, not even in a more transcendental sense. Oh well Nat! ------------------------------ Date: 3 Oct 91 04:19:17 GMT From: noao!asuvax!cs.utexas.edu!samsung!mips!apple!netcomsv!bryanw@arizona.edu (Bryan Woodworth) Subject: Need disk cat prog. to show disk files & sizes, ask comments To: Info-Atari16@naucse.cse.nau.edu I am looking for a program that does the following: o catalogs filenames and filesizes according to disk #s o asks for comments o stores output in !! ASCII !! format. Any ideas? -- Bryan Woodworth Mail: bryanw@netcom.COM Netcom - Online Communication Services San Jose, CA ------------------------------ Date: 3 Oct 91 23:35:36 GMT From: noao!asuvax!cs.utexas.edu!usc!orion.oac.uci.edu!ucivax!bonnie.ics.uci.edu!jvanc e@arizona.edu (Joachim Vance) Subject: People dumping machines (was.. Atari Mega 2 system.. for sale) To: Info-Atari16@naucse.cse.nau.edu In article <1991Sep27.143553.27920@magnus.acs.ohio-state.edu> dhbutler@magnus.acs.ohio-state.edu (David Butler) writes: > One thing I have noticed about the computer world is that there are > a lot of real bone-heads in it, like as in thick skulls. Atari and > Amiga users are the WORST of the lot. Get off your high-horses guys, > you are arguing over a hunk of frigging silicone and some wires! > That's right, go home, look at your ST, and think about what it really > is, a lump of PLASTIC and METAL, and that is all, it has no > importance. GET A LIFE! Didn't you know? Computers are a bona fide social religion. Just like cars, beer and music. Computers, for some people, have as much to do with a person's self esteem and self image as clothing and hairstyle (or more so). What more to life is there anyway ;) -- Joachim Vance ===================================================================== I am antisesquipedalian--Opposed to the use of long words. ===================================================================== ------------------------------ Date: 3 Oct 91 23:45:15 GMT From: noao!asuvax!cs.utexas.edu!usc!orion.oac.uci.edu!ucivax!bonnie.ics.uci.edu!jvanc e@arizona.edu (Joachim Vance) Subject: People dumping machines (was.. Atari Mega 2 system.. for sale) To: Info-Atari16@naucse.cse.nau.edu > though, like I said, if the blitter can speed up bit-block transfers... My understanding is that the TT has no blitter. The '030 was too fast to justify one. Am I mistaken? Joachim -- Joachim Vance ===================================================================== I am antisesquipedalian--Opposed to the use of long words. ===================================================================== ------------------------------ Date: 4 Oct 91 00:41:46 GMT From: munnari.oz.au!bunyip.cc.uq.oz.au!uqcspe!cs.uq.oz.au!warwick@uunet.uu.net (Warwick Allison) Subject: People dumping machines (was.. Atari Mega 2 system.. for sale) To: Info-Atari16@naucse.cse.nau.edu In <28EBAB8B.5952@ics.uci.edu> jvance@bonnie.ics.uci.edu (Joachim Vance) writes: >> though, like I said, if the blitter can speed up bit-block transfers... > My understanding is that the TT has no blitter. The '030 was too fast >to justify one. Am I mistaken? That was my guess, from seeing the "Blitter" option greyed out (ie. disabled) on my friend's TT. It seems to me that if TurboST and QuickST can do better than the blitter (though I'm still not convinced), then certainly even the coders at Atari can do better with a 32MHz machine. Warwick. -- _-_|\ warwick@cs.uq.oz.au / * <-- Computer Science Department, \_.-._/ University of Queensland, v Brisbane, AUSTRALIA. ------------------------------ Date: 2 Oct 91 20:30:08 GMT From: noao!asuvax!cs.utexas.edu!qt.cs.utexas.edu!zaphod.mps.ohio-state.edu!van-bc!jon h!jhenders@arizona.edu (John Henders) Subject: Railroad Tycoon Needs File To: Info-Atari16@naucse.cse.nau.edu In <4990@chalmers.se>, Per Anders Olausson writes: > > 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. > F19, on North American TOS's had several annoying bugs, the worst of which was that you'd suddenly find yourself flying inverted. Not fun if you were 100 feet off the ground at 400 mph. ;-) After promising to fix this for several months, Microprose announced that they didn't consider North American sales significant enough to warrant the effort. While the bugs may not be a major problem on European TOS's, the early reports over here are that the game will barely run on most machines, some only work if you don't touch the mouse, and 4 meg machines are completely out of luck. It's too bad, as this game's release for the ST was one reason I put off purchasing a clone, as unlike Richard Covert, I consider the 386 boxes the current top games machine. -- John Henders jhenders@jonh.wimsey.bc.ca Vancouver,B.C or ubc.cs!van-bc!jonh!jhenders ------------------------------ Date: Sat, 05 Oct 91 03:02:45 SST From: "S. Ssuthipuntha" Subject: SOME (HOPEFULLY NOT REDUNDANT) INFO ON OTHER MAC EMULATOR (LONG!! To: INFO-ATARI16@naucse.cse.nau.edu Subject: Some (hopefully not redundant) Information Greeting from Singapore, * I am wondering why the mainframe here alway turns the Subject: line into uppercase! Contemplating to buy NeXT, I posted a message regarding the Mac Emulator to NEXT-L@BROWNVM.BITNET without much expectation as I so get use to getting zero response or help when I posted my queries here. To my surprise I received 4 replies within 6 hours after sending out my messages. Either the NeXT users are more enthusiastic about their computer than us, Atarians, or they are to free as they don't have to read the flaming which often occur in our discussion group. Perhaps the Ferrari owners (is it really a Ferrari?) or those who have an opportunity to drive/use without having to own one themselves could not be bother to spend their time debating or arguing whether the Toyota is better than Nissan. Below is some parts of the reply which I felt might be of interest to all who are using Spectre or waiting for Spectre 256 (a Color Mac Emulator). Suthipuntha, School of Architecture, National University of Singapore AKISUJAR@NUSVM.BITNET ------------------------------------------------------------------- Hello, I received the following from Abascus, the people working on a commercial Mac-emulator for the NeXT. The MIT effort has been halted because they don't see any point in duplicating Abascus' effort. Apparently, the MIT folks thought that Abascus is so far ahead of them that it wouldn't be worth their while to try to catch up anyways. Instead, they might try to work together. =================================================================== Greetings, Your presence at this conference implies an interest in open computing. At Abacus Research and Development, ARDI, we too are interested in open computing. Specifically we are interest in helping you run programs that are currently available only on Apple's(r) Macintosh (r) computer. We are a small start up with big goals. Information that you have asked for that isn't contained in one of those three missives is answered below. Q: Performance? A: Compute intensive applications blaze (the native 040 does all the work, we just stand back and let it rip). Graphics are slowed down by two things. ROMlib is written entirely in C so our graphics start out a bit slower than Apple's, on top of that we go through NeXTstep and that slows us down a bit more. I believe most people who have seen a demo are happy with the graphics. Some of our graphics tests run faster on a 040 NeXTstation than on a Mac IIci, some run slower. Q: What special hardware is needed. A: None. With the beta software you'll be able to stick 1.4M Mac formatted floppies into your drive and have the contents transferred to your hard disk for use under Executor. Q: Has Apple seen your work? A: At least one person from Apple stopped by at UNIX Open Solutions '91 (thanks to everyone who stopped by). I have also sent two demo copies to people within Apple and am about to send a third to Apple Europe. Q: Lawsuit? A: Who knows? No word of one yet. We're prepared for one. Q: Is the emulator at the source level or binary level? A: What we will be releasing, Executor, is a binary compatible "solution." We started this game with a source compatible solution, ROMlib. ROMlib was briefly offered for sale on the Sun-3 line for $400.00 for a one CPU copy. We sold a few but lost our shirts by spending much too much time explaining its use. Source compatibility systems are complex and it turns out there aren't a whole lot of people who are familiar with Mac programming and UNIX programming. We will re-offer ROMlib for ISVs, but the cost will be much greater and we can't do that until we've hired some support people which in turn is predicated on getting some funding or selling some copies of Executor. Q: Can I pass information about Executor and ROMlib to other groups? A: Please do. We've tried to keep a good balance between hype and reality; I hope you do as well. Today we do not have any shrink-wrapped products available for you to purchase. We are just about to send beta copies of what will be our first product. The "not quite beta" software can be shown running on a NeXTstation in our booth. Because this is a conference dedicated to open solutions, we are also running a in-house version that uses X-windows. The software that we are demonstrating is known as Executor and it allows you to take shrink-wrapped products originally written on a Macintosh and run them on non-Apple machines. The product line we will support is the NeXT product line. Emulating the Macintosh is no simple matter. When people clone IBM-PCs they have the cooperation of Microsoft. Microsoft wrote the operating system that runs on PCs and Microsoft is willing to sell copies to clone makers. Because Apple wrote the operating system that runs on Macintoshes, in order to be able to do what we do we had to rewrite the Macintosh operating system from scratch. Because this is such an enormous task, our first product will have some limitations. The first version will not support: Color, Sound, Printing, Desk Accessories, System 7, or AppleTalk(r). As we grow we will get rid of these limitations. We will also support other product lines. If you are interested in our technology but you already buy UNIX machines from someone other than NeXT, you may want to tell the company you deal with that you'd like to see our software running on their platforms. We could use the exposure. For the technically curious, here's a brief description of how Executor is put together. Executor is actually a very small program (approximately 3000 lines of C and assembly "glue") that uses a large library known as ROMlib. As the name implies, ROMlib is a library of routines that replaces those provided by the Macintosh ROMs. Although Executor has some assembly language portions, ROMlib is written entirely in C and at various times ROMlib has been brought up on a wide variety of machines, including: DECstations, VAXstations, SPARCstations, the IBM-PC running Xenix, Data General's Aviion, the IBM-RT as well as the machines we use in house, "Sun 3"s and NeXTstations. We originally hoped independent software vendors would use ROMlib to port their applications to the wide range of platforms that will support ROMlib, but there were concerns that ROMlib wouldn't be robust enough to handle complex applications. Executor was created both as a viable software product and as proof that ROMlib will work with complex programs. We hope you like what you see and that you'll pass on your knowledge of our company and projects to your colleagues and to the manufacturer that supplies you with open solutions. We welcome suggestions and are trying hard to grow as a company so that we can act on them. Most suggestions so far have been "Support Color," Support Printing." We will as soon as we can. When we release our first product it will certainly be less powerful than what everyone wants (a product that runs on all platforms, executes all programs written on a Macintosh and has no limitations with respect to Color, Printing, etc.). We humbly ask that you not buy our product until it does what you want. We don't want to disappoint anyone and sincerely believe that some people will benefit from our limited versions and it will be less of a hassle for each of us if you wait until we release what you really want before you become a customer. ExecutorDemo is distributed on a floppy disk as a NeXT package. You must be super-user to do the installation because ExecutorDemo must be installed as a set-uid root program so it can load in kernel Once ExecutorDemo has been installed you should be able to run the sample programs provided by starting up ExecutorDemo and selecting the application you wish to run and then either completing a double click or selecting the "OK" button. This document assumes you are already familiar with the Macintosh paradigm. The first release will run Microsoft Word 4.00D. Other programs may work; but you are on your own. The Microsoft Word "only" version will cost $80.00. When it is fully debugged, a version that supports all major applications, Color, and Sound will cost $700.00. The $80.00 version should be out in December 1991. It is too early to predict when the full featured version will be available. Qualification for other applications shall be forthcoming as an interim solution. people wouldn't believe our code would hold up with the heavy use of a major application. It does. 2) The legal implications. We'd get a better reception if we were selling flammable children's nightwear. I hope enough people were interested to justify this as a post rather than e-mail. I hope some comp.sys.next readers will see us at UNIX Open even though NeXT won't be there. Perhaps if enough show up we can go hit "Fondue Fred" in Berkeley. Thank you. Sincerely, Clifford T. Matthews President and founder Abacus Research and Development, Inc. It sounds like they still have much work to do on it, but seems to be well underway. I hope this helps. Suthipuntha, ------------------------------ Date: 3 Oct 91 14:00:20 GMT From: noao!asuvax!cs.utexas.edu!qt.cs.utexas.edu!zaphod.mps.ohio-state.edu!magnus.acs .ohio-state.edu!dhbutler@arizona.edu (David Butler) Subject: Spectre GCR/System 7/A/UX To: Info-Atari16@naucse.cse.nau.edu In article <"1028*.S=data3d.O=aahs.PRMD=uninett.ADMD=..C=no."@MHS> data3d@aahs. no (Karl Anders 0ygard) writes: >1 simple question: Does Spectre run System 7 and A/UX? > >Karl Anders Oygard - Karl A Oygard System 7 does not work as yet (and who wants it, have you used it? Man, talk about slow. Also uses over a MEG or ram just for the basic OS, they probably have Crays running on smaller operating systems. I have a theory the whole thing was written in basic, and is actually just a huge pracitical joke anyway). I don't know about A/UX. Dave Small will probably have system 7 working soon for those who want it. As for A/UX, since Dave is a UNIX wiz, if it does not work at this time, I'm sure he is working on it, or can at least let you know one way or the other. - David Butler - ------------------------------ Date: 3 Oct 91 04:38:44 GMT From: news-server.csri.toronto.edu!generic.physics.utoronto.ca!julian!julian.uwo.ca!e rsmith@uunet.uu.net (Eric Smith) Subject: Using gcc/g++ to cross compile for the ST To: Info-Atari16@naucse.cse.nau.edu In article <1991Oct2.215945.25204@elroy.jpl.nasa.gov> hyc@hanauma.jpl.nasa.gov (Howard Chu) writes: >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. The mint library docs were written before gcc 1.40 was available and before the gcc include files were adapted for MiNT (you can check the latter by grep'ing for __MINT__ in the include directory), so the confusion is understandable. Some clarification, then: (1) You can keep the original gcc include files and libraries, and name the MiNT libraries as mint.olb and mint16.olb, and then use the "-mint" switch to gcc to use the MiNT libraries (e.g. gcc -mint foo.c). If you do this, the MiNT library will be searched first, and then the "normal" gcc library; it is highly unlikely that anything will actually be linked from the normal library, since the MiNT one is complete, so that second search does nothing. (Also: use the gcc library crt0.o). You can use this set up if you want to use different libraries for different programs. (2) Alternatively, you can throw out (or put on a backup disk) the old gcc libraries and use the MiNT ones (in this case, call them gnu.olb and gnu16.olb) and the MiNT crt0.o. In this case, you'll probably want to use the MiNT include files instead of the gcc ones, since they're smaller. This is the setup I use, and it's the only one I can absolutely guarantee; on the other hand, I strongly suspect that (1) works as it should, since I trust bammi to get it right. Personally, I can see no reason *not* to use the MiNT library alone, so I see no reason to keep the "normal" one. However, mileage may vary. (Do I see a reason not to use the normal library? Yes: UNIXMODE is a horrible abomination that causes code bloat and aggravation if you're trying to use a non-TOS file system (like minix) under MiNT. It was probably one of my worst ideas (or, if the idea wasn't bad, the implementation certainly was). MiNT is my penance for UNIXMODE :-) ). -- Eric R. Smith ersmith@julian.uwo.ca eric.smith@uwo.ca create a sensible (non-TOS) file system. It was my worst mistake, and believe me, I've done penance for it ------------------------------ Date: 3 Oct 91 04:58:32 GMT From: pro-smof.cts.com!bgodot@ucbvax.berkeley.edu (Buck Godot) Subject: WANTED: Suggestions for ST color monitor purchase To: Info-Atari16@naucse.cse.nau.edu I'm tired of using Video Key with a composite monitor. It was an inexpensive option at the time, but I would like to get the real thing now. Does anyone have any suggestions for a color monitor purchase? Any warnings? BTW, this is for a 1040 STf..... ------------------------------ End of Info-Atari16 Digest ******************************