#DF0: activity?
24 messages in this thread
Bob:
I have an interesting occurance on my machine (A-2000)….. The DF0: drive
light periodically flashes. Seems that it will do that with Whap!, WP, or PgS
running. Haven't noticed it with anything else but will be trying to look a
little closer. It is curious since, like you, I rarely use the floppies for
much of anything and nothing is assigned to them. Any ideas as to what is
going on?
=>73<=, bill }KB7LX @ WA4LPD{
My primitive guess would be that the software's checking to see if a disk's
logged in?? sw
Steve:
Could be but I can't imagine why, there is no reason for any of those programs
to have any interest in df0. I am real suspicious that there might be
something goofy about my Amiga 2000, though it does not seem to be having
problems…… less than most report when it come to something like PageStream.
=>73<=, bill }KB7LX @ WA4LPD{
The safe but yucko thing to do might be to use VirusX3.2 or NoVirus (I actually
prefer the latter first) on your system to see if anything ugly's hanging
about. My long experience with a variety of systems has led me to the general
conclusion that one should always suspect the hardware *last*, and only after
doing a thorough investigation of all the other possibilities. The other thing
I could think of right off might be some jumper block configured oddly
somewhere?
Stabs in the Dark
Steve
Steve:
I would agree except that often such strangeness is 'known' to be due to 8520
problems…. In fact, every hardware problem that I have had was due to
something wrong with one of the 8520s (except possibly the clock problem that I
had with this 2000 and I really don't know if that problem still exists or not
— in fact I don't even know if I am using the vertical sync now for the line
clock or not). Have not seen NoVirus and am not sure which VirusX I am using
(just looked, guess I should update '1.21').
=>73<=, bill }KB7LX @ WA4LPD{
ye gods! 1.21?! It's up officially to 3.2; DO NOT go for any VirusX3.3 arc or
other files you see around, they're bogus and are in fact viruses themselves.
VirusX3.2's here in one of the libs somewhere. After hearing about the Falcon
disk virus from Spectrum Holobyte, just went through 30 (!) floppies with 3.2
in about an hour (my drive is sweating), fortunately no ugly discoveries. sw
Steve:
Thanks for the tip! I will look for 3.2 and load it up. Actually, I don't
worry too much since very few 'foreign disks' make it to my system….. of
course there are some and thats all it takes!
=>73<=, bill }KB7LX @ WA4LPD{
I've been a die-hard CP/M user for many a year (may continue to be one for many
more!), and never ran into viruses. I think I now have virtually every p.d.
virus utility currently available, including safeboot, novirus, virusX, and
others, since I also never ran into "custom boot blocks" on commercial CP/M
software, and have become quite anxious over the comparative fragility of disks
in the Amiga, Mac and PC arenas. steve
Steve:
Since I don't run any copy protected software, the boot block type virus has
not been anything that really scared me much. I did in fact get the original
virus (the one that announced that something 'wonderful has happened' and 'that
your amiga was alive.' The result was the feeling that I had been 'violated.'
I was furious, even though I knew that there would actually be no harmful
effects. Sorta like finding that your home has been burglerized!
I find that I have to place virus writers on about the same plane as those that
would put razer blades or poison in apples on All Hallows Eve! Really sick,
and a menace to society.
=>73<=, bill }KB7LX @ WA4LPD{
Bill, I'm in full agreement there; right next to 'em live the designers of copy
protected boot blocks.
Some day I'm going to have to figure out whether all those characters at the
end of your messages are a CB call-sign or a sideways design…. can't hold my
head sideways long enough to figure it out… =|8*> (abe lincoln w/sunglasses)
steve
Steve:
The '73' is a ham radio 'short hand' for best wishes. The }KB7LX @ WA4LPD{ is
the ham radio packet address that is needed to get messages to me on packet
radio….. My station call is KB7LX and the packet radio BBS station's call is
WA4LPD.
=>73<=, bill }KB7LX @ WA4LPD{
Bill,
One kind of all the wall thing that you may not have checked is
devs:mountlist. (All of them, if you reassign devs:). 'Handler = ???' entry for
something df0: based.
-John
John:
Elaborate please. Not sure what you are driving at. Everything except, env:
is assigned to DK0: and there is nothing that is on DF0: that does not also
exist in the appropriate directory on DK0:
=>73<=, bill }KB7LX @ WA4LPD{
Boy, looking at my message to you I can sure understand why it's hard to
follow. I'll try and be a little more clear this time.
From what I understand you're having problems with _something_ going to df0:
even when you have everything assigned elsewhere. One possible (not probable
now that I've thought about it a little more) problem is that in your
devs:mountlist file where you specify devices like filesystems, you have to
specify a, normally disk based, 'Handler'. The handlers are normally found in
L: and so normally an entry in devs:mountlist would look like…
handler = l:fastfilesystem
However, it also may not look like the above. If you are specifying…
handler = df0:l/fastfilesystem
then when that device is mounted, the handler will be loaded from df0:.
I realize now that this is probably not your problem as the disk access does
not seem to be related with mounting devices, however, devs:mountlist is a hard
place to remember to look at when weird things happen and I just thought you
might like to check it out.
-John
John,
One problem that will "lock" the system to df0: is not re-assigning T:
to RAM: (or a HD) before you issue a second EXECUTE command or do anthing else
that would cause a file to be written to T:.
Don
Aha! Another 'tricky' one.
-John
John:
OK, thanks, I appreciate your trying to think of possible solutions. Most
everything is mounted from DH2: except of course DH2: itself and the libraries
that AmigaDOS has to have to just startup.
=>73<=, bill }KB7LX @ WA4LPD{
Bill,
You should also check your 'path' to make sure you don't inadvertently
have something on DF0: in the list.
Hi Vic:
Yes, that was one of the eariler things that I checked but of course the
interesting thing is that this access takes place without any commands being
issued to the OS….. that is I will see the DF0: activity LED flash while just
typing a message in View! (for instance).
=>73<=, bill }KB7LX @ WA4LPD{
Bill,
Do you use WShell? What do you have in your ENV:path file?
-sja
I've had the exact same 'problem' that Bill Leach described for as long as I
can remember. It doesnt seem to cause any real trouble with disk activity or
system performance, but the drive light sort of flickers – sometimes quite
brightly, mostly a dim flash or two. Strange, but bearable. – Mike
Steve:
Yes, I am using WShell and lets see……. sys:c, sys:tools, sys:utilities,
sys:system (all DK0:).
=>73<=, bill }KB7LX @ WA4LPD{
Bill,
With PageStream running, _anything_ is possible. <grin>
That sure does sound like a weird problem, though (since it's not just with Pgs
running). I really don't have any ideas, other than the possibility of a minor
glitch in one of the 8520's, since (I think) they are involved with the floppy
disk driver. If I were adventurous, I might try swapping the two 8520's, and
see what symptoms appeared or changed. More than likely, I'd never get around
to it, though. <grin>
…BobR
Bob:
The thought occured to me but I am not feeling all that adventurous just now,
'if it ain't broke, don't fix it' seems to be appropriate just now!
=>73<=, bill }KB7LX @ WA4LPD{