FFS, PFS, or AFS?
Steven
>I am using OS3.9 with FFS 45.1 that came with it. I was under the impression
>that FFS was fixed to handle larger drives than 4 gigs.....
Yes, is your OS 3.9 'C:SetPatch' working ?
>but I just installed a 6.1 gig drive using HDToolbox and all went well. That
>is, it recognized the drive as 6 gigs, and I was able to partition it very
>easily, but when I did the mandatory reboot, not all my partitions appeared,
>the larger partitions at the end of the drive failed to appear. I tried to make
>those partitions smaller, but same results.
Check all the partitions are set to Automount (HDToolBox -> Change...).
You could also try HDInstTools, hdinst.lha from Aminet.
>If I use scsi mounter, it sees all the partitions and I can dismount the
>invisible ones and remount them, but they just DO NOT show up. I can quick
>format them using a tool like MyFormat 1.26.....the partitions show there, but
>the format still doesn't make an icon appear and DirectoryOpus 4 says
>"directory not available.
Try using the Workbench Format menu.
>I had a 2 gig drive that was really overheating (you guessed it, a Seacrate
>Barracuda), thus the need to install another drive. Will I lose the data on
>my drive if I switch file systems?
Yes, but only on the partitions using the changed filesystem.
>Help, please?
I hope it does.
Good luck,
Steven
--
To reply using mail, Please change my address so I have a big foot !
Jim Woods
>>I am using OS3.9 with FFS 45.1 that came with it. I was under the
>>impression that FFS was fixed to handle larger drives than 4 gigs.....
>Yes, is your OS 3.9 'C:SetPatch' working ?
As far as I know....how can I tell?
>>but I just installed a 6.1 gig drive using HDToolbox and all went well.
>>That is, it recognized the drive as 6 gigs, and I was able to partition it
>>very easily, but when I did the mandatory reboot, not all my partitions
>>appeared, the larger partitions at the end of the drive failed to appear. I
>>tried to make those partitions smaller, but same results.
>Check all the partitions are set to Automount (HDToolBox -> Change...).
All are automount
>You could also try HDInstTools, hdinst.lha from Aminet.
I have that program....no different results.
>>If I use scsi mounter, it sees all the partitions and I can dismount the
>>invisible ones and remount them, but they just DO NOT show up. I can quick
>>format them using a tool like MyFormat 1.26.....the partitions show there,
>>but the format still doesn't make an icon appear and DirectoryOpus 4 says
>>"directory not available.
>Try using the Workbench Format menu.
I can't because there are no icons for the partitions I want to format.
>>I had a 2 gig drive that was really overheating (you guessed it, a Seacrate
>>Barracuda), thus the need to install another drive. Will I lose the data on
>>my drive if I switch file systems?
>Yes, but only on the partitions using the changed filesystem.
That's what I was afraid of....damn.....
>>Help, please?
I have a new problem now..... I use ToolsDaemon and made the mistake of changing
>Good luck,
> Steven
Now I have a new problem, and here is a warning for all those who still use
ToolsDaemon with OS3.9......now I know why they moved it out of WBStartup
when it installed. You can use it without any problem until you want to
change the menu. When you save the changes in the ToolsDaemon Prefs, the
program crashes your computer and changes something in the boot startup
routine, because after the crash you ban't reboot......it goes partway and
then stops. I'm lucky I still have this 2.1 gig with everything still
working. Grrrrrr!!!
Thanks for your input Steve.
--
Jim Woods <jwo...@travel-net.com>
<tsb>Amiga 2000 040/33
Steven
>>>I am using OS3.9 with FFS 45.1 that came with it. I was under the
>>>impression that FFS was fixed to handle larger drives than 4 gigs.....
>>Yes, is your OS 3.9 'C:SetPatch' working ?
>As far as I know....how can I tell?
In a CLI Shell, just type 'SetPatch', it should then show what's patched.
Make sure the scsi.device and filesystem are updated.
>>>but I just installed a 6.1 gig drive using HDToolbox and all went well.
>>>That is, it recognized the drive as 6 gigs, and I was able to partition it
>>>very easily, but when I did the mandatory reboot, not all my partitions
>>>appeared, the larger partitions at the end of the drive failed to appear. I
>>>tried to make those partitions smaller, but same results.
>>Check all the partitions are set to Automount (HDToolBox -> Change...).
>All are automount
>>You could also try HDInstTools, hdinst.lha from Aminet.
>I have that program....no different results.
>>>If I use scsi mounter, it sees all the partitions and I can dismount the
>>>invisible ones and remount them, but they just DO NOT show up. I can quick
>>>format them using a tool like MyFormat 1.26.....the partitions show there,
>>>but the format still doesn't make an icon appear and DirectoryOpus 4 says
>>>"directory not available.
>>Try using the Workbench Format menu.
>I can't because there are no icons for the partitions I want to format.
Hmmm, try in a CLI Shell,
'format drive <the partition> name <your name> noicons quick'
If this doesn't work and you don't mind losing the contents of your 6 gig drive,
make an OS 3.9 Emergency boot floppy disk, then using (booting) only this disk
and using this HDToolBox and CD to again fully install (read configuration) and
partition the 6 gig drive again.
Set your 6 gig drive boot partition to Boot Priority 2 and Save.
Still using the Emergency disk, format all the 6 gig drive partitions and then
install OS 3.9 in the 6 gig drive boot partition.
Now remove the Emergency disk and it should all be working :-/.
If not, you may need to post some more details about your system and also what
'info' lists ?
Jim Woods
>>As far as I know....how can I tell?
>In a CLI Shell, just type 'SetPatch', it should then show what's patched.
I will try that...thanks
>Make sure the scsi.device and filesystem are updated.
I have omniscsi.device
>>>Try using the Workbench Format menu.
>>I can't because there are no icons for the partitions I want to format.
>Hmmm, try in a CLI Shell,
> 'format drive <the partition> name <your name> noicons quick'
>If this doesn't work and you don't mind losing the contents of your 6 gig
>drive, make an OS 3.9 Emergency boot floppy disk, then using (booting) only
>this disk and using this HDToolBox and CD to again fully install (read
>configuration) and partition the 6 gig drive again.
>Set your 6 gig drive boot partition to Boot Priority 2 and Save.
>Still using the Emergency disk, format all the 6 gig drive partitions and
>then install OS 3.9 in the 6 gig drive boot partition.
>Now remove the Emergency disk and it should all be working :-/.
>If not, you may need to post some more details about your system and also
>what
>'info' lists ?
Gawd I feel sheepish. I just used HDToolbox and looked at the filesystem
installed and it is 44.5 or something like that...can't remember now. I
checked in the OS3.9 and the version is 45.9, so that may be my problem the
whole time......I used the wrong filesystem. I have to try it again now.
Thanks....I'll post again if that was the trouble. Thanks for the help.
Jim Woods
I completely re-installed my 6 gig drive using the correct filesystem, but my
partitions still fail to show up
>>>>Yes, is your OS 3.9 'C:SetPatch' working ?
>>>As far as I know....how can I tell?
>>In a CLI Shell, just type 'SetPatch', it should then show what's patched.
>I will try that...thanks
CLI says setpatch version 44.13 has already been installed.
>>Make sure the scsi.device and filesystem are updated.
>I have omniscsi.device
Setpatch says scsi.device has been patched but I use omniscsi.device....is
that a problem?
>>>>Try using the Workbench Format menu.
>>>I can't because there are no icons for the partitions I want to format.
>>Hmmm, try in a CLI Shell,
>> 'format drive <the partition> name <your name> noicons quick'
The response to this is "format failed", "not of required type"
>>If this doesn't work and you don't mind losing the contents of your 6 gig
>>drive, make an OS 3.9 Emergency boot floppy disk, then using (booting) only
>>this disk and using this HDToolBox and CD to again fully install (read
>>configuration) and partition the 6 gig drive again.
>>Set your 6 gig drive boot partition to Boot Priority 2 and Save.
I completely re-installed the drive, saved, and re-booted but still missing
the 2 partitions at the end of the drive. It's weird, because Info doesn't
list the partitions, but the program MyFormat1.26 does. Trying to format
using that program still fails, however.
>Gawd I feel sheepish. I just used HDToolbox and looked at the filesystem
>installed and it is 44.5 or something like that...can't remember now. I
>checked in the OS3.9 and the version is 45.9, so that may be my problem the
>whole time......I used the wrong filesystem. I have to try it again now.
>Thanks....I'll post again if that was the trouble. Thanks for the help.
I don't feel sheepish now.....it still doesn't work.
My system is a 2000 with GVP040/33 combo with GURU Rom v6.10, 64 megs ram plus 2
megs chipram. I also have a ZIP drive. I have a PicassoII running CGFX.
Any more suggestions? I really want to use the full 6.4 gigs on that drive.
Steven
>CLI says setpatch version 44.13 has already been installed.
That's the correct version.
>>>Make sure the scsi.device and filesystem are updated.
>>I have omniscsi.device
>Setpatch says scsi.device has been patched but I use omniscsi.device....is
>that a problem?
Hmmm, I don't know much about this device, but it could be the problem. FFS uses
New Style Devices NSD for above 4 GB !
Someone may know of an updated version of this device or Guru ROM.
Type in a CLI Shell, 'version omniscsi.device full' to get the version.
While you wait for an answer, go to Aminet and get SFS_BETA.lha, install it in
the partitions that don't show up with HDToolBox and quick format them.
SFS will work with NSD, TD64 and SCSI Direct.
Use 'SFSCheck <SFS partition>' and it will show the Device interface type.
BTW, PFS3 uses TD64 or SCSI Direct.
>>>Hmmm, try in a CLI Shell,
>>> 'format drive <the partition> name <your name> noicons quick'
>The response to this is "format failed", "not of required type"
This also suggests the filesystem is having problems with the device.
>>>If this doesn't work and you don't mind losing the contents of your 6 gig
>>>drive, make an OS 3.9 Emergency boot floppy disk, then using (booting) only
>>>this disk and using this HDToolBox and CD to again fully install (read
>>>configuration) and partition the 6 gig drive again.
>>>Set your 6 gig drive boot partition to Boot Priority 2 and Save.
>I completely re-installed the drive, saved, and re-booted but still missing
>the 2 partitions at the end of the drive. It's weird, because Info doesn't
>list the partitions, but the program MyFormat1.26 does. Trying to format
>using that program still fails, however.
Don't use MyFormat1.26, if you did it how I suggested, then it should be fine.
>My system is a 2000 with GVP040/33 combo with GURU Rom v6.10, 64 megs ram
>plus 2 megs chipram. I also have a ZIP drive. I have a PicassoII running
>CGFX.
>Any more suggestions? I really want to use the full 6.4 gigs on that drive.
I hope that's enough for the moment ;-).
I'm sure the solution is very near :-).
Good Luck,
Niels Bache
> I completely re-installed my 6 gig drive using the correct filesystem, but my
> partitions still fail to show up
[...]
> Setpatch says scsi.device has been patched but I use omniscsi.device....is
> that a problem?
Jim, have you tried uncommenting the relevant line in your
DEVS:NSDPatch.cfg file? Load it into an editor, search for "omni", read
what it says there, and (if it's the version you need) uncomment the
line with the specs for the device. The comment mark is the "#" in the
first column, just remove that.
You can read more (much more!) about the usage at the top of the file.
Oh, and make sure you are using the newest of those config files. There
was a time (BB1?) where a new file was installed with a name like
NSDPatch.cfg-new or something, but you had to go in yourself and rename
it to NSDPatch.cfg after carrying over any modifications you had made in
the old one.
I don't specifically know if that's your problem, but if you haven't
tried it yet, I sure would give it a go.
[...]
Best regards,
Niels
--
______ Almost quite, but not entirely, unlike forty-two.
___/L_][_\\__ _ // Yet another | Niels Bache, Groenlandsvej 12 B
(___{__{__{___7 \X/ Amiga user!!! | DK-2800 Lyngby, Denmark
`(_)------(_)-' My other .sig is a Porsche... nba...@post5.tele.dk
Jim Woods
>That's the correct version.
>>>>Make sure the scsi.device and filesystem are updated.
>>>I have omniscsi.device
>>Setpatch says scsi.device has been patched but I use omniscsi.device....is
>>that a problem?
>Hmmm, I don't know much about this device, but it could be the problem. FFS
>uses New Style Devices NSD for above 4 GB !
What is NSD? I never heard of that.
>Someone may know of an updated version of this device or Guru ROM.
>Type in a CLI Shell, 'version omniscsi.device full' to get the version.
It says omniscsi.device 1.10 (o4/03/95)
>While you wait for an answer, go to Aminet and get SFS_BETA.lha, install it
>in the partitions that don't show up with HDToolBox and quick format them.
I will try that, but then will I need multi-filesystem or whatever it is
called?
>SFS will work with NSD, TD64 and SCSI Direct.
>Use 'SFSCheck <SFS partition>' and it will show the Device interface type.
>BTW, PFS3 uses TD64 or SCSI Direct.
>>>>Hmmm, try in a CLI Shell,
>>>> 'format drive <the partition> name <your name> noicons quick'
>>The response to this is "format failed", "not of required type"
>This also suggests the filesystem is having problems with the device.
>>>>If this doesn't work and you don't mind losing the contents of your 6 gig
>>>>drive, make an OS 3.9 Emergency boot floppy disk, then using (booting)
>>>>only this disk and using this HDToolBox and CD to again fully install
>>>>(read configuration) and partition the 6 gig drive again.
>>>>Set your 6 gig drive boot partition to Boot Priority 2 and Save.
>>I completely re-installed the drive, saved, and re-booted but still missing
>>the 2 partitions at the end of the drive. It's weird, because Info doesn't
>>list the partitions, but the program MyFormat1.26 does. Trying to format
>>using that program still fails, however.
>Don't use MyFormat1.26, if you did it how I suggested, then it should be
>fine.
I just mentionned that because that program saw the partitions. Also if I
boot from the OS3.1 Workbench OR the Install disk, the partitions show up.
>>My system is a 2000 with GVP040/33 combo with GURU Rom v6.10, 64 megs ram
>>plus 2 megs chipram. I also have a ZIP drive. I have a PicassoII running
>>CGFX.
>>Any more suggestions? I really want to use the full 6.4 gigs on that drive.
>I hope that's enough for the moment ;-).
>I'm sure the solution is very near :-).
I will have to keep trying. I've NEVER run into such a frustrating problem
with my Amiga before......sheeeesh!
Jim Woods
>> I completely re-installed my 6 gig drive using the correct filesystem, but
>> my partitions still fail to show up
>[...]
>> Setpatch says scsi.device has been patched but I use omniscsi.device....is
>> that a problem?
>Jim, have you tried uncommenting the relevant line in your
>DEVS:NSDPatch.cfg file? Load it into an editor, search for "omni", read
>what it says there, and (if it's the version you need) uncomment the
>line with the specs for the device. The comment mark is the "#" in the
>first column, just remove that.
I found the line and it says for omniscsi, I need the GVPscsi line. That one
followed immediately with the # sign, so I deleted that #. I have a backup if
that is not correct. This is an area that is more technical than I am used
to handling, but, hey, I will try anyhing :-)
>You can read more (much more!) about the usage at the top of the file.
There is a LOT of stuff there, but you need an understanding of what it means
to understand :-) :-)
>Oh, and make sure you are using the newest of those config files. There
>was a time (BB1?) where a new file was installed with a name like
>NSDPatch.cfg-new or something, but you had to go in yourself and rename
>it to NSDPatch.cfg after carrying over any modifications you had made in
>the old one.
I'm not sure which version I have OR which is newest...I will have to check.
>I don't specifically know if that's your problem, but if you haven't
>tried it yet, I sure would give it a go.
>[...]
>Best regards,
>Niels
This sounds really good to me....thanks for the input. I will post what I do
or do not find that works.
Steven
>>Hmmm, I don't know much about this device, but it could be the problem. FFS
>>uses New Style Devices NSD for above 4 GB !
>What is NSD? I never heard of that.
New Style Devices (NSD) support 64 bit addressing, i.e. > 4GB.
>>Someone may know of an updated version of this device or Guru ROM.
>>Type in a CLI Shell, 'version omniscsi.device full' to get the version.
>It says omniscsi.device 1.10 (o4/03/95)
>>While you wait for an answer, go to Aminet and get SFS_BETA.lha, install it
>>in the partitions that don't show up with HDToolBox and quick format them.
>I will try that, but then will I need multi-filesystem or whatever it is
>called?
No.
>>I'm sure the solution is very near :-).
>I will have to keep trying. I've NEVER run into such a frustrating problem
>with my Amiga before......sheeeesh!
Thanks to Niels, you may now have found the solution :-).
John Deker
>>>CLI says setpatch version 44.13 has already been installed.
First, upgrade to SETPATCH v44.16. It can be found on the OS3.9 CDROM at:
AmigaOS3.9:OS-Version3.9/Emergency-Disk/C/SetPatch
There are several occurrances of version 44.13 on the CD, but the above path is
the only location for 44.16. This was obviously an oversight by H&P and AI.
The installer does not install the newest available SetPatch.
>>That's the correct version.
>>>>>Make sure the scsi.device and filesystem are updated.
>>>>I have omniscsi.device
>>>Setpatch says scsi.device has been patched but I use omniscsi.device....is
>>>that a problem?
Definitely. Per the instructions in NSDPatch.cfg (see below):
# For omniscsi.device 1.9 as used in some Guru-ROM's
# Yes, to patch omniscsi.device, you'll need the name gvpscsi.device!
#DEVICE gvpscsi.device DEVICETYPE NSDEVTYPE_TRACKDISK COMMANDS 2-5,9-15,20-
23,28
you would need to remove the "#" sign in front of DEVICE gvpscsi.device. I
don't recall what version of "omniscsi.device" you have, but hopefully
activating this line would work for you.
After activating the line and rebooting, try determining whether the patch is
activated by:
1. Opening a shell window
2. Type "setpatch pi >ram:setpatchinfo.txt" at the prompt to get the Patch Info
(pi) as to the status of all patches.
3. View the ram:setpatchinfo.txt file with MultiView or whatever.
You should see something like this within the long listing:
Current Patch-Status:
1230scsi.device patch use count 0 (7.0)
1230scsi.device patch use count 0
1233scsi.device patch use count 0 (7.0)
1233scsi.device patch use count 0
1234scsi.device patch use count 0 (7.0)
1234scsi.device patch use count 0
1260scsi.device patch use count 0 (7.0)
1260scsi.device patch use count 0
2060scsi.device patch use count 1 (7.0)
2060scsi.device patch use count 0
Note the next to last line above shows that 2060scsi.device on my system has
been patched as indicated by the "1" near the end of the line. GVPSCSI or
OmniSCSI should show something similar if you are successful.
>>Hmmm, I don't know much about this device, but it could be the problem. FFS
>>uses New Style Devices NSD for above 4 GB !
>What is NSD? I never heard of that.
Per an earlier msg posted here and to which you responded, New Style Devices
(NSD) has been incorporated into OS3.9 thru the use of C:SetPatch and
DEVS:NSDPatch.cfg. NSDPatch was available on Aminet before OS3.5 was released.
>>While you wait for an answer, go to Aminet and get SFS_BETA.lha, install it
>>in the partitions that don't show up with HDToolBox and quick format them.
>I will try that, but then will I need multi-filesystem or whatever it is
>called?
No. But, installing the new filesystem on a partition will destroy the data in
that partition. Backup the target partitions first if you have data you do not
want to lose.
>>SFS will work with NSD, TD64 and SCSI Direct.
>>Use 'SFSCheck <SFS partition>' and it will show the Device interface type.
>>BTW, PFS3 uses TD64 or SCSI Direct.
>>>Any more suggestions? I really want to use the full 6.4 gigs on that
>>>drive.
I highly recommend NOT using FFS for any partition greater than 2GB. If the FFS
gets corrupted, it will take a long time to validate and AFAIK, you could run
out of RAM before the validation completes.
Instead, use either SFS (shareware) or PFS3 (commercial ware). These
file systems are virtually indestructable and validation will become history for
the partitions that use these file systems. I personally use PFS3 on all my
partitions except my boot partition for possible compatibility reasons. My boot
partition is within the first 4GB on the disk and is smaller than 2GB as
required for an OS3.5/3.9 boot partition.
>I will have to keep trying. I've NEVER run into such a frustrating problem
>with my Amiga before......sheeeesh!
Amiga Inc only assures that large drives are supported if you use SCSI.DEVICE.
They've made reasonable attempts to support other drive interfaces, but it is
your responsibility to read and understand the documentation or to find someone
willing to help and advise you related to other drive interfaces. Not all third
party interfaces can be made to support large HD's. The interface manufacturer
is to blame in those rare cases.
=======================
I use ICQ and AmiComSys; ICQ ID#:78972393
Marcel DeVoe
[snip: hard drive problems]
> That's what I was afraid of....damn.....
>>>Help, please?
In comp.sys.amiga.hardware John Deker <jwd...@voicenet.com> wrote:
> In message on 07-Jan-01 20:16:14, Jim Woods wrote:
>>>>CLI says setpatch version 44.13 has already been installed.
>First, upgrade to SETPATCH v44.16. It can be found on the OS3.9 CDROM at:
> AmigaOS3.9:OS-Version3.9/Emergency-Disk/C/SetPatch
> There are several occurrances of version 44.13 on the CD, but the above
> path is the only location for 44.16. This was obviously an oversight by
> H&P and AI. The installer does not install the newest available SetPatch.
Sorry I can't help with your hard drive problem. But I read this thread
closely with interest and am very surprised about AOS3.9 not having
installed the latest SetPatch. Thanks John for posting that.
> Now I have a new problem, and here is a warning for all those who still use
> ToolsDaemon with OS3.9......now I know why they moved it out of WBStartup
> when it installed. You can use it without any problem until you want to
> change the menu. When you save the changes in the ToolsDaemon Prefs, the
> program crashes your computer and changes something in the boot startup
> routine, because after the crash you ban't reboot......it goes partway and
> then stops. I'm lucky I still have this 2.1 gig with everything still
> working. Grrrrrr!!!
This is probably low on your priority list of problems but FWIW I have
been using ToolsDeamon for a couple of weeks now with AOS3.9 and after a
couple of days use I added AWebSE into my "Internet" titled menus and
saved it no problem.
Of course I neglected to say I use PFS3, but didn't observe any crash at
the time.
--
Marcel J. DeVoe - mde...@shore.net - Team *AMIGA*
A4091scsi CV64 96 megs CDRW M1764-17" Catweasel FUSION/Emplant
A4000/060 CyberStorm MKII overclocked 66mhz - see "How to Overclock!"
and "DIY A4000 Tower for $45" @ http://www.shore.net/~mdevoe
Jim Woods
>AmigaOS3.9:OS-Version3.9/Emergency-Disk/C/SetPatch
Done
>There are several occurrances of version 44.13 on the CD, but the above path
>is the only location for 44.16. This was obviously an oversight by H&P and
>AI. The installer does not install the newest available SetPatch.
There is also a version 44.20, but that didn't work.
>>>>Setpatch says scsi.device has been patched but I use omniscsi.device....is
>>>>that a problem?
>Definitely. Per the instructions in NSDPatch.cfg (see below):
># For omniscsi.device 1.9 as used in some Guru-ROM's
># Yes, to patch omniscsi.device, you'll need the name gvpscsi.device!
>#DEVICE gvpscsi.device DEVICETYPE NSDEVTYPE_TRACKDISK COMMANDS
>2-5,9-15,20-
>23,28
>you would need to remove the "#" sign in front of DEVICE gvpscsi.device.
When I tried that with the text as it it, my 2000 wouln't boot.
> I
>don't recall what version of "omniscsi.device" you have, but hopefully
>activating this line would work for you.
The version it gives me in shell using "version omniscsi.device full" is
1.10
>After activating the line and rebooting, try determining whether the patch is
>activated by:
>1. Opening a shell window
>2. Type "setpatch pi >ram:setpatchinfo.txt" at the prompt to get the Patch
>Info
>(pi) as to the status of all patches.
>3. View the ram:setpatchinfo.txt file with MultiView or whatever.
>You should see something like this within the long listing:
>Current Patch-Status:
>1230scsi.device patch use count 0 (7.0)
>1230scsi.device patch use count 0
>1233scsi.device patch use count 0 (7.0)
>1233scsi.device patch use count 0
>1234scsi.device patch use count 0 (7.0)
>1234scsi.device patch use count 0
>1260scsi.device patch use count 0 (7.0)
>1260scsi.device patch use count 0
>2060scsi.device patch use count 1 (7.0)
>2060scsi.device patch use count 0
>Note the next to last line above shows that 2060scsi.device on my system has
>been patched as indicated by the "1" near the end of the line. GVPSCSI or
>OmniSCSI should show something similar if you are successful.
Here is my list as per your advice:
AMIGA ROM Operating System and Libraries
Copyright © 1985-2000 Amiga International, Inc.
All Rights Reserved.
SetPatch (V44.16) has already been installed. Patch list:
68040 Support Code Loaded
BOOL CheckIO() workaround
Enabled Advanced Graphics Modes
AmigaOS Copyright
ramlib signal usage
stack size check for CON:, RAW:, RAM:, PAR:, PRT:, SER:
graphics/WritePixelLine8()
graphics/WriteChunkyPixel()
Memory Pools
Enabled data cache
Current Patch-Status:
1230scsi.device patch use count 0
1260scsi.device patch use count 0
2060scsi.device patch use count 0
2nd.scsi.device patch use count 0 (43.22)
2nd.scsi.device patch use count 0 (43.0)
2nd.scsi.device patch use count 0 (40.20)
2nd.scsi.device patch use count 0
ExpSys.device patch use count 0
QuickNet.device patch use count 0
QuickNetS2.device patch use count 0 (2.3)
QuickNetS2.device patch use count 0
a2060.device patch use count 0 (40.9)
a2060.device patch use count 0
a2065.device patch use count 0 (3.0)
a2065.device patch use count 0
amoksana.device patch use count 0 (3.190)
amoksana.device patch use count 0 (3.189)
amoksana.device patch use count 0
ariadne.device patch use count 0 (1.47)
audio.device patch use count 1
cd.device patch use count 0
clipboard.device patch use count 0
console.device patch use count 1 (40.0)
console.device patch use count 0
cybppc.device patch use count 0
cybscsi.device patch use count 0
gameport.device patch use count 1
gg_ne1000.device patch use count 0 (37.7)
gg_ne1000.device patch use count 0
gg_ne2000.device patch use count 0 (37.7)
gg_ne2000.device patch use count 0
gvpscsi.device patch use count 1
hydra.device patch use count 0 (1.44)
hydra.device patch use count 0
icard.device patch use count 0 (1.5)
icard.device patch use count 0 (1.4)
icard.device patch use count 0
input.device patch use count 1
keyboard.device patch use count 1
mfm.device patch use count 1
parallel.device patch use count 0
printer.device patch use count 0
ramdrive.device patch use count 1
scsi.device patch use count 0 (43.22)
scsi.device patch use count 0 (43.0)
scsi.device patch use count 0 (40.20)
scsi.device patch use count 0
serial.device patch use count 0 (43.0)
serial.device patch use count 0
slip.device patch use count 0
tekscsi2.device patch use count 0
timer.device patch use count 1
trackdisk.device patch use count 1
wildfirescsi.device patch use count 0 (1.1)
z3scsi.device patch use count 0
ROM updates installed by SetPatch:
console.device, console 44.6 (31.3.2000)
ram-handler, ram 44.21 (2.9.2000)
scsi.device, IDE_scsidisk 43.35 (28.12.99)
FileSystem.resource, filesysres 45.7 (17.9.2000)
filesystem, fs 45.9 (3.9.2000)
AmigaOS ROM Update, ROMUpdate 44.26 (17.9.2000)
According to the above, gvpscsi.device is activated, but I don't know which
version of omniscsi.device this includes. They mention version 1.19 in their
text, but my version is 1.10 and I'm not sure if or where in the NSDPatch.cfg
to add my version or if it is even possible.
Can you make any suggestions here?
BTW my last partitions are still missing.
>>>While you wait for an answer, go to Aminet and get SFS_BETA.lha, install it
>>>in the partitions that don't show up with HDToolBox and quick format them.
>>I will try that, but then will I need multi-filesystem or whatever it is
>>called?
>No. But, installing the new filesystem on a partition will destroy the data
>in that partition. Backup the target partitions first if you have data you
>do not want to lose.
Heh heh heh, what data? I can't get the partitions to show up :-)
>>>SFS will work with NSD, TD64 and SCSI Direct.
>>>Use 'SFSCheck <SFS partition>' and it will show the Device interface type.
>>>BTW, PFS3 uses TD64 or SCSI Direct.
>>>>Any more suggestions? I really want to use the full 6.4 gigs on that
>>>>drive.
>I highly recommend NOT using FFS for any partition greater than 2GB. If the
>FFS gets corrupted, it will take a long time to validate and AFAIK, you could
>run out of RAM before the validation completes.
I have no partitions larger or even close to 2 gigs, so that shouldn't be a
problem for me there. I did find that having partitions that lapped over
the 4 gig limit of FFS caused my computer to hang up when booting, usually
where it tries to "load Amidock"
>Instead, use either SFS (shareware) or PFS3 (commercial ware). These
>file systems are virtually indestructable and validation will become history
>for the partitions that use these file systems. I personally use PFS3 on all
>my partitions except my boot partition for possible compatibility reasons.
>My boot partition is within the first 4GB on the disk and is smaller than 2GB
>as required for an OS3.5/3.9 boot partition.
I would prefer to use FFS for all, but that is definitely a consideration.
>>I will have to keep trying. I've NEVER run into such a frustrating problem
>>with my Amiga before......sheeeesh!
>Amiga Inc only assures that large drives are supported if you use
>SCSI.DEVICE. They've made reasonable attempts to support other drive
>interfaces, but it is your responsibility to read and understand the
>documentation or to find someone willing to help and advise you related to
>other drive interfaces. Not all third party interfaces can be made to
>support large HD's. The interface manufacturer is to blame in those rare
>cases.
Sounds like politics :-)
Thanks very much for your input regarding this.....it is most appreciated.
--
Jim Woods <jwo...@travel-net.com>
Jim Woods
>New Style Devices (NSD) support 64 bit addressing, i.e. > 4GB.
Thanks for that info Steve.
>>>While you wait for an answer, go to Aminet and get SFS_BETA.lha, install it
>>>in the partitions that don't show up with HDToolBox and quick format them.
That didn't work either.
>>>I'm sure the solution is very near :-).
For someone who understands filesystems, maybe :-)
>>I will have to keep trying. I've NEVER run into such a frustrating problem
>>with my Amiga before......sheeeesh!
>Thanks to Niels, you may now have found the solution :-).
Yes, if I can figure out what to do with the solution.
>Good Luck,
> Steven
Thanks for your time and input, Steve.
Jim Woods
>> ToolsDaemon with OS3.9......now I know why they moved it out of WBStartup
>> when it installed. You can use it without any problem until you want to
>> change the menu. When you save the changes in the ToolsDaemon Prefs, the
>> program crashes your computer and changes something in the boot startup
>> routine, because after the crash you ban't reboot......it goes partway and
>> then stops. I'm lucky I still have this 2.1 gig with everything still
>> working. Grrrrrr!!!
>This is probably low on your priority list of problems but FWIW I have
>been using ToolsDeamon for a couple of weeks now with AOS3.9 and after a
>couple of days use I added AWebSE into my "Internet" titled menus and
>saved it no problem.
Maybe my problem saving the new menu has something to do with other stuff
I run on my system conflicting with OS3.9
>Of course I neglected to say I use PFS3, but didn't observe any crash at
>the time.
Well I won't be trying to find out what causes my crashes, because the crashes
are too severe......i.e. my computer won't boot at all. It takes a second
drive to boot from, then mount the bad drive using scsi mounter and copy the
files back that were corrupted. What a hassle. At least with an Amiga you
CAN do things like that.
Thanks for your input, Marcel.
Joe Cosby
feverishly;
thunder crashed, Steven <sn...@smallfoot.com> laughed madly, then
wrote:
Just out of curiosity ... has anyone here ever had a serious problem
with PFS3?
It sounds like a great system, the only problem being the
unavailability of something like Disksalv for it. I'm just curious if
anybody has ever had a problem bad enough to need disksalv.
--
Joe Cosby
http://joecosby.home.mindspring.com
I had fried octopus last night. You have to be really quiet when you
eat it. Otherwise, it emits a cloud of black smoke and falls on the
floor.
-- Steven Wright
Sig by Kookie Jar 5.98d http://go.to/generalfrenetics/
Steven
>>>>While you wait for an answer, go to Aminet and get SFS_BETA.lha, install
>>>>it in the partitions that don't show up with HDToolBox and quick format
>>>>them.
>That didn't work either.
Hmmm, SFS should work with any device capable of >4 GB access :-(.
This is why I suggested trying it, and why I would still try to get it working !
Try using SFSFormat, what does 'SFSquery <Partition Name e.g. IDH7:>' say ?
>>>>I'm sure the solution is very near :-).
>For someone who understands filesystems, maybe :-)
The filesystems are fine, it's your omniscsi.device you need to worry about ;-).
>>Thanks to Niels, you may now have found the solution :-).
>Yes, if I can figure out what to do with the solution.
Your omniscsi.device 1.10 is not a NSD, but it now looks like it may also not do
TD64 or SCSI Direct (SFS failing) :-/.
BTW, if this is true, not even PFS3 would work.
The only way would be to replace your omniscsi.device with a newer version,
maybe by getting a replacement GVP Guru ROM !
NSDPatch.cfg talks about patching omniscsi.device 1.9, which seems to be a lower
version than yours (unless they mean 1.90 or yours is just 1.1 !) :-/.
Someone with more GVP knowledge may know of a patch or replacement device for
your card, good luck.
>Thanks for your time and input, Steve.
I just hope you get it fully working :-).
Best Regards,
Niels Bache
> >> Now I have a new problem, and here is a warning for all those who still use
> >> ToolsDaemon with OS3.9......now I know why they moved it out of WBStartup
[...]
> >This is probably low on your priority list of problems but FWIW I have
> >been using ToolsDeamon for a couple of weeks now with AOS3.9 and after a
> >couple of days use I added AWebSE into my "Internet" titled menus and
> >saved it no problem.
>
> Maybe my problem saving the new menu has something to do with other stuff
> I run on my system conflicting with OS3.9
Or maybe the other way around: I have seen reports that the problem
disappears if you *also* run MagicMenu. Maybe Marcel does that and you
don't?
Niels Bache
[...]
> There is also a version 44.20, but that didn't work.
Of SetPatch? Are you sure? That sounds weird, that's not supposed to
exist as far as I know.
Where on the CD did you find that (path)?
Niels Bache
[...]
> I found the line and it says for omniscsi, I need the GVPscsi line. That one
> followed immediately with the # sign, so I deleted that #. I have a backup if
> that is not correct. This is an area that is more technical than I am used
> to handling, but, hey, I will try anyhing :-)
Yes, that is what I meant for you to try. Make sure that the line is
still in one piece (it has been broken with line feeds in the two other
posts in this thread where I saw it quoted).
[...]
> >Oh, and make sure you are using the newest of those config files. There
> >was a time (BB1?) where a new file was installed with a name like
> >NSDPatch.cfg-new or something, but you had to go in yourself and rename
> >it to NSDPatch.cfg after carrying over any modifications you had made in
> >the old one.
>
> I'm not sure which version I have OR which is newest...I will have to check.
Well, just check if you have both a DEVS:NSDPatch.cfg and a
DEVS:NSDPatch.cfg-new (I think it was -- something like that, anyway).
If you do, you need to rename the "-new" one to just be
DEVS:NSDPatch.cfg after saving the other one, and possibly carry over
any previous modifications.
Niels Bache
[...]
> Instead, use either SFS (shareware) or PFS3 (commercial ware). These
> file systems are virtually indestructable and validation will become history for
On the other hand, FFS has become *much* more stable with the last two
OS releases. It hasn't invalidated any partitions here for quite some
time now.
Steven
>Just out of curiosity ... has anyone here ever had a serious problem
>with PFS3?
It's not a serious problem, but it can't be used with devices that have block
sizes above 1024 bytes. This doesn't really affect HDD's anyway (512 bytes).
>It sounds like a great system, the only problem being the
>unavailability of something like Disksalv for it. I'm just curious if
>anybody has ever had a problem bad enough to need disksalv.
It has a repair tool PFSDoctor, pfssalv.lha is also available on Aminet.
Regards,
Patrick Ford
>
> Here is my list as per your advice:
WOW! Have you really got a dozen scsi controllers and six or so
network cards? To need to patch all those devices, you must have a 25
slot Zorro board!
--
Patrick Ford
Auckland, New Zealand
Patrick Ford
> Just out of curiosity ... has anyone here ever had a serious problem
> with PFS3?
> It sounds like a great system, the only problem being the
> unavailability of something like Disksalv for it. I'm just curious if
> anybody has ever had a problem bad enough to need disksalv.
What shortcomings has the supplied PFS3 pfsdoctor got, that you
would want to use Disksalv?
Jim Woods
>[...]
>> Instead, use either SFS (shareware) or PFS3 (commercial ware). These
>> file systems are virtually indestructable and validation will become
>> history for
>On the other hand, FFS has become *much* more stable with the last two
>OS releases. It hasn't invalidated any partitions here for quite some
>time now.
Not here......I have been having trouble copying large directories from one
hard disk to another because of a PC power supply that craps out in the middle.
Then I have one helluva time getting booted back up.
Jim Woods
>[...]
>> I found the line and it says for omniscsi, I need the GVPscsi line. That
>> one followed immediately with the # sign, so I deleted that #. I have a
>> backup if that is not correct. This is an area that is more technical than
>> I am used to handling, but, hey, I will try anyhing :-)
>Yes, that is what I meant for you to try. Make sure that the line is
>still in one piece (it has been broken with line feeds in the two other
>posts in this thread where I saw it quoted).
I think it's in one string.
>[...]
>> >Oh, and make sure you are using the newest of those config files. There
>> >was a time (BB1?) where a new file was installed with a name like
>> >NSDPatch.cfg-new or something, but you had to go in yourself and rename
>> >it to NSDPatch.cfg after carrying over any modifications you had made in
>> >the old one.
>>
>> I'm not sure which version I have OR which is newest...I will have to
>> check.
>Well, just check if you have both a DEVS:NSDPatch.cfg and a
>DEVS:NSDPatch.cfg-new (I think it was -- something like that, anyway).
>If you do, you need to rename the "-new" one to just be
>DEVS:NSDPatch.cfg after saving the other one, and possibly carry over
>any previous modifications.
I have tried both, but I'm still missing my partitions.
Am I supposed to have both files for it to work?
Jim Woods
>[...]
>> There is also a version 44.20, but that didn't work.
>Of SetPatch? Are you sure? That sounds weird, that's not supposed to
>exist as far as I know.
>Where on the CD did you find that (path)?
It is in one of the install directories, I can't remember which one now.
Jim Woods
>> I run on my system conflicting with OS3.9
>Or maybe the other way around: I have seen reports that the problem
>disappears if you *also* run MagicMenu. Maybe Marcel does that and you
>don't?
I use Magic Menu version II......the latest one. I have always used
magicmenu......I couldn't get along without it.
Jim Woods
>>>>>While you wait for an answer, go to Aminet and get SFS_BETA.lha, install
>>>>>it in the partitions that don't show up with HDToolBox and quick format
>>>>>them.
>>That didn't work either.
>Hmmm, SFS should work with any device capable of >4 GB access :-(.
>This is why I suggested trying it, and why I would still try to get it
>working !
>Try using SFSFormat, what does 'SFSquery <Partition Name e.g. IDH7:>' say ?
I have re-installed FFS, based on other info I have read here.
>>For someone who understands filesystems, maybe :-)
>The filesystems are fine, it's your omniscsi.device you need to worry about
I think you may be right here, but it's a GuruRom 6.1 and I believe ther are
only versions 6.11 and maybe 6.13 above that.
>Your omniscsi.device 1.10 is not a NSD, but it now looks like it may also not
>do TD64 or SCSI Direct (SFS failing) :-/.
How do you know that? I don't see that in the NSDPatch.config.....just a
mention of version 1.19
>BTW, if this is true, not even PFS3 would work.
<sigh>
>The only way would be to replace your omniscsi.device with a newer version,
>maybe by getting a replacement GVP Guru ROM !
They are har to come by these days.
>NSDPatch.cfg talks about patching omniscsi.device 1.9, which seems to be a
>lower version than yours (unless they mean 1.90 or yours is just 1.1 !) :-/.
>Someone with more GVP knowledge may know of a patch or replacement device for
>your card, good luck.
Anyone familiar with GuruRoms out there???
>>Thanks for your time and input, Steve.
>I just hope you get it fully working :-).
So do I......thanks again.
Jim Woods
Patrick, as I understand this, and I may be wrong, the devices patched are only
those with a 1 following the lines, so there are actually only a few patches.
Steven
>>Hmmm, SFS should work with any device capable of >4 GB access :-(.
>>This is why I suggested trying it, and why I would still try to get it
>>working !
>>Try using SFSFormat, what does 'SFSquery <Partition Name e.g. IDH7:>' say ?
> I have re-installed FFS, based on other info I have read here.
BTW, did you try using the name gvpscsi.device instead of omniscsi.device :-/.
>>>For someone who understands filesystems, maybe :-)
>>The filesystems are fine, it's your omniscsi.device you need to worry about
>I think you may be right here, but it's a GuruRom 6.1 and I believe ther are
>only versions 6.11 and maybe 6.13 above that.
Before you give up, try installing SFS on a empty working partition (to make
sure it's installed correctly) and on a non working partition (> 4 GB).
Then use SFSFormat and SFSquery.
>>Your omniscsi.device 1.10 is not a NSD, but it now looks like it may also
>>not do TD64 or SCSI Direct (SFS failing) :-/.
>How do you know that?
OS3.9 FFS should work without a patch if it's a NSD device !
SFS should also work with TD64 and SCSI Direct, so it failing could mean
omniscsi.device doesn't support those methods of access either !
AFAIK, if it did, the NSDPatch could then patch the omniscsi.device to convert
NSD commands into either SCSI Direct or TD64 commands :-/.
I'll have a more detailed look at the NSDPatch system.
>I don't see that in the NSDPatch.config.....just a mention of version 1.19
In my NSDPatch.config
'# For omniscsi.device *1.9* as used in some Guru-ROM's'
>>The only way would be to replace your omniscsi.device with a newer version,
>>maybe by getting a replacement GVP Guru ROM !
>They are har to come by these days.
I've seen your wanted advert, I would wait for more advice. It may still be
possible to get it working with your GuruROM version, I just don't know :-/.
Niels Bache
> >Den 8/04-2004 kl. 1:54:24 skrev Jim Woods (jwo...@travel-net.com):
>
> >> There is also a version 44.20, but that didn't work.
[...]
> >Where on the CD did you find that (path)?
>
>
> It is in one of the install directories, I can't remember which one now.
[...]
OK, I just checked the entire CD. There are 5 occurrences of SetPatch,
as follows
> version AmigaOS3.9:Emergency-Boot/C/SetPatch file full
setpatch 44.13 (2000/03/05)
> version AmigaOS3.9:OS-Version3.9/Emergency-Disk/C/SetPatch file full
setpatch 44.16 (2000/09/15)
> version AmigaOS3.9:OS-Version3.9/First-Install/c/SetPatch file full
setpatch 44.2 (1999/10/04)
> version AmigaOS3.9:OS-Version3.9/Workbench3.5/C/SetPatch file full
setpatch 44.13 (2000/03/05)
> version AmigaOS3.9:OS-Version3.9/Workbench3.9/C/SetPatch file full
setpatch 44.13 (2000/03/05)
So one is as old as 44.2, three are 44.13, and one (in the emergency
disk's C directory) is the newest 44.16.
(You didn't mix up 44.2 and 44.20, did you?)
Niels Bache
[quoting me...]
> >On the other hand, FFS has become *much* more stable with the last two
> >OS releases. It hasn't invalidated any partitions here for quite some
> >time now.
>
> Not here......I have been having trouble copying large directories from one
> hard disk to another because of a PC power supply that craps out in the middle.
> Then I have one helluva time getting booted back up.
Ah. Actually, when I thought about it again, some of the more
significant improvements may not have happened until FFS v45.9, which is
what is in Boing Bag 2 (for OS 3.5) and in OS 3.9. So my statement about
"the last two OS releases" might have been a little misleading (although
stability was also improved back in the original OS 3.5 version over
previous ones).
If you are using any lower version of FFS on the drive(s) in question,
you might benefit from updating it. It can't improve your PSU, but it
might help you to avoid invalidating your disk when the PSU does fail.
Niels Bache
[...]
> >Yes, that is what I meant for you to try. Make sure that the line is
> >still in one piece (it has been broken with line feeds in the two other
> >posts in this thread where I saw it quoted).
>
> I think it's in one string.
OK, then that's not it. It probably is the version, as you are
discussing elsewhere in the thread.
[...]
> >Well, just check if you have both a DEVS:NSDPatch.cfg and a
> >DEVS:NSDPatch.cfg-new (I think it was -- something like that, anyway).
> >If you do, you need to rename the "-new" one to just be
> >DEVS:NSDPatch.cfg after saving the other one, and possibly carry over
> >any previous modifications.
>
> I have tried both, but I'm still missing my partitions.
> Am I supposed to have both files for it to work?
No, SetPatch only looks for the one called NSDPatch.cfg. The other one
was just installed with BB1 (I think it was) and put there with a name
that kept it from overwriting the original one in case users had made
modifications they wanted to keep. Only the instructions about carrying
over the modifications, deleting the old file, and renaming the new to
the original name were either missing or at least not evident to most
users (I don't remember which).
Joe Cosby
feverishly;
thunder crashed, "Patrick Ford" <pa...@ihug.co.nz> laughed madly, then
wrote:
I didn't know there was a recover utility.
I'm not using PFS, I was just curious. I was interested when it first
came out, it looks like a great product and a great bragging item for
the Amiga; when I was still using native Amiga, I was afraid to try
it because, at the time, there was no recover utility.
--
Joe Cosby
http://joecosby.home.mindspring.com
False Memories Do Not Exist!
Jim Woods
>setpatch 44.13 (2000/03/05)
>> version AmigaOS3.9:OS-Version3.9/Emergency-Disk/C/SetPatch file full
>setpatch 44.16 (2000/09/15)
>> version AmigaOS3.9:OS-Version3.9/First-Install/c/SetPatch file full
>setpatch 44.2 (1999/10/04)
>> version AmigaOS3.9:OS-Version3.9/Workbench3.5/C/SetPatch file full
>setpatch 44.13 (2000/03/05)
>> version AmigaOS3.9:OS-Version3.9/Workbench3.9/C/SetPatch file full
>setpatch 44.13 (2000/03/05)
>So one is as old as 44.2, three are 44.13, and one (in the emergency
>disk's C directory) is the newest 44.16.
>(You didn't mix up 44.2 and 44.20, did you?)
I guess I figured 44.2 meant 44.20, which,as the way programmers mark their
files.
Jim Woods
>>[...]
>>> There is also a version 44.20, but that didn't work.
>>Of SetPatch? Are you sure? That sounds weird, that's not supposed to
>>exist as far as I know.
>>Where on the CD did you find that (path)?
>It is in one of the install directories, I can't remember which one now.
My system is back up now after a crash last night and I was unable to search
for the file. It is in OS3.9/First-Install/C
The version there is 44.2 (maybe I thought that meant 44.20)
Jim Woods
In the NSDPatch.config they say that omniscsi.device is treated like
gvpscsi.device for the patch.
As far as changing physically, that can't be done because the controller has
the GuruRom installed and it decides on the scsi name. I remember that when I
switched roms I had to change a whole whack of tooltypes, including HDToolbox.
>>>>For someone who understands filesystems, maybe :-)
>>>The filesystems are fine, it's your omniscsi.device you need to worry about
>>I think you may be right here, but it's a GuruRom 6.1 and I believe ther are
>>only versions 6.11 and maybe 6.13 above that.
>Before you give up, try installing SFS on a empty working partition (to make
>sure it's installed correctly) and on a non working partition (> 4 GB).
>Then use SFSFormat and SFSquery.
I did install SFS on the 2 partitions and they still were invisible. I didn't
try to use SFSFormat, though.
From what others have told me here, I have to patch my device, but that
appears to be not-do-able.
>>>Your omniscsi.device 1.10 is not a NSD, but it now looks like it may also
>>>not do TD64 or SCSI Direct (SFS failing) :-/.
>>How do you know that?
>OS3.9 FFS should work without a patch if it's a NSD device !
>SFS should also work with TD64 and SCSI Direct, so it failing could mean
>omniscsi.device doesn't support those methods of access either !
I need someone who knows to tell me for sure if omniscsi.device v1.10 falls
into the realm of that patch.
>AFAIK, if it did, the NSDPatch could then patch the omniscsi.device to
>convert NSD commands into either SCSI Direct or TD64 commands :-/.
That is what I don't know, but I need to know.
>I'll have a more detailed look at the NSDPatch system.
Maybe you will see something I didn't, I hope. I have problems, sometimes,
grasping long text because of a stroke I had a few years ago. I have trouble
just reading the newspaper, and following the credits on a movie is impossible
for me.
>>I don't see that in the NSDPatch.config.....just a mention of version 1.19
>In my NSDPatch.config
>'# For omniscsi.device *1.9* as used in some Guru-ROM's'
I saw that, but my version is 1.10, so I don't know if the patch was written
to cover that.
>>>The only way would be to replace your omniscsi.device with a newer version,
>>>maybe by getting a replacement GVP Guru ROM !
>>They are har to come by these days.
>I've seen your wanted advert, I would wait for more advice. It may still be
>possible to get it working with your GuruROM version, I just don't know :-/.
I really hope so....thanks
Jim Woods
>> hard disk to another because of a PC power supply that craps out in the
>> middle. Then I have one helluva time getting booted back up.
>Ah. Actually, when I thought about it again, some of the more
>significant improvements may not have happened until FFS v45.9, which is
>what is in Boing Bag 2 (for OS 3.5) and in OS 3.9. So my statement about
>"the last two OS releases" might have been a little misleading (although
>stability was also improved back in the original OS 3.5 version over
>previous ones).
I had an older version on my drive before upgrading.
>If you are using any lower version of FFS on the drive(s) in question,
>you might benefit from updating it. It can't improve your PSU, but it
>might help you to avoid invalidating your disk when the PSU does fail.
I will gladly update my filesystem everywhere when I get my problems sorted
out. I am afraid to change my old drive and not ne able to boot at all.
As it is, when I reboot after a failure to "complete a write" my 2000 starts
to boot from my old drive, but stops very soon after it starts, then I must
cold-reboot with my new 6 gig drive unplugged from the scsi chain. Then, after
getting rebooted, I plug the drive back onto the ribbon cable, use scsimounter
and everything comes up. Then I delete the directory I was copying and start
again. This is the ONLY way I could get it to boot....it wouln'd even boot
from a floppy, it would start reading the floppy, go back to reading the
hard drive and stop without going back to the floppy again.
Patrick Ford
> >> It sounds like a great system, the only problem being the
> >> unavailability of something like Disksalv for it. I'm just curious if
> >> anybody has ever had a problem bad enough to need disksalv.
> >
> >What shortcomings has the supplied PFS3 pfsdoctor got, that you
> >would want to use Disksalv?
>
> I didn't know there was a recover utility.
>
> I'm not using PFS, I was just curious. I was interested when it first
> came out, it looks like a great product and a great bragging item for
> the Amiga; when I was still using native Amiga, I was afraid to try
> it because, at the time, there was no recover utility.
with a drive that was physically dying. Before I got it Iwas regularly
using Disksalv on FFS partitions. Get PFS3--it won't let you down.
Patrick Ford
> >On 8 Jan 2001 14:0:37 -0500, Jim Woods <jwo...@travel-net.com> wrote:
>
> Patrick, as I understand this, and I may be wrong, the devices patched are only
> those with a 1 following the lines, so there are actually only a few patches.
bootup.
Steven
This is getting a little complex and if it's alright with you I'd like to
simplify it ;-).
Forget for the moment about FFS and patches, and lets try to get SFS working.
SFS is extremely flexible and should work on any system capable of >4GB access.
The guide even mentions your omniscsi.device :-).
This all applies to your new 6 gig HDD which should have nothing of any value
stored on it.
Using HDToolBox 'Add/Update...' 'l:SmartFilesystem', remember to set the dos
type to '0x53465300' if it's needed.
Install SFS on a known to be working but empty FFS partition (e.g. IDH1:), by
'Change...' the filesystem.
Install SFS on a non working partition (> 4 GB e.g. IDH6:) in the same way.
Save the changes and re-boot.
Use SFSFormat instead of the normal format for both partition.
You should now have at _least_ one formatted SFS partition, hopefully you have
two SFS partitions.
SFSquery both partitions to see how SFS is using your 'omniscsi.device'.
>From what others have told me here, I have to patch my device, but that appears
>to be not-do-able.
Don't give up, just yet ;-).
These results should give clue to what is possible :-).
>>'# For omniscsi.device *1.9* as used in some Guru-ROM's'
>I saw that, but my version is 1.10, so I don't know if the patch was written
>to cover that.
I would have thought if it works with 1.9, then it should be possible to get
it to work with 1.10, this is why I still have hope of a solution :-).
Marcel DeVoe
> Den 8/01-2001 kl. 13:18:29 skrev Jim Woods (jwo...@travel-net.com):
>> >> Now I have a new problem, and here is a warning for all those who still use
>> >> ToolsDaemon with OS3.9......now I know why they moved it out of WBStartup
> [...]
>> >This is probably low on your priority list of problems but FWIW I have
>> >been using ToolsDeamon for a couple of weeks now with AOS3.9 and after a
>> >couple of days use I added AWebSE into my "Internet" titled menus and
>> >saved it no problem.
>>
>> Maybe my problem saving the new menu has something to do with other stuff
>> I run on my system conflicting with OS3.9
> Or maybe the other way around: I have seen reports that the problem
> disappears if you *also* run MagicMenu. Maybe Marcel does that and you
> don't?
Heh! I DO have MagicMenus also. Wouldn't do without it. But maybe I'll try
disabling that to see if things get worse.
But OTOH, I HAVE been seeing some unsual lockups lately since installing
AOS3.9 over 3.5. Programs such as IBrowse would suddenly stop responding
to mouse clicks while YAM and MIAMI3.2b and DirOpus 4 on it's own screen
would, and the only way to get going again is to reboot.
--
Marcel J. DeVoe - mde...@shore.net - Team *AMIGA*
A4091scsi CV64 96 megs CDRW M1764-17" Catweasel FUSION/Emplant
A4000/060 CyberStorm MKII overclocked 66mhz - see "How to Overclock!"
and "DIY A4000 Tower for $45" @ http://www.shore.net/~mdevoe
Marcel DeVoe
>>The filesystems are fine, it's your omniscsi.device you need to worry about
> I think you may be right here, but it's a GuruRom 6.1 and I believe ther are
> only versions 6.11 and maybe 6.13 above that.
6.13 (what is written on the chip's label) is the one I have for my 2091A
controller in my A2000. I believe that was the last version.
>>Your omniscsi.device 1.10 is not a NSD, but it now looks like it may also not
>>do TD64 or SCSI Direct (SFS failing) :-/.
> How do you know that? I don't see that in the NSDPatch.config.....just a
> mention of version 1.19
Unfortunately having not installed the GURU-ROM yet I can't comment what
version omniscsi.device gives. :-(
>>The only way would be to replace your omniscsi.device with a newer version,
>>maybe by getting a replacement GVP Guru ROM !
> They are har to come by these days.
Have you checked Software Hut?
>>NSDPatch.cfg talks about patching omniscsi.device 1.9, which seems to be a
>>lower version than yours (unless they mean 1.90 or yours is just 1.1 !) :-/.
>>Someone with more GVP knowledge may know of a patch or replacement device for
>>your card, good luck.
> Anyone familiar with GuruRoms out there???
Even if you had a EEPROM programmer, I don't think you're going to find
the latest file to burn into it, unless you can convince the original
programmer to send it to you.
You may just have to purchase the newer GURU-ROM, or get a different
controller board. The Spitfire or the RapidFire is supposed to be good. I
think they may be still available.
Marcel DeVoe
> I will gladly update my filesystem everywhere when I get my problems sorted
> out. I am afraid to change my old drive and not ne able to boot at all.
> As it is, when I reboot after a failure to "complete a write" my 2000 starts
> to boot from my old drive, but stops very soon after it starts, then I must
> cold-reboot with my new 6 gig drive unplugged from the scsi chain. Then, after
> getting rebooted, I plug the drive back onto the ribbon cable, use scsimounter
> and everything comes up. Then I delete the directory I was copying and start
> again. This is the ONLY way I could get it to boot....it wouln'd even boot
> from a floppy, it would start reading the floppy, go back to reading the
> hard drive and stop without going back to the floppy again.
Hmm, I'm beginning to wonder now if your drive is naff? Try a different
ribbon cable or check your SCSI ID# to make sure it doesn't conflict?
Are you terminating the drives correctly, only at each of the very ends
of the chain and with like terminators?
You say the PC supply fails occasionally? Did you check the voltages to
see if you have at least greater than 4.8v on the 5 volt line and >11
volts on the two 12 volt lines.
Have you thought about trying another drive?
Niels Bache
[...]
> >(You didn't mix up 44.2 and 44.20, did you?)
>
> I guess I figured 44.2 meant 44.20, which,as the way programmers mark their
> files.
Not if they follow the standards, they don't. The number behind the
dividing symbol (which happens to look a little like a decimal point) is
a revision number which is totally independent from the number before
it. This is how all system components in AmigaOS (and by example also
stuff from many others) are given internal version.revision numbers,
which is what we are referring to here.
It's a common misunderstanding, though, especially as there is also such
a thing as a "marketing" version. This is e.g. 3.9 for the latest
AmigaOS. And those usually follow the decimal number rules.
It's a fine mess...
Niels Bache
> In comp.sys.amiga.hardware Jim Woods <jwo...@travel-net.com> wrote:
[...]
> > cold-reboot with my new 6 gig drive unplugged from the scsi chain. Then, after
> > getting rebooted, I plug the drive back onto the ribbon cable, use scsimounter
[...]
> Hmm, I'm beginning to wonder now if your drive is naff? Try a different
> ribbon cable or check your SCSI ID# to make sure it doesn't conflict?
>
> Are you terminating the drives correctly, only at each of the very ends
> of the chain and with like terminators?
Also, is it really safe to hot-plug SCSI devices? I have no idea, but I
wouldn't have dared trying it myself ;-)
[...]
Niels Bache
[...]
> Heh! I DO have MagicMenus also. Wouldn't do without it. But maybe I'll try
> disabling that to see if things get worse.
Yeah, well, Jim did use it too, so apparently it's not that simple.
Mark Lynn
wrote:
>>On the other hand, FFS has become *much* more stable with the last two
>>OS releases. It hasn't invalidated any partitions here for quite some
>>time now.
>
>
>Not here......I have been having trouble copying large directories from one
>hard disk to another because of a PC power supply that craps out in the middle.
>Then I have one helluva time getting booted back up.
I know how you feel, I have exactly the same problem here at the
moment and I`m on the lookout for a cheap power supply.
--
Mark.
To e-mail add lynn after me
Marcel DeVoe
> I am using OS3.9 with FFS 45.1 that came with it. I was under the impression
> that FFS was fixed to handle larger drives than 4 gigs.....but I just
> installeda 6.1 gig drive using HDToolbox and all went well. That is, it
> recognized the drive as 6 gigs, and I was able to partition it very easily,
[snip: repeated posting]
Say Jim. Could you do something about deleting this particular article?
It somehow got dated at 2004. That means it's may to be on my server for
the next *3 years!*
SG
> In comp.sys.amiga.hardware Niels Bache <nba...@post5.tele.dk> wrote:
> > Den 8/01-2001 kl. 13:18:29 skrev Jim Woods (jwo...@travel-net.com):
>
> >> >> Now I have a new problem, and here is a warning for all those who still use
> >> >> ToolsDaemon with OS3.9......now I know why they moved it out of WBStartup
>
> > [...]
>
> >> >This is probably low on your priority list of problems but FWIW I have
> >> >been using ToolsDeamon for a couple of weeks now with AOS3.9 and after a
> >> >couple of days use I added AWebSE into my "Internet" titled menus and
> >> >saved it no problem.
> >>
> >> Maybe my problem saving the new menu has something to do with other stuff
> >> I run on my system conflicting with OS3.9
>
> > Or maybe the other way around: I have seen reports that the problem
> > disappears if you *also* run MagicMenu. Maybe Marcel does that and you
> > don't?
>
> Heh! I DO have MagicMenus also. Wouldn't do without it. But maybe I'll try
> disabling that to see if things get worse.
>
> But OTOH, I HAVE been seeing some unsual lockups lately since installing
> AOS3.9 over 3.5. Programs such as IBrowse would suddenly stop responding
> to mouse clicks while YAM and MIAMI3.2b and DirOpus 4 on it's own screen
> would, and the only way to get going again is to reboot.
I use all that software with 3.9 (including MagicMenus), with no
problems at all. Are you using IB2.2? Some of the early IB2.X
versions might cause behavior like that.
--
Steve.
Marcel DeVoe
> Marcel DeVoe<mde...@shore.net> wrote:
>> But OTOH, I HAVE been seeing some unsual lockups lately since installing
>> AOS3.9 over 3.5. Programs such as IBrowse would suddenly stop responding
>> to mouse clicks while YAM and MIAMI3.2b and DirOpus 4 on it's own screen
>> would, and the only way to get going again is to reboot.
> I use all that software with 3.9 (including MagicMenus), with no
> problems at all. Are you using IB2.2? Some of the early IB2.X
> versions might cause behavior like that.
Yes, it's IB2.2. I think it may be more probably YAM though. I'm still
using an earlier version, 1.3.x. It was GURU'ing in AOS3.1 fairly often,
but stopped in AOS3.5. Now it's happening again in 3.9 but without the
GURU, IB just comes to a dead stop. But it most often happens when I'm
running both YAM and IB concurently. YAM closes down properly though.
Strange.
Mike Leavitt
> In comp.sys.amiga.hardware SG <sg...@erols.com> wrote:
> > Marcel DeVoe<mde...@shore.net> wrote:
> >> But OTOH, I HAVE been seeing some unsual lockups lately since installing
> >> AOS3.9 over 3.5. Programs such as IBrowse would suddenly stop responding
> >> to mouse clicks while YAM and MIAMI3.2b and DirOpus 4 on it's own screen
> >> would, and the only way to get going again is to reboot.
>
> > I use all that software with 3.9 (including MagicMenus), with no
> > problems at all. Are you using IB2.2? Some of the early IB2.X
> > versions might cause behavior like that.
>
> Yes, it's IB2.2. I think it may be more probably YAM though. I'm still
> using an earlier version, 1.3.x. It was GURU'ing in AOS3.1 fairly often,
> but stopped in AOS3.5. Now it's happening again in 3.9 but without the
> GURU, IB just comes to a dead stop. But it most often happens when I'm
> Strange.
YAM and IB both work perfectly, even together here under 3.9. What else
are you running (MCP perhaps?) Of course I run YAM 2.2, haven't tried
1.3.5 in years, so you may be right about the version. Time for an
upgrade, I suspect. 2.2 has its quirks, but you will get used to it. I
never had any trouble with 1.3.5 under 3.1 though. It was rock solid.
--
Mike Leavitt ac...@lafn.org + team Amiga +
Marcel DeVoe
> Hello Marcel DeVoe
>> Yes, it's IB2.2. I think it may be more probably YAM though. I'm still
>> using an earlier version, 1.3.x. It was GURU'ing in AOS3.1 fairly often,
>> but stopped in AOS3.5. Now it's happening again in 3.9 but without the
>> GURU, IB just comes to a dead stop. But it most often happens when I'm
>> running both YAM and IB concurrently. YAM closes down properly though.
>> Strange.
> YAM and IB both work perfectly, even together here under 3.9. What else
> are you running (MCP perhaps?) Of course I run YAM 2.2, haven't tried
> 1.3.5 in years, so you may be right about the version. Time for an
> upgrade, I suspect. 2.2 has its quirks, but you will get used to it.
Guess I should "about time" upgrade to it then.
> I never had any trouble with 1.3.5 under 3.1 though. It was rock solid.
Heh! Once some kind gentleman send me the correct .mcc MUI library,
so's Genesis under AOS 3.9. (dig, dig ;)
Niels Bache
[...]
> Heh! Once some kind gentleman send me the correct .mcc MUI library,
> so's Genesis under AOS 3.9. (dig, dig ;)
It's available in the Genesis package on Aminet:
gendemo104.lha comm/tcp 1.7M 101+Genesis demo. A new, powerful, TCP/IP stack
Hmm, OK, 1.7MB, I guess that's a bit much to download if all you want is
one .mcc file. OTOH, there's a lot of relevant documentation etc. in
there too.
Then again, you could also just go get the newly released maintenance
package containing the promised ReAction version of GenesisPrefs:
http://www.amiga.com/3.9/download/GenesisPrefs.lha
That way you don't need to run the MUI version at all.