Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Path: utzoo!mnetor!seismo!lll-lcc!ames!ucbcad!ucbvax!fingate.BITNET!MAILER-DAEMON From: MAILER-DAEMON@fingate.BITNET (Mail Delivery Subsystem) Newsgroups: comp.sys.atari.st Subject: Returned mail: User unknown Message-ID: <8701181012.AA23191@ucbvax.Berkeley.EDU> Date: Sun, 18-Jan-87 05:13:03 EST Article-I.D.: ucbvax.8701181012.AA23191 Posted: Sun Jan 18 05:13:03 1987 Date-Received: Sun, 18-Jan-87 09:37:44 EST Sender: daemon@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 474 ----- Transcript of session follows ----- >>> RCPT To: <<< 550 ... User unknown 550 ... User unknown ----- Unsent message follows ----- Received: by santra.UUCP (5.51/6.3.TeKoLa) id AA11413; Fri, 16 Jan 87 17:29:33 +0200 From: Message-Id: <8701161529.AA11413@santra.UUCP> Received: by fingate Fri Jan 16 17:29:27 from MAILER@FINHUTC.BITNET via rscs BSMTP. Received: by FINHUTC (Mailer X1.23b) id 0346; Fri, 16 Jan 87 11:43:32 FIN Date: Thu 15 Jan 87 16:53:56 PST Reply-To: Sender: Atari ST users forum Comments: X-To: "Distribution List: ;" Original-From: Info-Atari16 Digest Subject: Info-Atari16 Digest V87 #23 To: , , Original-To: ,,Also I would like to point out that from common sense, there is no way the >desktop can have any knowledge about the folders on a disk that has never >been opened. For example, lets say I boot my hard disk, then close the >floppy window and insert a disk with 39 folders on it into the drive. NOw >assuming I never open that disk, there is no possible way for the computer >to see those and be affected by them. > However, I am going to bring drive C down below 30 folders just in case... Is this true? I gathered from the letters that just HAVING the folders around was a danger... one last thing, to test the bug, he created a floppy with 59 folders on it (he brought the hard drive down first, of course)... When he did a SHOW INFO, it reported 38 folders... --jon drukman ARPA: jsd%oz@mit-mc BITNET: drukman@umass "Do do the cruel immersion Do do the flaming tie" - shriekback ------------------------------ Date: 14 Jan 87 13:50:54 GMT From: mcnc!ecsvax!harris@seismo.css.gov (Mark Harris) Subject: Re: MINIX To: info-atari16@score.stanford.edu In article <1028@botter.cs.vu.nl>, ast@botter.cs.vu.nl (Andy Tanenbaum) writes: > Q2: How compatible does a machine have to be to run MINIX? > A2: It needs a NEC uD765 chip as floppy disk controller, a Motorola 6845 as > video controller, etc. Will MINIX run with an Enhanced Graphics Adapter? My system has an EGA/monochrome monitor. - Mark Harris, Appalachian State University ------------------------------ Date: 14 Jan 87 15:14:13 GMT From: mcvax!prlb2!bernard@seismo.css.gov (Bernard Yves) Subject: What Graphics for the Mega's ? To: info-atari16@score.stanford.edu The new MegaST's seem great : they have many interesting new features but I'd like to have more informations about their new graphics. Some postings say there will be the blitter chip built-in, some other no. Some rumors say that there will be an expansion card with a graphic chip and allowing a 1024 * 1024 resolution on a monochrome monitor. So, what is the truth ? If we only consider the hardware, we nearly have everything for a good small low-cost workstation : memory (2Meg, 4Meg), power (68000/88020). But what about graphics ? When will we have a screen (monochrome is enough) with at least 1024*1024 resolution, good enough for true desktop publishing and CAD applications ? What will be its price ? What are the graphics improvements in the Mega family (if there are any) ? Yves Bernard Philips Research Labs, Brussels. ------------------------------ Date: 15 Jan 87 01:18:22 GMT From: bzs@bu-cs.bu.edu (Barry Shein) Subject: Something old, something new (a proposal) To: info-atari16@score.stanford.edu Here's a wierd idealistic idea... Let's face it, in the micro world we are destined to "get stuck" with aging technology (ie. anything more than 6 months old.) The worst thing is to create a back pressure on innovative vendors to hold back things so old boxes (which may contain honest errors of design) might be upgraded or kept compatible. So we need a solution that can be applied successfully over and over again (other than whining every time :-) Here's mine: 1. Offer a trade-in on the last model as a substantial discount against the new model. 2. Sell these used systems at their steeply discounted price back to schools who can (should be able to...) make good use of them. 3. Get the tax boys (and girls) to maximize that spread by having the government kick in in the form of a tax deduction to the company (who, more than likely, is incurring at least an operating cost for managing the program.) There is little doubt in my mind that this would *not* be a "tax scam", schools are spending on computers, this reduces the govt's bills (or tuition on campuses, etc) and should be compensated. 4. Have a lottery or something simple like that to distribute the used systems (I don't care, just keep it simple.) 5. Let the various vendors play one-upsmanship (one-upspersonship?) on how far they can push such programs, ahh, competition at its altruistic best! Am I only a dreamer? A fool in love? So shoot me. -Barry Shein, Boston University Fellow Americans, it may be ugly to think about, but there are places in America where children go for days without hacking... ------------------------------ Date: 14 Jan 87 19:12:51 GMT From: braner@tcgould.tn.cornell.edu (braner) Subject: Re: Re: Hard disk questions (40 folder limit) To: info-atari16@score.stanford.edu IF giving GEMDOS a mediach() return value of "changed" once in while (for the hard disk) will solve the 40-folders bug, it should be trivial to write an utility that intercepts the mediach() vector and returns "changed" periodically (say every 10th call). Does anybody know if that would work? And should it return "maybe changed" or "definitely changed"? Is there another way to do it? If that does not solve it, how about a utility that keeps track of the number of folders you have "accessed"? This would mean intercepting the Rwabs() vector, looking at directory sectors when they are read, scanning the entries, finding out which are subdirectories, noting those down, and scanning those if they are later read. Not trivial, this one, but possible. It should print a warning on the screen when you're approaching the limit. - Moshe Braner ------------------------------ Date: 15 Jan 87 04:51:38 GMT From: jpexg@HERMES.AI.MIT.EDU (John Purbrick) Subject: Re: printers To: info-atari16@score.stanford.edu > I'm still searching for the right printer for my ST. > In the January BYTE, page 402, there's an ad from FOCUS Computers where > it says they'll sell you a Toshiba P321 printer for... $348.50! > Is that a typo? That printer costs a LOT more elsewhere: it's a 24-pin > device..... Has anybody had any dealings with Focus? I can't comment on the printer, but I just bought a printer from Focus. It came in less than a week and is just as advertised. Mine's a Panasonic KXP1080i, it cost $190 and is adequate for my purposes. Note that 24-pin printers tend not to include a tractor feed! I thought of a 24-pin model too, but couldn't justify the cost to myself. If you deal with the New York outfits, expect a hard sell on their part for additional stuff (power line monitor, dust cover, extra paper and ribbon, etc), but I've always won buying the printer and photo equipment. No problems with extended delivery or ripoffs. Regarding the price, beware. A glossy magazine's prices will be weeks out of date, and the vendor won't stand by the advertised price (unless it's higher!). The dollar just doesn't buy the yen it used to. Get the Sunday New York Times and look in the second half of the second section--all the dealers advertise there and the prices are usually good till the following Tuesday. --John Purbrick jpexg@hermes.ai.mit.edu ps The Panasonic KXP1080i has a graphics resolution of 72 dots per inch (at least, that's the highest resolution with equal X and Y resolution). ------------------------------ Date: 14 Jan 87 14:25:17 GMT From: cyliax@ee.ecn.purdue.edu Subject: programming the dma port To: info-atari16@score.stanford.edu Has anyone had any experience programming the dma port ? I have build an interface to use on the port, but I have some problems accessing it in software. I used the following code segment to access the port: { short rv; short *flock = (short *)0x43e; /* flag to disable flpvbl routine */ short *hdcreg = (short *)0xff8604; /* the fdc/sector count register */ short *dmareg = (short *)0xff8606; /* dma mode/status register */ while(!*flock) /* wait for flock */ ; *flock++ ; /* and set it */ *dmareg = 0x08; /* select hdc register with A1 = 0 */ *hdcreg = 0x00; /* now write to it */ rv = *hdcreg; /* now read from it */ *flock = 0; /* enable flpvbl routine */ return(rv); } When this was run in supervisory mode, there was no activity on the dma port control signals ( CS R/W* d0-d7 .. ) at all. Although the returned value did reflect the state on the data lines, for example pulling one low would reset the coreesponding bit in the returned value. I have also tried putting some delays between the reads and writes. Any hints or pointers would be greatly apreciated. Ingo Cyliax cyliax@ee.ecn.purdue.edu cyliax@ihnp4!pur-ee ------------------------------ Date: 14 Jan 87 17:19:00 GMT From: clyde!watmath!watnot!watrose!jafischer@rutgers.rutgers.edu (Jonathan Fischer) Subject: Csd - C source debugger To: info-atari16@score.stanford.edu Start Winter 86/87 lists both "Let's C" and "Csd" as if they are available for the ST, yet I had read some time ago that Mark Williams Co. had no plans for porting Csd. Does ANYONE have any news about Csd for the ST? Price? Availability? -Jonathan Fischer ------------------------------ Date: 14 Jan 87 18:01:09 GMT From: clyde!masscomp!ulowell!rstpierr@rutgers.rutgers.edu (Pete St.Pierre) Subject: booting off a hard disk. To: info-atari16@score.stanford.edu I was told that even with a hard disk set up... The ST still needs a a disk in the floppy drive to boot. Is this really the case? It seems to be a bit of a waste. Replies: USnail Pete St.Pierre UUCP: wanginst!ulowell!rstpierr Box 2059 Univ of Lowell Lowell, Ma. 01854 ------------------------------ Date: 14 Jan 87 19:24:38 GMT From: ihnp4!alberta!ubc-vision!ubc-cs!manis@ucbvax.Berkeley.EDU (Vincent Manis Subject: Re: resource files To: info-atari16@score.stanford.edu The only good reason for embedding a resource file in a program is when writing a DA. The resource manager apparently doesn't free memory properly when closing a resource file, so you're apparently advised not to load resources dynamically. I wouldn't know--I've never written a DA. However, embedded resources can't be easily changed; if you want to modify resources, you have to re-edit the resource file and re-embed. I can't see how it's worth the effort. In any case, separate .RSC files are a real win. You can easily distribute different RSC files for one program (thus supporting various monitor resolutions, or different languages for example). ------------------------------ Date: 14 Jan 87 11:35:42 GMT From: clyde!watmath!sunybcs!leo@rutgers.rutgers.edu (Leo Wilson) Subject: Re: Atari rumor To: info-atari16@score.stanford.edu Perhaps Atari took it to heart that people aren't real pleased about the 40 folder limit and decided to put out a machine that wouldn't have such an incredibly limiting problem. At least one vendor that I've spoken with about networks (BMB Compuscience in Milton, Ontario) uses a PC or compatible as the master/file server in a LAN scheme, neatly circumventing TOS's brain problems.... This company is also the ONLY one I've spoken with that will say "Yes, we'll network your ST's TODAY!", and I've called every one I've heard of that's involved with an ST network... Disclaimer: I'm not involved with BMB or atari, just trying to use ST's at work... where they have a very sparse idea that Usenet exists and no idea at all that the company name is in my .signature ... -- Leo E. Wilson(leo@buffalo.csnet) Niagara Paper Company 364 West Delavan Avenue 99 Bud-Mil Drive Buffalo, NY 14213 Buffalo, NY 14206 (716)883-7573 (716)856-5135 (0830-1700) ------------------------------ Date: 14 Jan 87 21:01:20 GMT From: i.cc.purdue.edu!afo@j.cc.purdue.edu (Alan Davis) Subject: Re: Screen Saver? To: info-atari16@score.stanford.edu In article <4160@utah-cs.UUCP> atwell@utah-cs.UUCP (Bart L. Atwell) writes: >About a year ago, an accessory was posted that would turn off the screen. >Unfortunately, it required you to select a desk accessory to do it. Does >anybody have one that turns off the screen after a certain amount of idle >time and turns it back on at a key/mouse click? I have solapak which for $29.95 will get you a ramdisk, print spooler and adjustable screen saver that runs from the auto folder. It also contains a configuration program that will allow you to disable the spooler and ramdisk if you want. The sppoler is a desk accessory that comes with several printer drivers and several "preset" print options. Disclaimer: PPPPPPPPP Alan Davis PPPPPPPPPP Purdue University Computing Center PP PP PP PP Usenet: {backbone}!pur-ee!s.cc.purdue.edu!afo PPPPPPPP BITNET: ADAVIS@PURCCVM PPPPPPP PP PP Disclaimer: I don't agree with Purdue's opinions, PPPPPP they don't agree with mine. PPPPPP ------------------------------ Date: 15 Jan 87 10:35:07 GMT From: voder!kontron!brad@ucbvax.Berkeley.EDU (Brad Yearwood) Subject: More on Alcyon double float array problem To: info-atari16@score.stanford.edu I was waiting for somebody else to more-or-less confirm my finding before posting this particular note. Another posting received this evening seems to confirm things sufficiently. Try the following program: double a[16]; main() { int i; double p, q; i = 10; p = 2.0; q = 3.0; a[i] = p * q; } Examine the generated code. Unless the late hour was impairing my judgment, the double multiply library routine returns its result in D0 and D1 (R0 and R1 - whatever you want to call them). The effective address calculation for a[i] promptly clobbers one or the other of these registers before doing the stores of each half of the result. No wonder my Fast Fourier Transforms and digital filters gave so many zero results that could be cured by breaking the computation down into tiny bite sized pieces, carefully avoiding any array element assignment more complex than: a[i] = I also observed printf hangups in debugging - possibly the partially corrupted stores create non-numbers which wedge the conversion routine. When reduced to tiny bite-sized pieces, however, Alcyon lets the inverse FFT of the FFT of 200 real data points zero-padded to 256, return very much the original real data, with only 0.0 and -0.0 imaginary components, and 0.0 or -0.0 in the real components of the 56 original zero-fill points. This is all using the IEEE package - not the fast package. My numerical luck with Mark Williams C hasn't been quite so good yet, with substantial fuzz remaining in both the imaginary components and zero-fill. They _do_ generate correct code, however. Win a few and lose a few. Maybe us seriously masochistic types who like the idea of slow floating point image processing on a budget, really just need a diversified portfolio of compilers to spread our risks. Disclaimer: This reflects work of strictly personal interest. Though we are commercially involved in image processing, my work at Kontron lies elsewhere. Brad Yearwood Kontron Electronics {voder, pyramid}!kontron!brad Mountain View, California (415) 965-7020 ------------------------------ Date: 14 Jan 87 17:01:58 GMT From: clyde!watmath!watnot!watrose!jafischer@rutgers.rutgers.edu (Jonathan Fischer) Subject: Re: Mac Emulator (idea!) To: info-atari16@score.stanford.edu In article <37@marque.UUCP> joeb@marque.UUCP (Joe Bronikowski) writes: >In article <870@ark.cs.vu.nl> Patrick@ark.cs.vu.nl (Patrick van Kleef) writes: >> >>People tell me there is a way of preventing bus errors on the ST. This >>type of error is generated by one line of the Glue chip, the so called >>BERR line. >> >>Now what if we disconnected that line? In theory bus errors would be >>impossible. Would it affect 'normal programs'? Will more Macintosh programs >>run? Is there anyone who can figure this out? The Mac has RAM in locations 0-8 that is unused by the OS (after booting), and some Mac programs, you would think, must actually USE this RAM. The ST has ROM in that area (or is it just ROM in location 0?), so eliminating the BERR would do no good. The program would still not work. It would be like eliminating the sensation of pain. You wouldn't feel that you have just sawed off your right leg, but it would still be gone. The above is based largely on hearsay and stuff from Magic Sac README files, so I may be partly wrong. Am I? -Jonathan Fischer ------------------------------ End of Info-Atari16 Digest ************************** -------