Copy Link
Add to Bookmark
Report
Info-Atari16 Digest Vol. 89 Issue 403
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
**************************
-------
