sdl@linus.UUCP (Steven D. Litvintchouk) (10/30/88)
I have been unable to get the Workbench 1.3 Fast File System (FFS) to
work with my Pacific Peripherals Overdrive hardcard on my Amiga 2000.
I have a Seagate ST157N hard disk attached to the hard card. I
formatted the drive with two partitions: one with the standard file
system, and one with the Fast File System (FFS). The partition with
the standard file system works fine. But every time I try to copy
files from a floppy disk drive to the FFS partition, the Amiga
crashes; sometimes it freezes up, other times it gurus. (If I try to
copy files from the standard hard disk partition to the FFS partition,
that also causes gurus, but only intermittently.)
I called Pacific Peripherals about this. They suggested that
FastMemFirst should not be used (the Workbench 1.3 version is
apparently buggy), and also suggested the following Mountlist entry
for the FFS partition:
DH1: Device = overdrive.device
Unit = 1
Flags = 0
Surfaces = 6
BlocksPerTrack = 26
Reserved = 2
Interleave = 0
LowCyl = 57 ; HighCyl = 607
Buffers = 5
BufMemType = 3
GlobVec = -1
FileSystem = L:FastFileSystem
Mount = 0
StackSize = 0x800
MaxTransfer = 127000
#
However, neither of these suggestions has fixed the problem.
Has anyone had better luck with FFS on a Pacific Peripherals
Overdrive? Does anyone know what might be causing these gurus on my
Amiga? Any help would be most appreciated!!!
Steven Litvintchouk
MITRE Corporation
Burlington Road
Bedford, MA 01730
Fone: (617)271-7753
ARPA: sdl@mitre-bedford.arpa
UUCP: ...{cbosgd,decvax,genrad,ll-xn,mit-eddie,philabs,utzoo}!linus!sdl
"Those who will be able to conquer software will be able to
conquer the world." -- Tadahiro Sekimoto, president, NEC Corp.rss@ece-csc.UUCP (ML) (10/31/88)
In a previous article sdl@linus.UUCP (Steven D. Litvintchouk) wrote: > >I have been unable to get the Workbench 1.3 Fast File System (FFS) to >work with my Pacific Peripherals Overdrive hardcard on my Amiga 2000. > >I have a Seagate ST157N hard disk attached to the hard card. I >formatted the drive with two partitions: one with the standard file >system, and one with the Fast File System (FFS). The partition with >the standard file system works fine. But every time I try to copy >files from a floppy disk drive to the FFS partition, the Amiga >crashes; sometimes it freezes up, other times it gurus. (If I try to >copy files from the standard hard disk partition to the FFS partition, >that also causes gurus, but only intermittently.) > >I called Pacific Peripherals about this. They suggested that >FastMemFirst should not be used (the Workbench 1.3 version is >apparently buggy) ... I have the same configuration and ran into the same problems. After some experimenting and some calls to a local guru I finally came up with this mountlist entry which seems to do the trick: /* Pacific Peripherals OverDrive Drive definition for ST157N drive */ DH0: Device = overdrive.device FileSystem = L:FastFileSystem Unit = 1 Flags = 0 Surfaces = 6 BlocksPerTrack = 26 Reserved = 2 Interleave = 0 LowCyl = 1 ; HighCyl = 608 Buffers = 5 BufMemType = 2 MaxTransfer = 1 Mount = 1 GlobVec = -1 DosType = 0x444F5301 Mask = 0x7FFFF # The "Mask" and "MaxTransfer" fields seem to be the important thing (I'm not sure about BufMemTypye either). Obviously, I haven't put any SFS partition on my drive; I have no need to since I don't have the 1.3 ROMS so I can autoboot (do I all need new roms on the Paciphic Periph. Overdrive controller to autoboot?) BTW -- I *DO* have FastMemFirst in my startup sequence. Hope this works for you. Mark Lanzo borrowing ...mcnc!ece-csc!rss
vkr@osupyr.mast.ohio-state.edu (Vidhyanath K. Rao) (10/31/88)
In article <41342@linus.UUCP> sdl@linus.UUCP (Steven D. Litvintchouk) writes: >[...]I called Pacific Peripherals about this. They suggested that >FastMemFirst should not be used (the Workbench 1.3 version is >apparently buggy), [...] Is this true? I got my hard disk and the dealer had put 1.3 on it. [But he didn't have the enhancer kit. So no manual. sigh] FastMemFirst was in the startup-sequence but after mount. So I put FastMemFirst up on top. I did a one problem rebooting while fine-tuning the startup. But with only 10 hours experience... I would appreciate a definitive answer. BTW, I have a C.Ltd controller. and a 500
dsking@pyr.gatech.EDU ( David King) (10/31/88)
In article <3823@ece-csc.UUCP> rss@ece-csc.UUCP (ML) writes: ... >/* Pacific Peripherals OverDrive Drive definition for ST157N drive */ ... > MaxTransfer = 1 ... > Mask = 0x7FFFF ># >The "Mask" and "MaxTransfer" fields seem to be the important thing (I'm not >sure about BufMemTypye either). > >Obviously, I haven't put any SFS partition on my drive; I have no need to since >I don't have the 1.3 ROMS so I can autoboot (do I all need new roms on the >Paciphic Periph. Overdrive controller to autoboot?) Ok, I had this problem a week ago before Pacific Peripherials had their 1.3 Enhancer release so I came up with my own solution. Jdow (thanks) suggested a solution which worked. I added a line MaxTransfer=512 to my mountlist. By specifying MaxTransfer=1 you are transfering a maximum of 1 byte per transfer. I tried using a slightly higher vue but it didn't work. Apparently the overdrive.device has problems with grabbing more than a block at a time for FFS. The problem with this is that the only speed advantage that I get from FFS is in the directory structure (in fact, raw transfer rate is slower). I have not played with the Mask value. Where did you get that Mask value? The present Overdrive can not autoboot presently. A daughterboard is needed to autoboot (atleast for mine - purchased in March '88). Good luck, - David --- - David King dsking@pyr.gatech.edu
andy@cbmvax.UUCP (Andy Finkel) (11/01/88)
In article <41342@linus.UUCP> sdl@linus.UUCP (Steven D. Litvintchouk) writes: > >I have been unable to get the Workbench 1.3 Fast File System (FFS) to >work with my Pacific Peripherals Overdrive hardcard on my Amiga 2000. > >I called Pacific Peripherals about this. They suggested that >FastMemFirst should not be used (the Workbench 1.3 version is >apparently buggy), and also suggested the following Mountlist entry >for the FFS partition: Pacific Peripherals is incorrect. FastMemFirst is fine, the problem is that their driver can only handle a limited number of blocks at a time (127000 bytes at a time). It also needs a bit more than the default stack to operate. That's what the changes in the mountlist entry they told you to make do. They seem to understand the problem; I've no idea why they are claiming that FastMemFirst is involved. If the problem is that their driver can't take block requests in treal fast memory (as opposed to C00000 memory) then the MASK parameter in the mountlist can be used instead. -- andy finkel {uunet|rutgers|amiga}!cbmvax!andy Commodore-Amiga, Inc. "I first began to lose faith in software engineering when I found out that no two printers were compatible." Any expressed opinions are mine; but feel free to share. I disclaim all responsibilities, all shapes, all sizes, all colors.
space@sns.UUCP (Lars Soltau) (11/02/88)
In article <5145@cbmvax.UUCP> andy@cbmvax.UUCP (Andy Finkel) writes: >FastMemFirst is fine. I never use FastMemFirst, for one good reason: I have 512K (how do you call it) "special" memory at $C00000 and 2M fast memory at $200000. I use 512 buffers for the HD and start quite a lot of programs at boot-up, like AmyCron etc. So after boot-up the $C00000 RAM is completely occupied but I still have nearly 2M of *CONTIGUOUS* RAM. If I did call FastMemFirst, all those boot-up processes would eat up my $200000 memory and while I still had about 2M fast mem, it would be in one 512K and one 1.5M block -- Lars Soltau UUCP: ...uunet!unido!sns!space BIX: -- no bucks -- Here's looking at you, kid! -- the Medusa
andy@cbmvax.UUCP (Andy Finkel) (11/03/88)
In article <6679@pyr.gatech.EDU> dsking@pyr.UUCP ( David King) writes: >a solution which worked. I added a line MaxTransfer=512 to my mountlist. By >specifying MaxTransfer=1 you are transfering a maximum of 1 byte >per transfer. I tried using a slightly higher vue but it didn't work. Actually, the minimum amount transfered is 1 block, or 512 bytes. -- andy finkel {uunet|rutgers|amiga}!cbmvax!andy Commodore-Amiga, Inc. "Possibly this is a new usage of the word 'compatible' with which I was previously unfamiliar" Any expressed opinions are mine; but feel free to share. I disclaim all responsibilities, all shapes, all sizes, all colors.
mp1u+@andrew.cmu.edu (Michael Portuesi) (11/05/88)
> *Excerpts from ext.nn.comp.sys.amiga: 2-Nov-88 Re: problems with using 1.3..* > *Lars Soltau@sns.UUCP (714)* > I never use FastMemFirst, for one good reason: > I have 512K (how do you call it) "special" memory at $C00000 and 2M fast memory > at $200000. I use 512 buffers for the HD and start quite a lot of programs at > boot-up, like AmyCron etc. > So after boot-up the $C00000 RAM is completely occupied but I still have nearly > 2M of *CONTIGUOUS* RAM. If I did call FastMemFirst, all those boot-up > processes would eat up my $200000 memory and while I still had about 2M fast > mem, it would be in one 512K and one 1.5M block My situation is the other way around. I have 1 MB of $C00000 RAM (which is non-CHIP non-FAST ram) and 512K of genuine FAST RAM. If I don't use FastMemFirst in my Startup-Sequence, RAD: my FaccII buffers, DMouse, et al. will wind up in the 1 MB of slow/fast mem, reducing the largest available free memory block. If I do use FastMemFirst, they will wind up in the genuine FAST memory, and my application programs will not get use of the FAST memory. DPaint running at high-res four bitplanes slows down quite considerably if it is not running from genuine FAST memory. Is it better to put up with the memory fragmentation so that the FAST memory can be put to better use? --M Michael Portuesi / Information Technology Center / Carnegie Mellon University ARPA: mp1u+@andrew.cmu.edu BITNET: mp1u+%andrew.cmu.edu@cmccvb UUCP: ...harvard!andrew.cmu.edu!mp1u+ "my friends say she's a dumb blonde, but they don't know she dyes her hair"