Forum unknown
· Hardware
C Ltd
21 messages in this thread
Those are probably in line, Steve; We have a driver that will be released
when 1.3 is; until then, it's not compatible with the 1.2 stuff, so it's
rather foolish to release it…. especially since there is no assurance
that they will release 1.3; After the 68020/mmu board fiasco, I'm back to
"Ye of little faith" mode. If they DO release the ffs, then we'll have a
driver that can handle it in an optimum manner, considering we're currently
limited to a programmed I/o interface. –Ben–
Hi Ben! I just purchased a C-Ltd SCSI controller for my 500 along with a
Everex 20D hard disk today. After putting my poor printer through the torture
of printing out the Technical reference manual, I find that it is going to be
a real chore in setting up my new hard disk. The manual that came with the
Everex is the absolute pits, with no tech information at all. Its pretty much
all set up for those MacWac's so they figured that was all the information
they would need. I will eventually get the information I need to set it up,
by calling Everex, and bugging my dealer, but would you happen to have the
configuration settings that I would need to format and/or mount the drive? I
thought maybe someone else has bugged you about a Everex HD and have the info
at hand. If not, well I guess I will do it the hard way. Any info would be
appreciated.
John Gager K7KB
(And patiently waiting for your PD SSTV goodies for the Amiga 🙂
No one has… You need to know the following about your drive;
1- how many cylenders, total;
2- how many (data) platters, total
3- how fast can it step?
4- is it SCSI or ST-506?
5- are there bad sectors?
6- if there are, you have 1 less cylinder than you think;
Get that info together, and I'll try and help you thru it, if you still need
help. –Ben– (PCBS are being made now for the sstv stuff – also fax demods)
Ben, I was able to set up my Everex 20D without too much problem after I
talked to the dealer. He has a 20D hooked up to his 1000, so was familiar
with it. Just for your own information in case someone else needs some help,
for low level formatting I used Romat and clicked the 20 gadget. The only
default I changed was the interleave which I changed to 3. This was
determined by experimentation. Then after using Romat, all you need to do is
use Quickformat or the AmigaDos format and you are all set to go! I'm not
sure what the step rate is for the Everex, because like I said, there was
absolutely no technical specifications in the manual at all. But I will call
Everex tomorrow and get the specs so I can possibly fine tune the format
some. As it stands right now, the read transfer rate is about 25300 KB/sec.
Even though I'm thrilled with the faster HD, I just can't wait until CBM
releases 1.3 with the FFS–BIG GRIN 🙂 I could easily live with a transfer
rate of over 100KB/sec. I'm looking foward to seeing what you come up with on
your SSTV converter. I was reading in the latest issue of CQ magazine where
someone has come up with a extension to the packet protocol that allows
picture transmission. I need to sit down and really read the ariticle to see
what it is all about. Thanks again Ben for your help, and when I get the
specs on the Everex, I will try some other fine tuning and see what is best
for that HD and post the results for you.
John Gager K7KB
Actually, John, it's not a transfer rate of 100k/sec – it's more like 220
k/sec. The _diskperf_ program comes up with a number that indicates up to
100k/sec for it's operations. Many operations will show very nearly the
same performance as if you had a DMA controller. One thing to consider is
that since this interface is a programmed I/o interface, when the disk
transfers are occuring, the CPU is _very_ busy, and other tasks suffer for
it.
An instance where this matters is when you have more than one task doing
disk i/o. An instance where it does NOT matter is when you are running a
program, or copying one. For instance, a couple of days ago, I was on the
phone with someone who has a 2090 system; she has just installed 1.3 and
the FFS on it. We both have, and use DirUtil III. Both of us experienced
virtually the same time when dragging the icon from the HD window into the
ram disk window – about 1.5 seconds.
Dirutil is 23k; it's not really a function of the HD interface at that
point, it's more the DOS. Both system, which were running 1.3 and FFS at
the time, use 68000's and are similar in many other ways, the only notable
exception being the 2090 itself. Figuring a 23k read and a 23k write (into
ram, no less) that's only a 40k transfer.
Even using the diskperf figures for my system (97k/sec for the slowest
number read spec), a good amount of time is unaccounted for. Enter
AmigaDOS, the worlds slowest data-handler. <grin> Catch you later, and I'm
glad you got your system up and going – btw, couldn't have helped you in
any case – ROMAT is not our product, and I know ZIP about it — we did the
ST-506/Adaptec stuff, and associated formaters and so on; the SCSI stuff
was done at C LTD. Remember that if it breaks! heheheh –Ben–
Ben, I've read (and I don't know what to believe at this point) that dma
controllers have a major advantage under FFS over non-dma, like one you know
I use. Any comment?
IT is true, in principal, and in theory. However, the Amiga's DOS throws in
a wrinkle that skews the numbers – the dos is so slow, for instance in
icon handling and so on, that although the interface itself runs quicker,
both are fast enough so that the major amount of time is spent in the DOS
routines. FFS corrects one of the bad bottlenecks in the system; programs
that utilize the disk for data transfer directly will realize a much larger
improvement from a DMA controller. Program loading, file copies, and so
forth, are still choked up by various DOS areas; for instance, the
requirement that a program be linked at load time causes the FFS program
loads to be only slightly faster, even though the disk activity, per se, is
greatly reduced.
To sum it up, yes, the DMA controllers have an advantadge. In normal Amiga
system use, I don't think you'll see it very much. DMA controllers will
shine when multitaking is involved WITH the file system – DMA transfers
will not, in and of themselves, slow down other tasks, while a programmed
I/o controller most certainly will. I think that's the most important
factor; You have to consider that we do not generally use the multitasking
as it was anticipated that we would; we generally run only one or two main
programs, and some backround ones that mostly sleep, like clocks,
screenblankers, dirutils, music programs (Excluding DMCS – a cpu hogger)
and so on; the reality in these types of situations is that the CPU is
really running one task, mostly – the one you're using to access the disk;
because of that, again, you won't see a lot of difference. Generally.
Now, bear in mind, this is an opinion only, and based on feel more than
benchies. Since this is so prone to how YOU use your system, it's almost
impossible to be concrete about it. It *is* my opinion, though. –Ben–
Most times I use my system with heavy IO, it's only one program that's
doing it – I've always been afraid to do 2 or more heavy io progs at a
time. This will be interesting!
IT is true, in principal, and in theory. However, the Amiga's DOS throws in
a wrinkle that skews the numbers – the dos is so slow, for instance in
icon handling and so on, that although the interface itself runs quicker,
both are fast enough so that the major amount of time is spent in the DOS
routines. FFS corrects one of the bad bottlenecks in the system; programs
that utilize the disk for data transfer directly will realize a much larger
improvement from a DMA controller. Program loading, file copies, and so
forth, are still choked up by various DOS areas; for instance, the
requirement that a program be linked at load time causes the FFS program
loads to be only slightly faster, even though the disk activity, per se, is
greatly reduced.
To sum it up, yes, the DMA controllers have an advantadge. In normal Amiga
system use, I don't think you'll see it very much. DMA controllers will
shine when multitaking is involved WITH the file system – DMA transfers
will not, in and of themselves, slow down other tasks, while a programmed
I/o controller most certainly will. I think that's the most important
factor; You have to consider that we do not generally use the multitasking
as it was anticipated that we would; we generally run only one or two main
programs, and some backround ones that mostly sleep, like clocks,
screenblankers, dirutils, music programs (Excluding DMCS – a cpu hogger)
and so on; the reality in these types of situations is that the CPU is
really running one task, mostly – the one you're using to access the disk;
because of that, again, you won't see a lot of difference. Generally.
Now, bear in mind, this is an opinion only, and based on feel more than
benchies. Since this is so prone to how YOU use your system, it's almost
impossible to be concrete about it. It *is* my opinion, though. –Ben–
Ben, I've read (and I don't know what to believe at this point) that dma
controllers have a major advantage under FFS over non-dma, like one you know
I use. Any comment?
Ben, almost all of the messages that I have read about the FFS is that it
is being used with a 2090 controller. Will it be compatible and speed up
my C-LTD/Everex combination? I sure hope so! It would be a real drag 🙁 if
I can't make use of the FFS when it comes out. Oh, I did get ahold of
Everex today and these are the specs of the drive:
615 max cylinders
15ms Track-Track access time
17 tracks/cylinder
As far as getting a defect list, well I was darn lucky to get the above
information. Defect list, what defect list. Our drives are not defective!
So I guess I will just experiment with the HighCyl number. The drive is
working great as is, so maybe I should stick to my philosophy: If its not
broke, don't fix it.
The FFS will be compatible with any driver that allows multiple block
reads and writes.
The FFS will be compatible with any driver that allows multiple block
reads and writes.
FFS will work with your setup; It will offer a considerable speedup in
areas where the 2090 offers considerable speedup. In areas like program
loading, neither controller can do much better, as the DOS is the problem,
not the file system. No defect list, eh? Did you look ON the drive, perhaps
a little sticker? –Ben–
FFS will work with your setup; It will offer a considerable speedup in
areas where the 2090 offers considerable speedup. In areas like program
loading, neither controller can do much better, as the DOS is the problem,
not the file system. No defect list, eh? Did you look ON the drive, perhaps
a little sticker? –Ben–
Ben, almost all of the messages that I have read about the FFS is that it
is being used with a 2090 controller. Will it be compatible and speed up
my C-LTD/Everex combination? I sure hope so! It would be a real drag 🙁 if
I can't make use of the FFS when it comes out. Oh, I did get ahold of
Everex today and these are the specs of the drive:
615 max cylinders
15ms Track-Track access time
17 tracks/cylinder
As far as getting a defect list, well I was darn lucky to get the above
information. Defect list, what defect list. Our drives are not defective!
So I guess I will just experiment with the HighCyl number. The drive is
working great as is, so maybe I should stick to my philosophy: If its not
broke, don't fix it.
Actually, John, it's not a transfer rate of 100k/sec – it's more like 220
k/sec. The _diskperf_ program comes up with a number that indicates up to
100k/sec for it's operations. Many operations will show very nearly the
same performance as if you had a DMA controller. One thing to consider is
that since this interface is a programmed I/o interface, when the disk
transfers are occuring, the CPU is _very_ busy, and other tasks suffer for
it.
An instance where this matters is when you have more than one task doing
disk i/o. An instance where it does NOT matter is when you are running a
program, or copying one. For instance, a couple of days ago, I was on the
phone with someone who has a 2090 system; she has just installed 1.3 and
the FFS on it. We both have, and use DirUtil III. Both of us experienced
virtually the same time when dragging the icon from the HD window into the
ram disk window – about 1.5 seconds.
Dirutil is 23k; it's not really a function of the HD interface at that
point, it's more the DOS. Both system, which were running 1.3 and FFS at
the time, use 68000's and are similar in many other ways, the only notable
exception being the 2090 itself. Figuring a 23k read and a 23k write (into
ram, no less) that's only a 40k transfer.
Even using the diskperf figures for my system (97k/sec for the slowest
number read spec), a good amount of time is unaccounted for. Enter
AmigaDOS, the worlds slowest data-handler. <grin> Catch you later, and I'm
glad you got your system up and going – btw, couldn't have helped you in
any case – ROMAT is not our product, and I know ZIP about it — we did the
ST-506/Adaptec stuff, and associated formaters and so on; the SCSI stuff
was done at C LTD. Remember that if it breaks! heheheh –Ben–
Ben, I was able to set up my Everex 20D without too much problem after I
talked to the dealer. He has a 20D hooked up to his 1000, so was familiar
with it. Just for your own information in case someone else needs some help,
for low level formatting I used Romat and clicked the 20 gadget. The only
default I changed was the interleave which I changed to 3. This was
determined by experimentation. Then after using Romat, all you need to do is
use Quickformat or the AmigaDos format and you are all set to go! I'm not
sure what the step rate is for the Everex, because like I said, there was
absolutely no technical specifications in the manual at all. But I will call
Everex tomorrow and get the specs so I can possibly fine tune the format
some. As it stands right now, the read transfer rate is about 25300 KB/sec.
Even though I'm thrilled with the faster HD, I just can't wait until CBM
releases 1.3 with the FFS–BIG GRIN 🙂 I could easily live with a transfer
rate of over 100KB/sec. I'm looking foward to seeing what you come up with on
your SSTV converter. I was reading in the latest issue of CQ magazine where
someone has come up with a extension to the packet protocol that allows
picture transmission. I need to sit down and really read the ariticle to see
what it is all about. Thanks again Ben for your help, and when I get the
specs on the Everex, I will try some other fine tuning and see what is best
for that HD and post the results for you.
John Gager K7KB
No one has… You need to know the following about your drive;
1- how many cylenders, total;
2- how many (data) platters, total
3- how fast can it step?
4- is it SCSI or ST-506?
5- are there bad sectors?
6- if there are, you have 1 less cylinder than you think;
Get that info together, and I'll try and help you thru it, if you still need
help. –Ben– (PCBS are being made now for the sstv stuff – also fax demods)
Hi Ben! I just purchased a C-Ltd SCSI controller for my 500 along with a
Everex 20D hard disk today. After putting my poor printer through the torture
of printing out the Technical reference manual, I find that it is going to be
a real chore in setting up my new hard disk. The manual that came with the
Everex is the absolute pits, with no tech information at all. Its pretty much
all set up for those MacWac's so they figured that was all the information
they would need. I will eventually get the information I need to set it up,
by calling Everex, and bugging my dealer, but would you happen to have the
configuration settings that I would need to format and/or mount the drive? I
thought maybe someone else has bugged you about a Everex HD and have the info
at hand. If not, well I guess I will do it the hard way. Any info would be
appreciated.
John Gager K7KB
(And patiently waiting for your PD SSTV goodies for the Amiga 🙂