#C-Ltd upgrade message
58 messages in this thread
How is RLL sm much more expensive? If I understand correctly, it allows more
storage and speed from a given drive by effectively increasing the storage
density. That should be more cost effective. Where have you seen rll to be
less reliable, except perhaps when it first came out? In regards to current
dma issues, has anyone ever tried out the 2620 and the 2090 with the specified
dpaint situation to see how they all behave together? No, it would not be
worth juryrigging the extra address lines as a kluge. Far too messy.
Now tell me something else. You talk about the increased part count on the
2090 as if it were and advantage. How so? I should think that being able to
do a given job with fewer parts should generally keep the cost down. It would
sound like the 2090 has not been well engineered in terms of part count and
complexity seeming to be higher then required to do the job – don't get upset,
this is just an impression that may be totally wrong.
Ron
Ron,
Cost effectiveness is one thing, and cost is another thing altogether. You
can buy a standard Seagate ST225 MFM drive for considerably less than any RLL
drive. Remember, many folks are looking for the lowest cost solution with the
best performance or capacity (or both) that they can find. The pieces bought
now can serve as a base for expansion as the money comes available. it is
interesting to note that quite a number of early Wedge purchasers are running
10 meg drives, and many of those have added a 20 or 40 to the initial setup.
For some, it meant the difference between running hard drives or staying with
floppies.
RLL was extremely unreliable when it was first introduced. It is better now,
but still not up to MFM in reliability. Part of this is due to the
manufacturer's attempts to provide low cost RLL drives, and part of it is due
to the more rigorous demands on the media itself.
No idea if anyone has tried DPaint with a 2620. DPaint itself is an extremely
ill behaved program, eating CPU cycles shamelessly while doing nothing, but if
I get my 2620 (probably March), I'll give it a try. Note that I have no
problems at all with DPaintt and the 2090. None.
Continued…
Ok, today, what would a reliable, say 30meg usable rll drive cost vs the same
in mfm? I note in talking to the Okidata people that they are very proud of
the drive I use. As for DPII, almost everyone here who's commented on it has
had a nasty thought or two on it, and its desparate need to be cleaned up and
improved. When you do get the 2620 I assume you'll try out the given problem
situation both with and without the 2620.
Ron
Ron,
Why do I get the feeling we are talking about two different things? I have
already tried DPaint and the 2090, loading a hi-res picture (640*400*4) while
displaying a 640*400*4 picture, which some have reported as a problem. Since
the 2620 autoconfigures its 32 bit ram within the first 16 megs, it will mean
that the 2090 can DMA directlyy into it. I'm just not sure which problem area
you are speaking of.
As for drives. What I was trying (apparantly unsuccessfully) to say, was
that the same drive mechanism often comes in two varieties, one MFM, and the
other, RLL. The price difference (on the cheaper drives), tends to be about
25-40% higher for the RLL version, which gives you 50% more storage. Cost
effective, lower cost per megabyte, but more money nonetheless. If all
consumers were interested mostly in cost per megabyte, we would all have
something like the CDC Wren IV, which is a 300 meg drive, and costs in the
neighbourhood of 2-3000 dollars, depending on where you get it.
-larry
What I would like to see is for someone who does have the problem with whatever
they do with dpaint to compare the disk speed plain and with a 2620.
As for cost effective, it still sounds like rll is more cost effective for a
'low cost' drive. For a much larger drive the wren is cost effective in
comparison, but we are talking about the drives that most people would drive.
RLL appears to give more megs to the buck in this range, at least in a reliable
drive.
Ron
Ron,
Yes, cost effective, but more cost. In general, the more expensive the drive,
the more cost effective it is in one form or another, often in capacity. Cost
thoughoes up as capacity goes up, and what you ll 'the same range' may not
be what many others call the same range. To many, a $100 difference may well
mean getting a drive or doing without.
And again, RLL is less reliable. I could probably get some sort of figures for
you on it, if I can get in touch with my friend at the distributor. He sees
drives coming back in warranty and out, and could probably give us an
indication of the relative numbers.
-larry
Larry, what sort of price difference would there be between a 30meg rll vs a 30
meg mfm? I should think the rll would be a bit cheaper, and if one is using a
drive designed, and certified for rll it should be reliable.
Ron
Ron,
I have no idea of the price difference between a 30 meg RLL and a 30 meg MFM.
I am not handy to my Computer Shopper mags right now, but it's a good place to
look for that info.
Reliability <sigh>. MFM is more reliable. I don't make this up, but get it
from sources who are in a position to know. You say that if a drive is designed
and certified RLL, it should be reliable. I agree, but you left out two things.
One is another 'if' _If_ the drive is of good quality, or better, _if_ the
drive is of better quality than the equivalent MFM drive (equivalent in
mechanism, not in capacity). For the same drive mechanism, RLL is less reliable
than MFM. Many manufacturers used to make a drive with a 'sputtered' media
coating on the platters for MFM, and a 'plated' media coating on the platters
for RLL. At that time, and drive that tested 'not quite good enough' for RLL,
was sold as an MFM drive, and the buyer had no way of knowing what type of
media the platters on any given drive were. It is most common now to have all
drives of any one type made with plated media, and tested to see if they are
good enough for RLL.
The bits are packed in closer together on an RLL drive, which means that the
media needs to be better. It also means that it will tolerate less of a
degradation in media than will MFM.
-larry
As I have agreed to end my part in the arguments in this thread, I still find
that I have not heard elsewhere that properly made and certified RLL drives
have reliability problems, will fully concede that others may have all sorts of
problems, and indeed I would expect them to.
Ron
Ron,
Remember the word "generally". It has a apecific meaning. Your RLL drive is
reliable. The RLL drives you know about are reliable (how many is that
anyway?). I am telling you that in the general case, RLL drives are _not as
reliable_ as MFM drives. This comes primarily from a person who sells drives,
whose company sells thousands of drives per year. The returned drives to that
company, both within the warranty period and out of warranty (for repair) show
him that RLL drives are significantly less reliable as a percentage of the
drives sold.
-larry
Larry,
Time the load of that 640x400x4 picture loading from a SCSI drive, a ST506
drive and then a floppy, all while displaying a 640x400x4 picture. I have done
just that and gotten the following results. (Oh, the HD's were formatted FFS)
SCSI 2:15-2:40 random, depends upon the phase of the moon.
ST506 0:13
Floppy 0:37
The picture I used was the Einstien pic, It's been around seemingly
forever. I'd like to hear any results you get, regardless of your setup. If you
get better performance than I using SCSI, I wanna know how!
-Dean
Dean,
I have timed it on a SCSI drive, and no longer have an ST506 drive hooked up
(though if I really wanted to, it could be done one evening). Yes, my
performance does seem to be better, though I only loaded a 640*400*4 pic with
some random lines drawn on it. It took approximately 4 seconds.
Hmm… let me try something and see if I can do it without crashing.
OK… I tried two pics from the flickeFixer disk. FF_Test (640*400*4, 38K) took
about 5 seconds, 'mandril' (512x420x4, 101K), took about 30 seconds. mandril
loaded with much ado and seeking. Loading mandril with 'UShow' puts the screen
into hi-res first, then loads the pic, and it takes less than 2 seconds.
Frankly, I suspect DPaint. I have thought of a test to try, but I will have to
reboot to do it. I will use TDebug to intercept the calls to the 2090, and
compare the loads of UShow and Dpaint. Perhaps the sectors accessed will prove
interesting.
Regards, Larry.
Larry,
Hmmmm, thats much better performance than I get! What version of
hddisk.device are you running, and where did you get it?
-Dean
Dean,
A 'strings' on my expansion/hddisk gives me a revision of:
bootrom 34.4 (5 May 1988)
and I got it here, in the hardware LIB I believe.
-larry
Larry,
Gee…I'm still using v33 since I don't have a SCSI drive hooked up and
v33 is faster than v34.4…or at least was when I tested v34.4 on my drive.
Never had any problems with either version, so stuck with v33 since it did have
the speed advantage.
Don
Don,
My rev 33 hddisk was fine for ST506 too, but I have since gone completely
SCSI, and so I needed the v34.5. Still not quite right though, as it doesn't
handle error returns properly when trying to use SCSI command passthrough, and
it doesn't support LUN's (multiple drives on one controller) yet. It is
currently in a state of being completely rewritten, according to CATS.
-larry
Larry,
Did you ever get back to Andy on LU's? I know he posted a message on
how to do it…and I know you tried it and had problems…but thought you were
going to call him and see if he had an update.
Don
Larry,
Interesting, that's the same version I have.
Another thing, I just retimed loading that pic (einstein) and it timed
out to 2:05 with my standard setup. I went back and changed the mountlist to
"MaxTransfer = 512" and tried again and it timed out to 0:06. This is going to
take some thought!
-Dean
Dean,
That _will_ require some thought! Changing MaxTransfer to 512 _should_ slow
things down.
I did take a look at the read requests with TDebug while loading Mandril from
DPaint and from UShow, and the requests are the same size, ie. there were a few
512 byte reads, but most were in the range of 5-17K per request. About the only
thing I can think of is that somehow only 512 bytes are being used or
transferred at a time, even though a larger number is requested, and that it
goes back for each 512 byte block, requiring a re-seek. I can't for the life of
me think of a way it could happen though, since it is not being done through a
separate read request (or TDebug would (should?) pick it up). It's a puzzler.
Played with a 2500 today. Ran Dpaint and Perfmon. Either they have fixed up
some of the hogging of DPaint (it is a later rev than the one I have_, or the
'020 is really humming. Perfmon would not 'max out' the idle graph when I
clicked in the DPaint window.
-larry
Larry,
I've seen the situation before that the 2090 driver can get lost,
especially on large reads. I believe this is why the MaxTransfer trick works.
When you're using TDebug, does it tell you where the data is being sent? I
think that DPaint goes right to CHIP mem, where UShow may buffer to FAST first.
From what I understand of the origional problem, the 2090 DMA overran the
64byte FIFO when talking to a SCSI device. That caused a R/W error that was
especially bad when loading very large files. The later drivers attempted to
fix this by internally trapping the error and reissuing the read command
(driver to SCSI device) until the data was recieved properly. DMA'ing to CHIP
memory when in 4 bitplane hires is the worst case.
I think I know what the problem actually is with the 2090, and I believe
it to be a hardware fault. One of these days I'll trace the circuit out and
find out if I'm right.
-Dean
Dean,
I just did some further testing, and am firmly convinced that DPaint itself
is the culprit in the 'slow loading' problem. Here are some tests you can try
yourself.
First, run DPaint and put it into 640*400*4 screen format, and then run PM
(performance monitor). Load up a hi-res pic, (don't know if this last step is
necessary, but it's what I did). Slide the Dpaint screen down so you can see PM
and place PM into .5 second sampling time. Observe the action of the CPU idle
indicator while positioning the mouse pointer over the canvas part of the
DPaint screen, over the menu bar, and over the WB screen. This thing is a cycle
hog, but only at certain times. Try clicking in the CLI and doing a command.
STATUS is quick and a good one to try. Note that it goes quickly. Now slide the
DPaint screen up to the top, and click it to the back. Click in the CLI and try
another STATUS. Note the slowness of it. DPaint cannot seem to get itself out
of hog mode whenever it is in the back.
Continued…
Continued…
These tests in themselves are not enough to condemn DPaint as the culprit in
the 'slow load' problem, but here's the kicker: Exit from Dpaint, and use UShow
to load up the same hi-res pic you were using to test DPaint. Click the left
button to 'set' the picture in place, and slide its screen down to expose the
CLI (use 2 if necessary) and PM. Now use UShow to load the same pic. (or
another one to clear the buffers, and back to the same one to retest). Observe
that the second pic loads just as quickly as the first one, even though it is a
similar condition to loading a pic into DPaint with the same screen
configuration.
My conclusion is that the 2090 has been given a bum rap for supposed DMA
interference with 640*400*4 screens, when in fact it is DPaint itself that is
somehow causing the poor performance. As soon as I can borrow ProPage, I will
perform similar tests on that, since that is the other one that people say they
notice the poor performance with.
Let me know how your tests go.
-larry
Larry,
I agree that Dpaint is a terrible CPU hog, and in trying your tests, I
find that if the mouse is positioned over the Dpaint screen, whether it is
active or not, Dpaint hogs cycles. With all that said, I have seen situations
where when using an effective 640x400x4 workbench screen plus severe overscan,
even loading a program from the CLI (such as Access! or MetaScope) will show a
marked loss of performance.
Using Dpaint and a ST506 drive, doesn't show near the degradation. Neither
does a floppy. In fact if I set MaxTransfer to 512 in my mountlist, performance
improves dramaticly with all other things being identical.
BTW, the 'problem' is worse if the file is stored contigusly. If it's
scattered on the disk, it loads much faster. (consistant with the MaxTransfer)
Also, with a OFS drive, loads are faster under the same circumstances.
Dpaint is a DOG, the 2090 does have problems as well, although in every
other respect I've been satisfied with it.
-Dean
Dean,
Do you have FastmemFirst early in your startup-sequence, before BindDrivers?
I do not have any performance degradation when showing any screen (except with
DPaint), and I am using 704*470 with the flickerFixer. Steve Ahlstrom tells me
he had problems like yours before putting FastMemFirst before BindDrivers. I
don't have any 'half-fast' ram on my German 2000, so the other problems you
refer to may be due to the $C00000 memory.
What you say about a file being 'scattered' on the disk is also supportive of
the thoery that when it does contiguous reads, it may be using only 512 bytes,
and having to re-seek to get the next block.
-larry
Larry,
When I had $C00000 memory on my 2000 I had the problem, and I still have
it now. (I no longer have $C00000 mem) I doubt that the problem I'm having is
my particular 2090 since I've also tried a 2090A with exactly the same results.
When running $C00000 mem, I was using FastMemFirst as the first thing in
the s-s, followed by SetPatch, and then BindDrivers. No matter what
configuration I use, I still have problems with 4 bitplane and/or max overscan.
-Dean
Hmmm….you conclusion is that the 2090 has been given a bum rap for supposed
DMA interference with 640x400x4 screens…..well ponder this Larry. Before I
had my 2090 controller I owned a C-LTD, and had no problems with it loading a
HiRes picture with Dpaint, but since I've moved to the 2090, a HiRes load is a
test of patience. Now one of the main differences between the 2 boards is that
one doesn't use DMA and the other does. So how do we explain that?
John
John,
I really don't know how to explain it, except to point out that there is no
problem loading a picture wih UShow, showing a picture in a screen 'slid down',
in the same position as that of the test done with DPaint. There could well be
a problem that has to do with DMA, and it could also be that DPaint does
something with the blitter that causes the problem. Any time there is
sufficient contention for the same resource, there will be problems, and if
Dpaint is hogging the bus via the blitter or copper, then that could explain
something. The borrom line, to me, is that there are other programs that show
no evidence of this problem under the same conditions.
-larry
oops… left out part of the test.
After fiddling with PM and observing the action of it when the mouse pointer
is in different places, try loading pics into Dpaint while watching PM. It does
not seem to matter to the performance whether the CPU is very busy or not, as
it takes a long time to load wven after you click on load, then click anywhere
in the WB screen. It's almost as if it isn't the CPU, but it could be a
function of PM that causes it to not be able to detect actual usage in whatever
DPaint is using.
-larry
Larry: I certainly have problems loading a Hi-Res picture in Dpaint II in that
it takes a painfully long time to load. I'm using the May 5th 88 (I think)
version of hddisk.device downloaded from one of the libraries here, so you may
have a newer version. If so, how about uploading it for us! Also, I'm using a
SCSI drive, and I've heard that the problem is more prevelant on a SCSI drive
than a MFM drive, but haven't been able to verify that yet.
John
John,
That is the same driver I have. In doing some more tests, I have discovered
that I do have low performance loading in certain pictures (I had been using
very simple pics). However, other programs I have tried do not show poor
performance, and I suspect DPaint is the culprit.
Continued..
Now, about parts count and the 2090. No, I don't consider a higher parts
count an advantage. It is definitely true that doing a given job with a lower
parts count is a goal to be desired. What you are doing, though, is mistaking
what 'the job' is. The 2090 and the C Ltd host adapter, to name only two, do
not perform the same job. True, they both help move data from a hard drive into
memory, and vice versa, but that's where the comparison ends. You can
communicate with someone across the country by walking there, by telephone, or
by radio, though you wouldn't say you were really 'doing the same job', even
though the communication is still acheived.
Remember, the 2090 handles DMA, a direct (native) ST506 interface, and
because of that, does considerable more than the C Ltd controller does. The C
Ltd, and others like it, depend heavily on a single, specialized chip, and the
software to handle it. If you doubt the amount of logic required to perform DMA
or to implement a native ST506 interface, I'm sure you canfind other opinions
than mine.
-larry
A question about the 2090a. Would it have been that hard for cbm to replace
the existing adaptec chip with something faster, or would st506 make that
worthless? Granted that adding dma and st506 does increase the part count,
though I've heard some thoughts about the quality of cbm's engineering of the
design in terms of part count being higher then that added functionality
requires. I'm not an engineer, so I can't judge.
Ron
Ron,
I don't know. There are a rather large number of factors involved in making
decisions during the design of a product, and I can't be aware of all of them.
Maybe they had a few hundred barrels of Adaptec chips laying around gathering
dust.
I don't know who your source was for the design comments, but I did notice a
name that cropped up a number of times in your messages as having told you
various things, and would just like to mention that a salesman is the last
person you want to believe on a technical matter.
-larry
The person wasn't a salesman. And maybe they did have a pile of the Adaptec
chips, which would seem to be a bit dated at this point.
Ron
Ron,
Adaptec _does_ make more than one set of controller chips.
-larry
I wonder if they have a pin compatible much faster version of what CBM is
using, that would have allowed a performance upgrade by them just going with
the newer chipset.
Ron
Ron,
I have no way of knowing. ST506 is, bu its very nature, fixed to a maximum
speed of 5 MBits per second, and the 2090 comes close to half the maximum
throughput rate. How much is it worth spending in the factory (remmbering that
the retail price is normally about 4-5 times the parts cost), to get a little
more throughput?
-larry
Ron,
One comment about parts count. As you are probably aware, CBM has it's
own chip manufacturer..MOS to be exact. I would suspect that before CBM
decided to integrate many chips into one thou….they'd like to make sure that
there would be a payoff (profit) in doing that. That means working out design
bugs fully, having experience in real-world usage (vs lab testing) and total
sales of the product.
I'm sure that at some time, the parts count will come down. I'd
suspect that for now…CBM used off the shelf chips for the most part in an
effort to lower startup costs. If the economies of volumn warrant it…I think
you'll see custom chips future versions of the board.
All that aside, having high parts count doesn't necessairly effect
performance. Moving lots of separate parts into one chip may not speed things
up at all…it'll only improve hardware reliability (less parts to break) and
lower production costs.
Yes, sometimes during the move from multiple parts to a single chip can
speed things up due to design changes or improvements made during the move.
Don
Ron,
As far as part counts are concerned. For a given job, there are many
different ways the job can be performed. There are also many factors to be
considered when calculating costs. In many of my designs, one high density chip
can cost many times more than the discrete logic needed to perform the same
function. If there is board space to spare, it is then "cheaper" to use more
components. If, on the other hand, board space is at a premium, the high
density chip becomes "cheaper". Board size, component costs, manufacturability,
component availability, and many other things all contribute to the cost
equasion. Trying to equate part counts to product costs seldom works well.
Given all the above, even trying to compare the 2090 and the Cltd boards
is wasted effort. They were each designed to do different jobs, the Cltd to
provide a low cost HD interface, and the 2090 to provide a flexible, highly
optioned HD interface providing a DMA interface. I find it interesting to note
that from the messages I've read here, both solutions come very close to each
other in final system cost, depending of course on what the exact setup is.
-Dean
That exact setup has a great deal of influence on the final cost. As to part
count, I note that it was suggested that the higher part count made the board
worth more. Higher functionality would of course cost more, but night higher
part count, which as you say, may cost less.
Ron
Ron,
No. Nobody said higher parts count made the board worth more. What was said
was thet higher parts _cost_ made the board _cost_ more. Simple economics. Note
also that, in general, more functionality means higher parts count, _unless_ it
is able to be incorporated in parts of higher integration, and provided
thatthose parts cost less than the more discrete parts.
In particular, note the difference between 'worth' and 'cost', and try to
compare similar functionalities.
-larry
"For a given job, there are many different ways the job can be performed."
I always chuckle about the old saw "There are as many ways to write a program
as there are programmers". Hardware hackers know that the same thing applies
to any non-trivial circuitry. You wanna talk tradeoffs, there are more of them
in hardware than there can ever be in software. You of course know that, Dean;
I'm just rambling.
Rick
Rick,
Amen to that. I actually run through at least 20 different design
possibilities before I even start to put it on paper. And then comes the
problem of making the whole thing work, which adds a few dozen more
possibilities. Next comes cost tradeoff's, and then …… 8)
-Dean
.. and then comes SEA and FMEA and Tolerance Analysis, each one of which shows
a fatal flaw in your design at the limit conditions, which means a whole
'nother iteration. I do both, but if I had to chose which to do for the rest
of my life, I think software would win out over hardware. (However, in defense
of hardware, it's a ball and a great learning experience on a hacking level.
I'm talking about production devices here, which are much more rigorous.)
Rick
Rick,
Right! <shaking head, and wondering why people think a complex HW or SW
project can be developed overnight)
-Dean
I think most of the problems reported with RLL were from people using
MFM-rated drives with RLL controllers. With RLL-rated media I believe there is
little or no difference in reliability. Remember, an RLL controller stores 50%
more information in the same space. If the oxide particles in the media are
too large then it will effectively "filter out" the higher frequency data. I
believe RLL-rated drives use plated media. The oxide is evaporated onto the
platter in a vacuum chamber, which gives a finer "grain" to the coating. The
old technology used an oxide slurry which was "painted" on. Of course, not all
plated media gets an RLL rating.
Jon
I wonder what percentage failure rate there has been with drives made and
certified for rll, vs the same for mfm. I suspect not much of a difference,
that from what I'm hearing many of the rll failures were with actual mfm drives
being misused.
Ron
Ron,
That does it. I will get figures for you. Would you like them certified by a
Notary Public?
-larry
Would a notary prove anything?
Ron
I don't know Ron. I am wondering what it takes for you to even consider the
opinion of anyone.
Jon,
I thought RLL got more information because of a different encoding method,
rather than because of higher density. Your message seems to indicate that it
is the media and the density. How IS this encoded? I understand GCR and MFM,
but have never seen RLL explained anywhere.
Betty
Where _did_ I read that description of RLL, anyway? I think it was in Byte
many moons ago. The encoding method is more efficient, but it still requires
better media as well.
Jon
Jon, I know that MFM puts down two bits for every bit of data – a data bit and
a clock bit. GCR puts 5 bits for 4 data bits. I really keep wondering about
RLL, but have not been able to find a source.
Betty
RLL gets higher DATA density with the same number of flux changes. It does
this by eliminating the need for a continuous clock signal. Since you need to
sync off of SOMETHING, the data is restructured such that there are always
enough flux reversals to substitute for the missing clock signal. This is done
by substituting specific flux reversal patterns for the bit patterns such that
there is a minimum and maximum number of successive zeros and ones; thus the
name RLL: the full name of the standard scheme is Run Length Limited 2,7 (the 2
and 7 referring to limits on successive flux reversals).
Since this is more demanding of the media, MFM drives will generally not be
reliable storing RLL data. Media type is therefore _indirectly_ connected with
RLL, but it's not primary to the issue of how the data density is increased.
The key point to remember: the DATA density is increased; the FLUX density
doesn't change.
We discussed this a few months ago here. I can dig up my references and type
in the specifics again if you need the information?
Rick
Rick, if you can just point me to a reference that the University might have –
most likely place to find such, I'd think – I'll go look it up. We live only 3
blocks from their library. I'm really curious about it. Disks are of
particular interest to me.
Betty
Mmm, don't know one offhand. You might go to stacks of technical magazines
like EDN or Electronic Design. EDN does a yearly index of articles each, um,
January I believe. Shouldn't take two or three peeks before… oh heck, I'm
being silly, hold on… <flip flip scrabble flip>… aha, okay, here.
Grab a copy of Electronic Design, January 24, 1985. Page 186 is a nice
single-sheet summary of the three methods of storage (FM, MFM, and RLL). It
exists within a larger article on disk drives.
Since you're into disks, you might also take a look at IEEE Spectrum, June
1986, page 32 on, if they have it. An interesting article on copy protection
as applied to disks… basically a catalog of available techniques.
Yell if I can be of further assistance.
Rick
Thanks, Rick!! My husband belonged to IEEE for many years. We probably have
that Spectrum in his files. And if not, those were kept at the University
library, too. This school specializes in engineering. (He taught there for 18
years.)
I'll get down there and look those up. Gee, I've wondered about RLL for quite
a long time, but just kept putting off doing the research.
Betty