Info-Atari16 Digest Tuesday, August 22, 1989 Volume 89 : Issue 403 This weeks Editor: Bill Westfield Today's Topics: How to find bad sectors on Hard Disk? Need Kind Soul to compile program! Dallas Semi TIMECLOCK & Questions! HELP! Re: Multitasking on the ST Re: Multitasking on the ST Re: Multitasking on the ST (Minix) Re: Apathy and Defeatism Cringely on TT How to do it propperly upgrading SF354 to double-sided, how??? ---------------------------------------------------------------------- Date: 14 Aug 89 20:27:24 GMT From: agate!helios.ee.lbl.gov!ncis.tis.llnl.gov!blackbird!jlong@ucbvax.Berkeley.EDU (Jeffrey K. Long) Subject: How to find bad sectors on Hard Disk? To: info-atari16@score.stanford.edu I have a 30 Meg hard disk that I home-brewed about a year ago. Anyway, at the time I got the drive mech. I lost the list of bad sectors which was taped to it. I use ICD formatting utilities on the disk, but they never flag any defective sectors. I seem to have a recurring problem whenever I get my disk just so full, that I feel like it must be a defective sector that is screwing up my programs whenever I try to load them. Does anyone know of a program that does a good job of flagging bad sectors on a hard drive? Any suggestions? I have reformatted several times but the problem always seems to pop up latter! Help! ========================================================================= | Jeff Long jlong@blackbird.afit.af.mil (ARPA net) | | | | humble (and getting humbler by the day) graduate student; | | The Air Force Institute of Technology (what a great way of life??) | ------------------------------ Date: 14 Aug 89 20:18:56 GMT From: agate!helios.ee.lbl.gov!ncis.tis.llnl.gov!blackbird!jlong@ucbvax.Berkeley.EDU (Jeffrey K. Long) Subject: Need Kind Soul to compile program! To: info-atari16@score.stanford.edu Hi , I have been trying for several months (almost a year! really) to find a .dvi driver for my HP Deskjet which runs on a 1meg machine. The only one I have found requires PC-Ditto since it is a messy-dos program. A while back I got JRD to compile some source code using his GCC port and with the exception of the requirement of more than 1meg of memory, it worked fine. Well, I finally go hold of the source for the driver which processes the page in separate strips, so it will run on 1 meg and 512K machines. But, the only C compiler I have is Laser-C and this source is the stuff from Utah that is written for about a zillion different C compilers, but none of which is a straightforward port using Laser-C. Anyway, JRD was able to compile the earlier code up for me with little trouble, and this should be a similarly easy port using GCC (gosh I whish I had the extra memory so I could run GCC on these larger source code files!!) I was wondering if there is anyone out there who, as a service to those of us with ST's and running LaTex and have a DeskJet, would be willing to try and port this source over to the ST. It would be a very valuable service indeed!! I would ask JRD to try again, but he has been so helpful in the past I hate to impose on his time anymore (not to mention the fact I erased my old mail from him and have lost his E-mail path :-) ) If anyone is willing to tackle this public service, please E-mail me a short note and we can discuss it further. Thanks for reading this!! ========================================================================= | Jeff Long jlong@blackbird.afit.af.mil (ARPA net) | | | | humble (and getting humbler by the day) graduate student; | | The Air Force Institute of Technology (what a great way of life??) | ------------------------------ Date: 14 Aug 89 21:32:43 GMT From: dino!sharkey!bnlux0!max.bnl.gov!atc@uunet.uu.net (Andrew Como) Subject: Dallas Semi TIMECLOCK & Questions! HELP! To: info-atari16@score.stanford.edu Hello world! Thanks for all the replies to my timeclock question. A few people pointed me to the Dallas Semi conductor clock/socket chip and said it was running on their Atari ST. I was given some software to run the clock that was written by some now-defunct software house in Calif (the name escapes me). The software doesn't seem to work with the clock inserted in any of the ST's rom positions. I figure I'll write my own driver for the thing however it states the clock uses address line A0 as part of the handshake. According to my ATARI ST INTERNALS book by Abacus the 68000 in the ST can't access A0! Has anyone sucessfully written software to run the clock chip on the 1040 ST? Also the Dallas Semi chip is rather bulky in the 1040 ST ..basically I'm gonna have to cut the power supply housing to make it fit. Does anyone know of a cartridge timeclock? ------------------------------ Date: 14 Aug 89 20:50:12 GMT From: cbmvax!daveh@uunet.uu.net (Dave Haynie) Subject: Re: Multitasking on the ST To: info-atari16@score.stanford.edu in article <29201@pbhya.PacBell.COM>, dbsuther@PacBell.COM (Daniel B. Suthers) says: > After reading this a question popped into my head. If you are downloading in > the back ground (it seems the most popular multi-task task) and running a > action game in the foreground, do you set the download process to the > highest priority to avoid losing data or do you just put up with longer > download times and connect times so your joy-stick will be responsive? Assuming your connection won't time out on you, and all your actual byte grabbing is interrupt or DMA driven (as on the Amiga), it's pretty much a matter of personal choice. Or looking at it another way, at least when talking to a commercial network, you'll pay for a higher game score with longer connect times. It's probably not that simple, though. In many video games, the game itself is taking most of the CPU time, at least on a 68000 processor. So if your video game is at a priority higher than that of your download, you may starve the XMODEM or Kermit protocol program. To be safe, I'd keep the download at the same or greater priority than that of the game. Though on 68020 or 68030 Amigas, you rarely run into that kind of process starvation. > While I'm at it... > What is a "ray trace" that most amiga users seem to want to generate them, and > are willing to wait 2 or 3 days for the output??? The ray traces I've done > have always completed over-night, and that's longer than I wish to wait for > a pretty drawing. Lots of Amiga folks are doing pretty serious ray tracing. Part of the limits of what you're going to be tracing are based on what you have available to enter the image in the first place. Tools on the Amiga like Byte-by-Byte's Sculpt- Animate 4D allow some pretty serious drawings to be entered. It's not only a timing issue, either -- I have two friend heavily into ray tracing. One is currently hitting memory limits on a 17 megabyte system I've set up here at Commodore, the other already has some images that can't be rendered on a 25 megabyte system. These certainly aren't typical users, but even for smaller ray traces, what finishes in 20 minutes on a 68030 system might take 25-100 times longer on a 68000 system. > Dan Suthers, Analyst, Pacific Bell -- Dave Haynie Commodore-Amiga (Systems Engineering) "The Crew That Never Rests" uunet|pyramid|rutgers!cbmvax!daveh PLINK: D-DAVE H BIX: hazy Be careful what you wish for -- you just might get it ------------------------------ Date: 14 Aug 89 23:00:05 GMT From: ncrlnk!ncr-sd!tw-rnd!johnl@uunet.uu.net (John Lindwall) Subject: Re: Multitasking on the ST To: info-atari16@score.stanford.edu In article <1071@philmds.UUCP> leo@philmds.UUCP (Leo de Wit) writes: >In article <482@tw-rnd.SanDiego.NCR.COM> johnl@tw-rnd.SanDiego.NCR.COM () writes: >|In article <1066@philmds.UUCP> leo@philmds.UUCP (Leo de Wit) writes: > [] >|>Why should memory protection be a hotter item when parallel processes >|>are involved? >| >|Because of the potential for a single user program to cause the termination >|of all the processes in the system. > >This is equally well possible in the current 'one-process-running-at-a-time' >scheme. Note that there are already accessory-based editors, batch >modem transfer programs, TSR print spoolers for the ST right now. > This point is well taken, but does not negate the point that process protection is desirable (in my mind). >| [My (John Lindwall's) example of a single process crashing the machine] > >I think you'll need a bit more than just an MMU for a secure system. >S'pose your nasty process alters some system vector (applying patch 271 >to SAFEDOS). A pity that the last bug was not yet removed... My point >is, that a MMU is a probably undispensable ingredient IN AN OTHERWISE >EXCELLENT SYSTEM. That safe system (which undoubtedly will have a >notion of privileges, users) is what you should start with in the first >place. > An MMU can protect pages of memory that the system considers special. The system vectors could be marked as un-writable by user level processes. An attempt to modify the protected pages could be trapped and prevented. I agree that the capabilities of an MMU are best utilized when designed into a system as opposed to grafted in as an afterthought. Current users of Commodore's 68020/68030 boards have an MMU in the system which has minimal benefit to the system, because AmigaDOS was not designed to support an MMU. In fact the only use I see for it (in the Amiga at present) is in copying the OS ROM into fast ram for a speed gain. True use of the MMU comes when running an OS designed to use it (like Unix when that becomes available). I am using the Amiga as an example here not because I believe it is the ULTIMATE SYSTEM that Atari should emulate. I feel ST users and developers can benefit from examining the problems and shortcomings that the Amiga is seeing now that MMU's are being phased in as standard equipment. >B.T.W. what do you do when a thunderstorm is coming up, but your >raytracer has yet to finish its last hour of calculations? Use a TMU :-) ? > Well, here in Sunny California (tm) we don't get many of those! :) :) :) >|I'm all for system robustness for ANY system. My point is that when you >|introduce multitasking, memory protection is more important due to the >|potential to disrupt other processes. > >I heard this one before and I still won't believe it, unless a proper >argument is given. > So I assume (if you were using a multi-tasking system) that you would prefer NOT to have process protection? I do not see the logic in this. >|>[about VM] >| >|Sounds Good! But now you're wandering into the area of virtual memory and >|that's not what our original discussion was about. Thanks for the reply. > >You bought an MMU but you don't want VM? Gee, that would be the first >reason I would buy an MMU for (and not for protection). As long as the >filesystems used are single-user, not write protectable, I don't care >much for safe core. > Yes, VM is nice. In my day-to-day Amiga experience I do not run out of memory much. I DO experience agonizing crashes which kill all my processes. From this experience I developed the priority of process protection being more important. If VM were available, I'm sure I would enjoy it and make use of it. Thank you for this enjoyable discussion. I hope it can continue on the amiable and informative level that has been maintained all along. Looking forward to your reply. ---------------------------------------------------------------------- John Lindwall johnl@tw-rnd.SanDiego.NCR.COM "Above opinions are my own, not my employer's" Health is merely the slowest possible rate at which one can die. -- ---------------------------------------------------------------------- John Lindwall johnl@tw-rnd.SanDiego.NCR.COM "Above opinions are my own, not my employer's" Health is merely the slowest possible rate at which one can die. ------------------------------ Date: 14 Aug 89 15:10:30 GMT From: polygen!jerry@bu-cs.bu.edu (Jerry Shekhel) Subject: Re: Multitasking on the ST (Minix) To: info-atari16@score.stanford.edu In article (Dzung Hoang) writes: >In article (DAVID MEGGINSON) writes: >> >>From what I've heard, Minix is very restrictive with memory. Each >>program is allowed a maximum of 64k, and there is not VM paging. A cute >>toy, but useless for anything but learning. >> > Minix for the IBM-PC's are restricted to 64K due to the PC's >architecture. The 68000 in the ST does not have any such restriction so it >can run programs larger than 64K. It is not "useless for anything but >learning." Post a message in comp.os.minix and you'll see what I mean. > > I used to have an ST but now own an AT compatible. I wish I still have >the ST (and a big hard drive) to run minix. > I've also had both the ST and the PC versions of Minix. The PC version's limitation is not 64K. A program may have 64K of code AND 64K of stack/data, for a total program size of 128K. This limitation is used for two reasons: it is reasonable for a teaching OS and most Minix utilities (MOST -- no 16-bit compress!), and it makes forking EXTREMELY fast and simple. Sure, you can run monstrous GNU stuff on ST Minix -- that is its strength -- unlimited program size. But try to run anything that forks a lot, like extracting programs from a shell archive, and you'll see the ST slow down to an unbelievable crawl, while my 8MHz AT zips along on the same job. And worse, try to run a program which forks and does not immediately exec(), and you'll be begging for an MMU! But just like the above poster, I sure wish I had a big hard drive for my ST Minix! --- +--------------------+-----------------------+-------------------------------+ | | Polygen Corporation | UUCP: | | Jerry J. Shekhel | Waltham, MA 02254 | princeton, mit-eddie, | | | (617) 890-2888 | buita, sunne!polygen!jerry | ------------------------------ Date: 14 Aug 89 22:58:46 GMT From: cs.utexas.edu!csd4.csd.uwm.edu!srcsip!tcnet!nic.MR.NET!ns!logajan@tut.cis.ohio- state.edu (John Logajan) Subject: Re: Apathy and Defeatism To: info-atari16@score.stanford.edu Xorg@cup.portal.com (Peter Ted Szymonik) writes: > Atari's strategy HAS also worked by the way - financially the company is > very strong and solid and 400 on the Fortune 500 list - far from an > easy achievement for a compnay that appeared a mere four years ago! Atari is also number 91 as far as all US companies involved in electronic equipment manufacture (not just computers!) Atari is a relatively large (net income wise) company. -- - John M. Logajan @ Network Systems; 7600 Boone Ave; Brooklyn Park, MN 55428 - - logajan@ns.network.com / ...rutgers!umn-cs!ns!logajan / john@logajan.mn.org - ------------------------------ Date: 14 Aug 89 21:47:36 GMT From: att!chinet!saj@ucbvax.Berkeley.EDU (Stephen Jacobs) Subject: Cringely on TT To: info-atari16@score.stanford.edu The 'Cringely' column in Infoworld today said that the TT will be officially announced August 25. He mentions some reasonable prices and specs. By experience, he's about as (in)accurate as most rumor mongers. So keep your fingers crossed, but remember the source, too. Other than that, I'd still be glad to hear about an ST or Mega delivered into US retail channels with TOS 1.4. Any sightings yet? Another thing I'd be interested in is a connoiseur's opinion of HDX 3.1, or whatever the new disk software is properly referred to as. Good and bad points. Steve J. ------------------------------ Date: 13 Aug 89 23:44:48 GMT From: ubc-cs!alberta!calgary!cpsc!schock@beaver.cs.washington.edu (Craig Schock) Subject: How to do it propperly To: info-atari16@score.stanford.edu Hi, For the last while I've been trying to find out how to use the LINE A (Copy Raster form ) Opcode $A00E propperly. Does anyone know the correct procedure for setting up and making a call to $A00E. All the docs I've recieved over the last 6 months have all been kludgy and all seem to contradict one another. I've gotten something to work, but it's pretty flakey. Any help on this matter would be greatly appreciated! Thanks in Advance Craig Schock Dept. of Computer Science University of Calgary. ------------------------------ Date: 15 Aug 89 03:46:31 GMT From: usc!ginosko!rex!hoang@bloom-beacon.mit.edu (Dzung Hoang) Subject: upgrading SF354 to double-sided, how??? To: info-atari16@score.stanford.edu I am attempting to upgrade a SF354 disk drive to a double sided drive by replacing the mechanism with an NEC FD1035 drive. I thought that the procedure would be simple until I saw that the connectors on the two drive mechanisms are not the same. The SF354 has a 14-pin single-row connector while the NEC has a 34-pin two-row connector. I have read that this upgrade is a simple matter. Could it be that my SF354 is a different version? Has anyone attempted the same feat successfully. If so, I would appreciate hearing how you did it. Dzung Hoang -- ----------------------------------------------------------------------------- hoang@comus.cs.tulane.edu hoang@rex.cs.tulane.edu hoang@comus.UUCP hoang@rex.UUCP tulane!comus!hoang tulane!rex!hoang ------------------------------ End of Info-Atari16 Digest ************************** -------