nick@hp-sdd.HP.COM (Nick Flor) (12/15/86)
The other day, I was flipping through a friends AmigaWorld, when I saw an advertisement for a 20mb hard disk that connected, not to expansion connector, but to the parallel port. Are there any drawbacks to this implementation? Just curious... Nick -- + Disclaimer: The above opinions are my own, not necessarily my employers. / Nick V. Flor / ..hplabs!hp-sdd!nick / Hewlett Packard, San Diego Division * "What's going down in this world, you got no idea. Believe me." - The Comedian
grr@cbmvax.cbm.UUCP (George Robbins) (12/16/86)
In article <634@hp-sdd.HP.COM> nick@hp-sdd.UUCP (Nick Flor) writes: > >The other day, I was flipping through a friends AmigaWorld, when I >saw an advertisement for a 20mb hard disk that connected, not to >expansion connector, but to the parallel port. > >Are there any drawbacks to this implementation? > Well, since there is no DMA support available for the Parallel Port, the actual data transfer part of the disk activity will be slower than a DMA type disk controller attached to the Expansion Bus. Does the device have some kind of pass through for the printer? However, the benefits of having a reliable Hard Disk may easily outweigh the these issues. A hard drive is much nicer than a rackful of floppys... -- George Robbins - now working for, uucp: {ihnp4|seismo|rutgers}!cbmvax!grr but no way officially representing arpa: cbmvax!grr@seismo.css.GOV Commodore, Engineering Department fone: 215-431-9255 (only by moonlite)
eric@ulysses.homer.nj.att.com (Eric Lavitsky) (12/17/86)
>George Robbins (cbmvax!grr) Writes: >Well, since there is no DMA support available for the Parallel Port, the >actual data transfer part of the disk activity will be slower than a DMA >type disk controller attached to the Expansion Bus. A bit of clarification here: George is correct, but: The only thing DMA really buys you on the Amiga currently, is the fact that data trasnfers don't interrupt the CPU. The maximum *actual* throughput for current DMA vs. non DMA disks is currently limited by AmigaDOS, which can only chug through about 35K/Sec. So, a disk on the parallel port, if designed correctly, will get you at least close to that limit and a DMA disk cannot surpass that limit (at least not the ones that currently exist). Of course, if you're not using AmigaDOS, that's another story... Has anyone used the disk benchmark recently posted by Rick Spanbauer on some of the popular Amiga hard disks? Eric
dillon@CORY.BERKELEY.EDU (Matt Dillon) (12/18/86)
>vs. non DMA disks is currently limited by AmigaDOS, which can only chug >through about 35K/Sec. So, a disk on the parallel port, if designed correctly, >will get you at least close to that limit and a DMA disk cannot surpass >that limit (at least not the ones that currently exist). Of course, if >you're not using AmigaDOS, that's another story... Actually, if you take RAM: timing as the theoretical maximum, it's more around 150-200K/Sec. -Matt
eric@ulysses.homer.nj.att.com (Eric Lavitsky) (12/18/86)
> Actually, if you take RAM: timing as the theoretical maximum, it's >more around 150-200K/Sec. > > -Matt Actually, it isn't. Using RAM: speeds is not a good metric for measuring AmigaDOS throughput. RAM: implements it's own handler - l:Ram-Handler and does not use a normal AmigaDOS filesystem. A physical disk device or Recoverable Ram Disk like ASDG's uses a normal AmigaDOS file handler which provides only 35K/Sec maximum throughput, and you had better use it on a disk if you want to be 100% compatible... Eric -- ARPA: Lavitsky@RED.RUTGERS.EDU UUCP: ...ulysses!eric ...caip!topaz!eric ...hplabs!well!lavitsky
perry@well.UUCP (Perry S. Kivolowitz) (12/19/86)
In article <8612180630.AA23659@cory.Berkeley.EDU> dillon@CORY.BERKELEY.EDU (Matt Dillon) writes: >>vs. non DMA disks is currently limited by AmigaDOS, which can only chug >>through about 35K/Sec. So, a disk on the parallel port, if designed correctly, >>will get you at least close to that limit and a DMA disk cannot surpass >>that limit (at least not the ones that currently exist). Of course, if >>you're not using AmigaDOS, that's another story... > > Actually, if you take RAM: timing as the theoretical maximum, it's >more around 150-200K/Sec. > > -Matt Wrong Wrong Wrong Matt. RAM: does not give an accurate indication of true AmigaDOS filesystem throughput because the RAM: is a handler not a device. Thus it implements it OWN file system. RAM: is much faster than AmigaDOS would otherwise let it.
ross@ulowell.UUCP (Ross Miller) (12/20/86)
In article <1537@ulysses.homer.nj.att.com> eric@ulysses.UUCP (Eric Lavitsky) writes: > >> Actually, if you take RAM: timing as the theoretical maximum, it's >>more around 150-200K/Sec. >Actually, it isn't. Using RAM: speeds is not a good metric for >measuring AmigaDOS throughput. RAM: implements it's own handler - >l:Ram-Handler and does not use a normal AmigaDOS filesystem. A >physical disk device or Recoverable Ram Disk like ASDG's uses a >normal AmigaDOS file handler which provides only 35K/Sec maximum >throughput, and you had better use it on a disk if you want to be >100% compatible... Hmmm, If this is true, then it would greatly benifit all hard disk users, if the hard disk company in question supplied a non-standard driver with their disk. Ross uucp: wanginst!ulowell!ross csnet: ross%ulowell.csnet@csnet-relay.arpa
bj@well.UUCP (Jim Becker) (12/21/86)
mer.nj.att.com> Sender: Reply-To: bj@well.UUCP (Jim Becker) Followup-To: Distribution: Organization: Whole Earth Lectronic Link, Sausalito CA Keywords: hard disks, DMA, AmigaDOS In article <1527@ulysses.homer.nj.att.com> eric@ulysses.UUCP (Eric Lavitsky) w rites: >>George Robbins (cbmvax!grr) Writes: >>Well, since there is no DMA support available for the Parallel Port, the >>actual data transfer part of the disk activity will be slower than a DMA >>type disk controller attached to the Expansion Bus. > >A bit of clarification here: George is correct, but: The only thing DMA >really buys you on the Amiga currently, is the fact that data trasnfers >don't interrupt the CPU. The maximum *actual* throughput for current DMA >vs. non DMA disks is currently limited by AmigaDOS, which can only chug >through about 35K/Sec. So, a disk on the parallel port, if designed correctly , >will get you at least close to that limit and a DMA disk cannot surpass >that limit (at least not the ones that currently exist). Of course, if >you're not using AmigaDOS, that's another story... > >Has anyone used the disk benchmark recently posted by Rick Spanbauer on >some of the popular Amiga hard disks? > >Eric Eric, I know that you are int the know, but in this case you are incorrect. the DMA is much faster than what can happen on the parallel port. What transpires on the expansion bus if difficult to get used to, although one adapts to the speed in time and cna await the 2 to 3x speed improvement in the DOS that is coming. The Parallel port doesn't have DMA, but the serial port does. Noone has tapped this yet though. It will be inconsiquential though, when the Pal Jr comes out there will be a new standard that will take a while for the human to get used to, especially with InfoMinder Plus. Amiga will be the future, espiecially if C-A realizes it. -Jim Becker Terrapin Software
wagner@utcs.UUCP (12/22/86)
In article <1527@ulysses.homer.nj.att.com> eric@ulysses.UUCP (Eric Lavitsky) writes: >Has anyone used the disk benchmark recently posted by Rick Spanbauer on >some of the popular Amiga hard disks? Just a word of warning...Rick's program has some problems. It leaves a file lock on one of it's files, and doesn't check when creating the file. This means that it can't be run a second time. The net result seems to be a zero (error) return code is being used as a file lock, and the benchmark program tries to use DF0: instead of what it was given. Still investigating.... Michael
wagner@utcs.UUCP (12/22/86)
Since we're on the topic of disk performance, I thought I'd point out a surprising result that I've gathered so far. The cache incorporated in 1.2 doesn't really seem to improve the timings of Rick's benchmarks, in general. That isn't too surprising....he goes to some trouble to make it difficult for a cache to work well in his benchmarks. However, one thing does speed up tremendously....deleting files! So now we can say that the cache makes it quicker to trash things....a great improvement! Michael
miner@ulowell.UUCP (Richard Miner) (12/22/86)
In several articles lots of people write: ...a disk on the parallel port can be close to the speed of a board on the expansion bus... - They even mention DMA on the serial port. A board on the expansion bus can grab the Amiga's bus and blast data into memory as fast as it takes to light up the address and data buses and trip the read/write strobes. Once the board has the address of an internal data buffer the DMA cycle far surpasses an assembly loop reading the serial or parallel ports. When we speak about DMA for hardrives we mean direct access to the systems bus. The solution is a nice address generating chip and a little 680xx bus arbitration logic. Perhapse all on a single LSI chip like the hardware group at Commodore came up with. Why are'nt more people taking this aproach? The logic to interface with the Zorro bus is not that complex, are address generators that expensive? PS (to weschester support) Thanks for the response to manx multitasking question, and great suport in 86, happy holidays and new year. -- Rich Miner ...!wanginst!ulowell!miner Ulowell, Center for Productivity Enhancement (617) 452-5000 x2693 HAL hears the Amiga9000 series is not selling. "Please explain Dave. Why aren't Amiga9000's selling?" Bowman hesitates, "You aren't IBM compatible."
hamilton@uxc.cso.uiuc.edu (12/22/86)
bj@well says: > The Parallel port doesn't have DMA, but the serial port does. Noone has tapped > this yet though. fascinating, if true. could you amplify? wayne hamilton U of Il and US Army Corps of Engineers CERL UUCP: {ihnp4,pur-ee,convex}!uiucdcs!uiucuxc!hamilton ARPA: hamilton%uiucuxc@a.cs.uiuc.edu USMail: Box 476, Urbana, IL 61801 CSNET: hamilton%uiucuxc@uiuc.csnet Phone: (217)333-8703 CIS: [73047,544] PLink: w hamilton
eric@topaz.RUTGERS.EDU (Eric Lavitsky) (12/23/86)
In article <881@ulowell.UUCP> ross@ulowell.UUCP (Ross Miller) .>In article <1537@ulysses.homer.nj.att.com> eric@ulysses.UUCP (Eric Lavitsky) writes: .>> .>>> Actually, if you take RAM: timing as the theoretical maximum, it's .>>>more around 150-200K/Sec. .>>Actually, it isn't. Using RAM: speeds is not a good metric for .>>measuring AmigaDOS throughput. RAM: implements it's own handler - .>>l:Ram-Handler and does not use a normal AmigaDOS filesystem. A .>>physical disk device or Recoverable Ram Disk like ASDG's uses a .>>normal AmigaDOS file handler which provides only 35K/Sec maximum .>>throughput, and you had better use it on a disk if you want to be .>>100% compatible... .>Hmmm, .> If this is true, then it would greatly benifit all hard disk .>users, if the hard disk company in question supplied a non-standard .>driver with their disk. .> .> Ross No no!, Please no! Do *not* supply a non-standard driver!!! That is not the way to solve the situation. The way to solve it is to attack it at its' heart - AmigaDOS itself, which apparently Tim King has done according to Phil Lindsays' latest tidbits... Eric -- ARPA: LAVITSKY@RUTGERS or LAVITSKY@RED.RUTGERS.EDU UUCP: ...topaz!eric ...hplabs!well!lavitsky ...ulysses!eric
eric@topaz.RUTGERS.EDU (Eric Lavitsky) (12/23/86)
In article <2241@well.UUCP>, bj@well.UUCP (Jim Becker) writes: .>In article <1527@ulysses.homer.nj.att.com> eric@ulysses.UUCP (Eric Lavitsky) w rites: .>>>George Robbins (cbmvax!grr) Writes: .>>>Well, since there is no DMA support available for the Parallel Port, the .>>>actual data transfer part of the disk activity will be slower than a DMA .>>>type disk controller attached to the Expansion Bus. .>> .>>A bit of clarification here: George is correct, but: The only thing DMA .>>really buys you on the Amiga currently, is the fact that data trasnfers .>>don't interrupt the CPU. The maximum *actual* throughput for current DMA .>>vs. non DMA disks is currently limited by AmigaDOS, which can only chug .>>through about 35K/Sec. So, a disk on the parallel port, if designed correctly .>>will get you at least close to that limit and a DMA disk cannot surpass .>>that limit (at least not the ones that currently exist). Of course, if .>>you're not using AmigaDOS, that's another story... .>> .>>Eric > >Eric, > >I know that you are int the know, but in this case you are incorrect. the DMA >is much faster than what can happen on the parallel port. What transpires on >the expansion bus if difficult to get used to, although one adapts to the speed >in time and cna await the 2 to 3x speed improvement in the DOS that is coming. Well Jim, thank you - I know that you are in the know as well, and I think that InfoMinder is a great product, but... I never suggested that there was any DMA on the parallel port, or that the parallel port was as fast as the expansion bus. I still stand behind what I said. Perhaps a little further clarification is necessary... Imagine the following: you drive a Lamborghini :-). Of course, this car can outpreform just about any other car in America. Bring the car onto your average American highway however, and you will be forced to do about the same speed as the other cars on the road (though it may take you less effort). Why?, because the American roads are so bad they limit you to a slower speed (this is a documented fact :-)... So currently (and I underline that word), the bottleneck is AmigaDOS (as you even pointed out). Yes, it is good news that Tim King has finally done something about it, and when it's finally generally available (how long do you think it will take?), there will be no question that DMA disks are oodles faster than any other. But for now, everyone has to travel on the same road (note that I'm still talking about throughput through AmigaDOS, *not* raw data transfer rates). So: Parallel port 30K/Sec => AmigaDOS =>User ~= Expansion Bus 10Mbit/Sec => AmigaDOS =>User Does that explain my point better? Another important thing to mention is that Phil's news about Tim Kings' fixes was news to me after I sent my message out... so all this may be moot (when the improvements see the light of customers' hands)... >The Parallel port doesn't have DMA, but the serial port does. Noone has tapped >this yet though. It will be inconsiquential though, when the Pal Jr comes out >there will be a new standard that will take a while for the human to get >used to, especially with InfoMinder Plus. Yes, but to tie up the serial port with a hard disk would be a very big mistake - one often wants his disk available while online with another host, you could always wait for the printer, right? :-) >Amiga will be the future, espiecially if C-A realizes it. > >-Jim Becker >Terrapin Software Eric (I hate inews) Lavitsky -- ARPA: LAVITSKY@RUTGERS or LAVITSKY@RED.RUTGERS.EDU UUCP: ...topaz!eric ...hplabs!well!lavitsky ...ulysses!eric
louie@sayshell.umd.edu (Louis A. Mamakos) (12/23/86)
In article <8088@topaz.RUTGERS.EDU> eric@topaz.RUTGERS.EDU (Eric Lavitsky) writes: >In article <2241@well.UUCP>, bj@well.UUCP (Jim Becker) writes: >.>In article <1527@ulysses.homer.nj.att.com> eric@ulysses.UUCP (Eric Lavitsky) w >rites: >>The Parallel port doesn't have DMA, but the serial port does. Noone has tapped >>this yet though. It will be inconsiquential though, when the Pal Jr comes out >>there will be a new standard that will take a while for the human to get >>used to, especially with InfoMinder Plus. > >Yes, but to tie up the serial port with a hard disk would be a very >big mistake - one often wants his disk available while online with >another host, you could always wait for the printer, right? :-) > Hmmm.. from all that I've seen, the serial port doesn't do DMA. It just generates interrupts. Both the hardware manual and disassembly of the serial driver seem to bear this out. It's a real shame it doesn't. In any case, another issue to examine when considering a DMA disk vs. an interrupt driven one is the effect on the rest of the system. Even though the bandwidth to the disk is the same, the DMA design should all the CPU time to service other tasks in the system. The non-DMA version will consume more CPU resources to get its job done. Ain't this multitasking just grand? A computer that can walk and chew gum at the same time! Louis A. Mamakos WA3YMH Internet: louie@TRANTOR.UMD.EDU University of Maryland, Computer Science Center - Systems Programming