Nexus HD Controller ??
32 messages in this thread
A guy I work with is purchasing a Progressive Peripherials 'NEXUS' HD
controller. Will run a Quantum 105 meg off of it. I havent' seen any
reviews or news on this controller. Anyone know anything about it? (ie.
strait SCSI, speed, support, etc?)
Aside comment: The dealer sold him by telling him he would be able to run
disk-based animations at 60fps with this setup (!). Now, I've seen a lot
of controller demos that show HD based anims, but always with lo-res,
non-interlace, lo-color, etc, and NOwhere near 60fps. I realize that
'fastest' carries a load of variables, but what would generally be
considered the best (ie. disk-based anim 'fastest') controller/HD combo out
now? Thanks –jp–seattle–
John,
Well…let's do a little math:
low-res screen is 320×200 pixels. That'd be 64000 bits or dividing
by 8 for bytes…that gets us 8000 bytes per frame. Presuming full frame
animation, at 60 frames per second…that be 60×8000 for a low-res, 2
color, full frame animation needed or 480,000 bytes per second off the
drive.
Of course, that's sustained bytes per second, not burst rates.
That also presumes that the full frame needs to be loaded everytime…not
just the changed pieces.
4 colors would take 2 bit planes, or twice as much data, 8 colors
would take 3 bit planes or 3 times the data (1,440,000 bytes per sec).
But let's stick with the data needed per frame. 8000 bytes every
60th of a frame for 1 bit plane, 16,000 per second for 2 bit planes (4
color) and 24,000 bytes per frame for 3 bit planes (8 color).
Now, a hard drive spins at 3600 revs per minute, or 60 revs per
second. That works out well for us, because we have 60 frames per second,
and a drive that spins 60 times a second. Thus…the amount of data we can
get off the drive in one revolution would be the absolute maximum we can
display in one frame.
Since almost all Hard drives can only read one head at a time, then
it makes no difference how many heads it has…it can only read one at a
time. Thus it comes down to how many sectors per track are available.
Presuming 512 bytes per sector, if the drive has 26 sectors per track (a
"normal" figure)…you can read 13,312 bytes every 60th of a second. If
you get a higher density drive, one that has 35 sectors per track…you can
read 17,920 bytes every 60th of a second.
Thus…the maximum you can get at 60fps would be a low-res 4 color
full frame animation. This presumes very little, if any, head movement is
required to read the data.
Don
The only HD-anims I have seen so far were lo-res, non-interlace. So that
would confirm you figures (so far).
There are several factors involved in playing anims from disk, however. As
you know, anims rarely store entire images, but rather the delta changes.
So to some extent it comes down to the amount of change in each image, how
fast your processor is, how efficient your disk reads/image expansion is,
etc, etc, right?
And let's face it, how often do you NEED 60fps? The majority of my work is
designed for 15fps. So far I've managed entirely with ram anims, and
sequencing them together, but I'd like to be able to do moderate
complexity, lo-res, oscan anims from disk at that speed. (and soon hires,
oscan, for HAM-E anims).
Thanks for your calcs. It made the limitations much clearer to me.
–jp–seattle–
keep in mind that doing overscan is going to take chip ram time away from
your CPU, and it needs all the time it can get to pump that data through.
Craig
Doing the basic math, 60 frames/second * 120 Kbytes/frame = appr. 7
Mbytes/sec. That is very optimistic, even on an A3000 or a GVP with 32bit
HD.
— Ethan
Ethan,
The absolute maximum rate you can get the data off any drive
currently available for the Amiga (no matter what controller/CPU
combination) is a *sustained* rate of slightly more than 1 Megabyte per
second.
That is simply the maximum rate that the data bits come under the
head of a drive spinning at 3600 rpm with 35 data sectors of 512 bytes
each.
Burst rates can be significantly higher…but you can't sustain a
data rate any faster than the data comes under the head that's currently
being read.
Don
Luckily, not all drives are 512 bytes/sector. I am using a drive that uses
2K bytes/sector and get almost 1.6 MB/sec sustained.
– Steve –
Steve,
How many sectors per track and what's the speed of the platter?
When I say 35 sectors per track at 512 bytes per sector…it could
have just as easily been 17 sectors per track at 1024 bytes per sector or 9
sectors per track at 2048 bytes per sector.
The point being that there are only X number of bytes available on
the track and the track can only pass under the head at a certain speed
based on the rotation of the platter. There's just no way you can read
data faster than it passes under the head.
Don
Jumping in again, remember all that most anims use (hopefully) very
compressed data (just deltas, and maybe palette info). So, you don't need
to store (320x400x5/8=) 80,000 bytes on HD for each frame, right? The
question is, what sustained speed can the HD read, and is there enough time
left for the 68000/030/etc to expand that data in real-time? I suppose a
good HD buffering scheme would help, cause not each frame needs the same
amount of processing time as each other one.
There must be an optimal controller/HD combo to store/use disk-based anims?
All things being equal, I'd assume that faster controllers/HD's are
better? But if you're running up against some fundamental limits of
transfer rates and processor times, then at a certain point the optimum is
reached, right? –jp–seattle–
Yes…that's why I mentioned 'full frame' animations…meaning the
whole frame is loaded each time. Yes, if you're loading in only the
deltas, then your data needs can be significantly smaller. The quality of
the animation is also a concern. Something like a Disney full featured
animation will have many more changes per frame than something like the
typical 'Saturday morning cartoon' style of animation.
The type of controller can also make a difference. A DMA
controller can be reading the data while CPU is decompressing it. A
non-DMA controller has to use the CPU to get the data off the drive, thus
it's not available to do the decompression at the same time. So depending
on how much CPU time is required to decompress, which is dependant on how
much data is needed per frame, a DMA type card *may* end up being
significantly better than a card that uses the CPU. IF the CPU needs
aren't great, then both cards would come out about the same.
As to data cacheing…again, it depends on how much data is needed.
IF you need X amount of data off the drive, but the drive head can only
travel over .75 X amount of data in that same time period…drive cache
won't help since you can't cache data any faster than you can read it.
However, if you only need X data and the heads pass over 2X amount of
data…cacheing can speed things up significantly because the drive can
'read-ahead' and have the data already read and in cache before you need
it.
Interesting data just picked up in a TV magazine, FWIW:
The typical "Saturday morning cartoon" uses 15,000 cels in a half hour
show. A new show (starting tomorrow) called Dark Water is using 24,000.
Malcolm
Yeah, that sounds about right; 15,000 cells @ 15fps = 1,000 seconds = 16.66
minutes of animation. About the right amount (after subtracting titles,
commercials, etc) So much of the current batch of Sat toons are abysmal,
however, with limited motion, etc. I'll have to check out Dark Water.
Give me the 40-50's LooneyTunes, Silly Symphonies, etc anyday.
–jp–seattle– (just a wrong turn north of Albuquerque)
burst rate is probably the relevant figure when you have to take time to
decompress the anim images anyway. my seagate 2383N gives 1,500K/second
read/write measured by DiskSpeed. makes a substantial difference relative
to the 750K/second with the quantum40. some drives can transfer at
substantially faster than the 1 megabyte/second you're claiming.
Dan,
The largest drive figures I'm aware of spin at about 4000 rpm and
have upto 42 sectors per track. Presuming 1:1 interleave, that means in
one minute, the drive head passes over 4000 x 42 sectors. 168000 sectors
x 512 bytes per sector is 86,016,000 bytes per minute. Divide by 60 and
you get 1,433,600 bytes per second.
That does not take into account the drive doing anything except
reading that one track over and over again. As soon as you get into head
stepping, that number drops off rapidly.
Now, a drive with a 64k cache *could* already have that data in the
cache, thus isn't restricted by how fast the data comes under the
head…but rather how fast the cache can be read and how fast it can be
pumped over the bus.
But presuming the data isn't in the cache, or that the amount of
data you want is larger than the cache…then the rate that data can be
read off the drive becomes the limiting factor since the cache can empty
faster than it can be filled.
You simply can't read data off the disk any faster than the data
comes under the head (any one head…since that's all that can be read at
once for the type of drives we're talking about here) when you are talking
*sustained* rates.
Burst rates…yes..and even relatively long bursts IF the data is
already in the cache…but for larger files…spin rate and sectors per
track is the limiting factor.
Don
you could very well be right. i don't know if data is read from multiple
head drives differently than you say. i'm just not sure. if you are
reading compressed anim frames one by one then waiting for cpu
decompression before reading the next one (non-dma SCSI controller) then
burst might well be king. for FractalPro, the average frame is about 64K
as IFF, probably much less when compressed into an anim frame and burst
speed might be the key to high frame rates when playing anim direct from
hd. 1.4 megabytes per second is plenty fast to get an anim frame off in
about 1/20 second. not bad. i wish i knew exactly what was happening when
and how fast in some other folks's programs (like diskanim from MindWare)
but i just don't. i do know that when i do simple page flips with Director
i get 2/second from the Quantum and 3/second from the 2383N. similar about
50% increase using diskanim favoring the 2383N. have no idea what iit
really means when DiskSpeed says i'm getting 1,500K/second read/write –
perhaps it is only burst, but anyone who knows for sure please shout. if
diskanim gave the same advantage for the 2383n as DiskSpeed implies, then
i'd get 2x as many frames per second on diskanim, but i'm only getting
about 50% more – so something does get in the way … maybe head motion.
Sure the fast drives don't alternate reading from different heads as the
disk spins and still not miss data on a single head? Got a feeling they do
but await definitive comments from the really smart folks out there
(besides the Sysop, of course!).
Dan,
I know of no consumer type HD units that can read more than one
head at a time. I do know of some *very* expensive commercial units that
can do that. These drives, can read the data as the equivalent of a
parallel read rather than a serial read with each head reading one bit of a
byte at a time (thus 8 heads all being read at once read a byte at a time).
Thus you can read 8 times as much data in one rev of the platter.
The type of drive you'll find on a personal computer can only read
the data as fast as the data passes under any one head, as I've already
explained. But what it does with that data in the way of presentation to
the host computer, and how intelligently it gets the data can make a large
difference in performance. For example, if the drive is real dumb, and
every time it reads a byte…it sends it down the bus and then every time
the host adapter gets a byte…it passes it to the CPU then the CPU is
going to get interupted 512 times per sector. It'll have to stop what it's
doing and move that byte into RAM. However, if that same drive cached the
data until it got say 64 bytes, and then dumped it all at once…and the
host adapter were DMA capable…then the CPU would never get interupted
until the whole read was done (whatever size of read it had requested).
Also, another way to up the apparent speed of a drive is an
intelligent read-ahead scheme. Let's say the CPU asked for sectors # 25
and #26. It's a fair bet that the next request will be for sectors #27 and
#28…so the drive goes ahead and reads them into an on-board cache. IF
the CPU does in fact ask for 27 and 28, they are already in the cache and
can be dumped immediately…whereas if the request is for some other
sectors…nothing is lost…because no matter what, those other sectors
have to be read…they're just not already in memory.
Another way is simply ot have a large cache of recently read
sectors on the drive. If the next request from the CPU is for one of those
sectors…again, it is sipmly a matter of dumping what's already in the
cache with no read required from the heads.
Well, you answered my question too. Oh well; it was nice THINKING that
maybe multiple heads could be read at the same time. It sure makes sense,
and couldn't be THAT expensive to implement, could it? –jp–seattle–
John,
Yup…it is very expensive to have all heads write at once. Among
other things…the whole logic of how a drive works and stores data would
have to change.
Among the changes needed, absolute syncronization of the heads is
required, the amount of circuitry needed goes up by a factor of 8 or more
and so forth.
Error correction becomes harder as does handling defects in the
media itself.
As an example, we've got some commerical drives at work that use
multiple heads at once. It's done by having two complete sets of heads.
Reads or writes are alternated between the sets of heads…thus it's
possible to do 2 reads or 2 writes at any one time. The drives hold 500
Megabytes of data and cost $25,000 apiece.
Compare that with a consumer type of 500 MB drive that costs in the
$1,000 price range.
What more heads does for you in a consumer type drive is give you
several things:
1. You can write more data without stepping the heads. Timewise,
stepping the heads is a relatively expensive operation when compared with
simply switching from one head to another.
2. You can store more data in the same size package…because more
heads means more surfaces (platters) that can be used.
3. Economies of scale…the same basic circuitry is needed for a 2
headed drive and a 6 headed drive. All that really needs to be added are
the additional platters and heads and perhaps a slight bit more switching
circuitry.
Don
thanks again, don. i surely defer to your explanation i'd like to know
how i get 1,500K per second with DiskSpeed – if that's only a 'burst'
measurement or is it sustained – which would seem to be close to the
theoretical limit you mentioned in previous message. appreciate the
continuing enlightenment on drive theory. hope others read this thread and
learn something which may help us all to distinguish hype from practicality
in the drive speed game. as i mentioned – even the 2x faster apparent
speed of my 2383N doesn't result in 2x faster real world performance, but
about 50% better. i do think transfer rate is the difference here. what
does transfer rate really mean from the perspective you've been explaining
in this thread?
DAn,
Without looking at the source code..it'd be hard to be specific on
exactly why it's reporting what it is. For example, if the speed test uses
DOS calls, then the amount of buffers (addbuffer or mountlist buffers
parameter) can make a significant difference…you're not really reading
the drive…you're reading the buffers.
At the hardware level…if you're reading/writting the same sector
over and over again…cacheing on the drive would act the same…you'd be
working from the cache rather than the platters. One other thing could be
turning the clock on only while data is actually being transfered.
A simple way to test is to create a 1 meg file. Copy it to NIL:
and time it. Then copy it to another filename. I think you'll find it
takes significantly longer than a 2/3rds of a second.
Don
that's a good point. If my drive has six heads, couldn't they all be
reading data at the same time? When I write to a disk with six heads, is
the information all written on the same platter? (ie all by one head); or
is it shared among all platters/heads? –jp–seattle–
John,
No, a drive with 6 heads can't read/write all heads at once…at
least not a drive in the consumer price range. It's one head at a time,
thus the answer to the second part of your question is all information is
written on one side of one platter
That presumes a small amount of data..small enought to fit on the
free room left on a single track. Larger amounts of data are spread over
the platters, one head at a time.
Presuming an empty drive, when a large write is done, the first
head writes as much data as it can, then the 2nd head writes as much as it
can, then the 3rd head and so forth. After the last head is done writting,
the head mechanism steps all the heads at once (the heads are bolted to the
mechanism…they all move at once) to the next track and the process starts
over again.
Exactly where the write is done is controlled by the filesystem in
use, that is…it decides exactly where it wants the data written and
simply issues "orders" to the drive.
Don
don curtis says our drives only write/read one head at a time. I'm not
positive, but don sounds authoritative enough i still wonder, though.
john, are you same JP as is one of my FractalPro customers? tried any HAM
interlace FPro anims from disk? I have and they do work fairly well using
Mindware's TASS 'diskanim' player – up to about 5-8 fps off a quantum40.
about to try some from a seagate 2383N which should be up to 2x as fast.
looking into the uncompressed format used by Vista. will report when
possible.
Yes, I am the same jp. No, I haven't tried any disk-based anims with
FractalPro yet. I'm not crazy about the TASS player; never got TASS to
work right for me; still trying 🙂
BTW, I've been using your FractalPro Vista save feature to generate 256
color HAM-E Mandelbrot images (planar images, not mountains). THANKS for
adding that option! (as well as using them with Vista, of course) (but it
SURE would be nice if you added some aspect correction; and chose the
MIDDLE of the FractalPro image to generate the Vista data from, rather than
the lower left)
Your comments re disk speed were interesting. All things being equal,
wouldn't sustained disk transfer time be more important than burst mode?
Otherwise wouldn't the anim be jerky? –jp–seattle–
thanks, john – very glad you like the new features. maybe will center
vista feature next time 'round. it was added near the end of development
and things were starting to drag out pretty long past expected ship date.
hope it's not a big problem for now. how does the vista option let you
make 256-color planar ham-e images? i'd like to pass the word on to ben at
the ham-e factory up in montana. he wanted 24-bit or at least 8-bit color
in fpro, but 24-bit is nearly meaningless (mathematically) on an Amiga.
the thing about burst is that anim decompression takes some of the time
when playing a disk anim – so if burst lasts long enough to get a frame,
then cpu must decompress it, burst speed might be more important than
sustained. who knows? i've used the diskanim player from DigiMate3 and
MindWare's new Credit Text Scroller and they both work – TASS public domain
never did work right. if you're interested, give mindware's real products
which incorporate diskanim a try. be seein' ya. :-)' DW p.s. if you
really like FPro4.0, don't keep it a secret!
Well, I DO like FractalPro 4.0 a lot. [there are features I would like to
see, but since I didn't write in asking for them, I cannot complain 🙂 ]
The centered Vista feature would be very nice; but as (more?) important is
the aspect correction. Oval versions of the set are just not toooo
attractive in Vista for some reason. I can imagine several ways to do it,
but I'll leave it to you.
How am I doing 256 color images using Vista/HAM-E? Easy. I just parse
your FractalPro/Vista file using ARexx, find the heights of each 258×258
points, and send it to HAM-E RegPaint via ARexx. Sending points over via
ARexx is not too fast (it can take 15-30 mins to plot a picture), but it
works fine. Processing via ARexx also allows nice color effects as well,
such as scaling the data, blurring boundaries, etc. I think I uploaded an
early version of the program to Ben's BBS; maybe I'll send up a later
version soon. (I think the pics are pretty nice. Verrry smooth coloring
in the boundary areas; look particularly nice with cycling)
I'm thinking of just directly converting your data over to a HAM-E IFF
image, rather than going through REGPaint's rexx port. Would be much
faster. But I wanted to experiment with the rexx port, so I made my first
cut that way.
By the way, my first version of HAM-E mandelbrots didn't use FractalPro at
all. I did all the mandelbrot calculations in the ARexx program, and sent
them over to REG Paint directly after done. It worked fine. Well…. it
was also sssssllllloooooowwwwww. It took 3-4 hours for one medium-size
image, at 100 iterations. That's when I thought of using FractalPro's
VISTA files as source, and just plotting the data differently.
Thanks for your comments on TASS. I'll check out the newer versions.
–jp–seattle–
at first i didn't know what you meant by ovals and aspect ratio problems –
but that has to do with Vista, not FractalPro if I read you right. I've
noticed the same thing but I have some problems using Vista (won't start up
from Icon on my system) so i don't use it that much – but it does distort
the aspect ratio. don't know much about HAM-E or RegPaint. Too busy with
bar code reader development these days to do much recreational computing.
also getting ready to try 1.2 gig DAT tape backup units. the one thing i
meant to mention – I was quite sorry to have missed you at my booth at
AmiExpo last fall. You had called me and I was looking forward to meet you
and you managed to slip into the booth and get what you needed all in the
space of a very few (rare) minutes I managed to slip out of the booth. It
was real busy and I think i got away for a total of about 1 hour over the 3
days! Wouldn't you know it was when you stopped by. Hoped you'd have time
to come back, but … Look forward to meet you. Please do write and
suggest what you'd like to see in FractalPro5.0! Thanks for the kind words
on FractalPro4.0. It is really a pretty grown-up program compared to 1.0.
Hope your feelings are mirrored by the other upgrade owners. DW good luck
with new TASS.
The aspect ratio problem (when saving the FractalPro –> Vista files) is
caused by mapping a 320×400 aspect ratio for FractalPro data points to a
268×268 aspect ration for Vista data points. So a round area in FractalPro
becomes oval in Vista, right?
I can't see how Vista is going to change things, since their data format is
set – square @ 268×268. One solution I can see would be for FractalPro to
calculate a different set of iteration values, based on the Vista 1:1
aspect ratio, rather than the screens 320:400. You could use the set point
at the exact middle of the screen (160,200) as the middle of this new set,
and work backwards to get the upper-left starting corner, etc. You could
always use the same points you'd already computed and interpolate, but that
would violate the spirit of fractals, right? 🙂
Your data works fine with my HAM-E conversion since I am also plotting to a
320×400 screen.
I was sorry to have missed you at the AmiExpo too. I dropped in several
times, and talked with your assistant, but never had the chance to meet
you. I may be in your area in over the summer and would make it a point to
drop by. You'll at least get a long letter regarding FractalPro 5.0 from
me! ttfn –jp–seattle–
Hiya … I have a Nexus controler … Works great Hear are some good
points 1 NOT DMA 2 Works with Amax 1800 tech support very helpfull people
can hold memory and works with accelerators ex that i have Hurricane 500
works great no probs
… the only bad thing about it is that it can only hold 4 megs of ram ii
wish it could hold more that is about it… any more questions just ask Oh
also they have GREAT backup software … and also there software (Fastback)
backup software you can use the program with the tape backup ] software