dillon@CORY.BERKELEY.EDU.UUCP (03/07/87)
The test was simple. If you run the following program in the background: for (;;) Delay(0); You are GUARENTEED to get a disk write error! The problem is in DOS. This is why HANOI running at full speed kills the machine... looking at the source it calls Delay() with some argument that was set to 12 - N , where N is the speed specified. If you specify 0, it calls Delay(0). This is also why Steve Drew's Manx version was dying a while back. By doing a directory on a cluttered disk with a large loop program running (for(;;) Delay(0)), you will also get read errors... what you hear is AmigaDos trying twice to read a track ... it misses a track, seeks to cyl. 0 and then tries again. So far as I can tell, Delay(1) doesn't seem to cause any problems. I've forwarded this to carolyn so she can get it to the right people. -Matt
dvmark@cca.UUCP (03/11/87)
In article <8703070244.AA13483@cory.Berkeley.EDU> dillon@CORY.BERKELEY.EDU (Matt Dillon) writes: > You are GUARENTEED to get a disk write error! > (goes on to explain that Delay(0) causes the problem) > So far as I can tell, Delay(1) doesn't seem to cause any problems. > -Matt In (an old) article (?@trantor.UMD.EDU) louie@trantor.UMD.EDU (Louis A. Mamakos) writes: > (about his new improved version of GfxMem) > The display updating is now much more crisp, and I'm now using the > timer.device rather than the AmigaDOS Delay() subroutine. There was a > note that the previous version could trash a disk while running the READ > (a primative downloading program - MJJ) program. I tested the new version > while downloading a copy of GfxMem.c (...), and things seemed to run just > fine. Those who learn nothing from history are doomed to repeat it - Santayana Those who have heard Santayana's quote are doomed to repeat it - Anon The above excerpt from Mr. Mamakos is dated 28 November, 1985! ^^^^ This note came with all copies of GfxMem that I have seen (on Fish Disks, BCS, etc.), maybe we should copy more working code than reinventing it. One thing that I am unclear about. The GfxMem problem was with a non-zero number sent to Delay(), keeping in mind that this was also AmigaDOS 1.0. If Delay(0) is still causing problems, I wonder if Delay(>0) just has a smaller target to hit, but the same possibility of hosing disk tracks? Matt, could you run some extensive tests with Delay(>0)?
garyo@masscomp.UUCP (03/12/87)
> Delay() is the culprit!
Matt notices that Delay(0) can cause disk errors.
Perhaps the reason I've never come across this is I always use the following
syntax:
if (dtime)
Delay(dtime);
Thus there's never a Delay(0).
I know this is obvious, I just thought I'd mention it.
Gary Oberbrunner
--
Remember, -Truth is not beauty;
Information is not knowledge; / Beauty is not love; Gary Oberbrunner
Knowledge is not wisdom; / Love is not music; ...!masscomp!garyo
Wisdom is not truth; ----/ Music is the best. - FZ