kim@amdahl.amdahl.com (Kim DeVaughn) (05/21/87)
[ Some days you eat the line ... some days the line eat's you ... ]
I just talked to Steve at Abel Supply in Tennessee about a couple of items,
and we got to chatting about various things, and somewhere along the way,
he mentioned that they would be getting ASDG's "Floppy Accelerator" in pretty
soon.
Not having heard of this product, I asked if it was h/w or s/w (we'd been
talking about h/w). "Software", he replied ... "supposed to make floppy
accesses *much* faster".
So I ask ... has anyone one the net heard of the "Floppy Accelerator"? Any
beta testers who care to comment (if they are permitted to)? What's up,
Perry?
Further rumors:
As an aside, I asked if they had any word on A500/A2000 availability.
"Nothing official", was the reply, but they are guessing at June for the
A500, and August (sigh) for the A2000.
Digi-Paint from New-Tek should (finally) be shipping within 10 days.
/kim
--
UUCP: kim@amdahl.amdahl.com
or: {sun,decwrl,hplabs,pyramid,ihnp4,seismo,oliveb,cbosgd}!amdahl!kim
DDD: 408-746-8462
USPS: Amdahl Corp. M/S 249, 1250 E. Arques Av, Sunnyvale, CA 94086
CIS: 76535,25cmcmanis%pepper@Sun.COM (Chuck McManis) (05/21/87)
In article <6805@amdahl.amdahl.com> (Kim DeVaughn) writes: >So I ask ... has anyone one the net heard of the "Floppy Accelerator"? Any >beta testers who care to comment (if they are permitted to)? What's up, >Perry? We were discussing ways to speed up floppies on BIX and began hypothesizing about a utility to cache tracks of a floppy in fast ram. It was pretty much spec'd out how you would do it and Perry complained every time he figured out a neat hack to make into a product everyone else did too. So I can put 2+2 together and guess that that is what he was talking about. Which brings up two things of interest... First the developer community is moving right along up the learning curve, as they do the Amiga gets better and better. Every time I think I have to totally whomp on the O/S to do something I find there is a 'nice' way to do it. Thanks Dale, Carl, Bob, Rob, RJ, Bob, Bob, Sam, Jim, Neil, et al for a very well thought out hacking path. Second, I firmly believe that good programmers share a subconcious(sp?) esp. Whenever one thinks of a good idea everyone seems to pick up on it until everyone announces the same idea at the same time. It is really weird. --Chuck McManis uucp: {anywhere}!sun!cmcmanis BIX: cmcmanis ARPAnet: cmcmanis@sun.com These opinions are my own and no one elses, but you knew that didn't you.
daveh@cbmvax.cbm.UUCP (Dave Haynie) (05/21/87)
in article <6805@amdahl.amdahl.com>, kim@amdahl.amdahl.com (Kim DeVaughn) says: > Keywords: ASDG floppy accelerator speed faster Digi-Paint A2000 availability > So I ask ... has anyone one the net heard of the "[ASDG] Floppy Accelerator"? Any > beta testers who care to comment (if they are permitted to)? What's up, > Perry? There was a thread about this going on in BIX awhile ago, at least I think that's what this product refers to. Simply put, its a program that adds intelligent track caching (i.e. at the device level) instead to DOS's block caching. Also, the caching memory can be FAST memory; its not required to be chip memory as are normal floppy buffers or DOS's block caches. From what Perry said, you have the power to add or remove caches at any time. With enough tracks cached, you get what essentially amounts to a RAMdisk overlay of a floppy disk. > > /kim -- Dave Haynie Commodore-Amiga Usenet: {ihnp4|caip|rutgers}!cbmvax!daveh "The A2000 Guy" BIX : hazy "These are the days of miracle and wonder" -P. Simon
eric@hector.UUCP (05/22/87)
Kim -
I have been using FACC for about 3 weeks now. It's made BBS-PC!
tolerable! Try calling JABS at 201-563-9057, I'm running it
completely on floppies using FACC - you'd think it was from a fast
hard disk!
Here's what's written on the back cover of the FACC package:
FACC is a dynamically managed buffer cache which speeds access
to your floppy disk drives. Unlike AddBuffers:
o FACC fully supports fast memory so your buffer cache
will not use any valuable CHIP memory and can be as
large as you like ;
o FACC allows dynamic control over it's buffers. Buffers
can be added or subtracted at will ;
o FACC presents a graphic display detailing cache
effectiveness, allowing you to tailor cache size or
observe disk operations as they occur ;
o FACC's display will shrink to a small size when
desired, to help keep your WorkBench uncluttered.
Note: While FACC will be of benefit to any and all Amiga owners,
FACC will be of greatest service to owners of Amigas with
more than 512K.
I think that describes the package quite well. The disk is *not* copy
protected (and says so on the package!). It's available now, ask your
dealer for it or contact ASDG directly.
Eric
ARPA: Lavitsky@RED.RUTGERS.EDU
UUCP: ...{wherever!}ulysses!eric
...{wherever!}rutgers!topaz!eric
SNAIL: 34 Maplehurst La., Piscataway, NJ 08854scotty@l5comp.UUCP (05/25/87)
In article <2599@ulysses.homer.nj.att.com> eric@hector (Eric Lavitsky) writes: > Note: While FACC will be of benefit to any and all Amiga owners, > FACC will be of greatest service to owners of Amigas with > more than 512K. Note: Unless it caches my HARD DISK drive it would be of little use to me... Does it buffer the hard disk drive? And if it doesn't, can I whip out a filezap and change the OpenDevice call to open my hard disk driver instead? And the guys at ASDG should note that the addbuffers for my hard disk come out of FAST ram not CHIP ram. :) (Nothing special here, just setup my mountlist for non-CHIP since the MicroForge uses the CPU to push the bits. And for those that have asked, my MOUNTable MF driver will be up shortly) Scott Turner -- L5 Computing, the home of Merlin, Arthur, Excalibur and the CRAM. GEnie: JST | UUCP: stride!l5comp!scotty | 12311 Maplewood Ave; Edmonds WA 98020 If Motorola had wanted us to use BPTR's they'd have built in shifts on A regs [ BCPL? Just say *NO*! ] (I don't smoke, send flames to /dev/null)
perry@well.UUCP (05/26/87)
In article <1912@cbmvax.cbmvax.cbm.UUCP>, daveh@cbmvax.cbm.UUCP (Dave Haynie) writes: > There was a thread about this going on in BIX awhile ago, at least I think > that's what this product refers to. Simply put, its a program that adds > intelligent track caching (i.e. at the device level) instead to DOS's block > caching. Also, the caching memory can be FAST memory; its not required to > be chip memory as are normal floppy buffers or DOS's block caches. From > what Perry said, you have the power to add or remove caches at any time. > With enough tracks cached, you get what essentially amounts to a RAMdisk > overlay of a floppy disk. > -- > Dave Haynie Commodore-Amiga Usenet: {ihnp4|caip|rutgers}!cbmvax!daveh Facc (available now at dealers near you or direct) is in fact an intelligently managed buffer pool. The pool exists and is shared by all drives in the same way that a Unix system's buffer pool is shared by all drives. That is, as one drive becomes more heavily used it will begin reusing buffers previously used by other drives. Facc presents a graphic display detailing exactly what's going on in the buf- fer pool so that you can tailor the size of the buffer pool to greatly opt- imize any particular recurring operation which you might have. The caching is by sector not by track. Writes are written through the cache. Disk removal causes automatic cache invalidation for that drive. One interesting but pleasant anomoly is that Facc searches 500 or so buffers faster than AmigaDOS searches 16 buffers allocated using addbuffers. This can be explained by the data structures used by both implementations. We suggest that NO addbuffers buffers should be employed whenusing Facc since they are a) redundant b) slower c) come from Chip ram. As Dave Haynie suggests, the really neat thing about Facc is that it gives you ram disk like performance from a very stable basis (a real floppy) and at the same time is more efficient (ram wise) than a ram disk for low memory applications. (ie: when you haven't got MANY megabytes of ram to throw at a ram disk - Facc is a better bet since it only caches what you are REALLY using unlike a ram disk which ``caches'' everything.) Perry S. Kivolowitz ASDG Incorporated (201) 563-0529
richard@pnet02.UUCP (05/28/87)
What happens when my machine guru's with Facc? Can I lose data ?
UUCP: {akgua!crash, hplabs!hp-sdd!crash}!gryphon!pnet02!richard
INET: richard@pnet02.CTS.COMperry@well.UUCP (Perry S. Kivolowitz) (05/29/87)
In article <558@gryphon.CTS.COM>, richard@pnet02.CTS.COM (Richard Sexton) writes: > What happens when my machine guru's with Facc? Can I lose data ? > Facc will not cause data to be lost during a guru anymore than running the Amiga without Facc. If you guru during no read or write operation to floppy then there is no difference with our without Facc. If you guru during a read from floppy then there is no difference with or without Facc (in fact, Facc might even prevent disk damage if the sector was being read from an internal buffer thus the heads would *not* be in motion when the guru occured). If the guru happened during a write operation, Facc is specifically designed to ensure that Floppy writes occur in the same manner that they would if Facc was not present. In summation, Facc will not alter the survivability of data in any way.
scotty@l5comp.UUCP (Scott Turner) (06/04/87)
In article <3173@well.UUCP> perry@well.UUCP (Perry S. Kivolowitz) writes: >In article <558@gryphon.CTS.COM>, richard@pnet02.CTS.COM (Richard Sexton) writes: >> What happens when my machine guru's with Facc? Can I lose data ? >> > [ long article which may or may not have cleared it up for the original > poster ] As originally stated Facc uses a 'write thru' cache. What this means is that when writes to the disk occur the data is written to the disk without hanging around in Facc for awhile. The intent of this is to get the data onto the drive as quickly as possible to avoid the problem brought up about Mr. Guru coming by for a visit at the wrong time. However, there are some fine points about this kind of caching that Perry did not address in his posting. 1. Some 'write thru' caches will copy the data to the cache before the data is written to disk. This leaves a small window in which data can be lost. Perry states that Facc doesn't change the order in which things get written. This probably means Facc doesn't fall into this type of cache. 2. You CAN have a write thru cache that doesn't copy into the cache on writes. But these kinds of caches must invalidate any cached data for the block that was just written. And must re-read the block just written into the cache. This is bad because I've noticed that amigadog writes file extension blocks and then turns right around and re-reads them. 3. A write thru cache can write the data and THEN copy it into the cache. But most often when the phrase 'write thru cache' is used # 2 above is the scheme. Perry also writes: >then there is no difference with our without Facc. If you guru during a read >from floppy then there is no difference with or without Facc (in fact, Facc >might even prevent disk damage if the sector was being read from an internal >buffer thus the heads would *not* be in motion when the guru occured). If I fail to see what advantage there is to the heads not being in motion when a guru occurs. This smells of the misleading data that others wish to suppress around here. It should also be pointed out that the "System Request Task Held" requester is NOT the end of the road in many cases. Multi-tasking is usually still active so that non-write thru caches, like the one used by trackdisk.device, can get a chance to write out to the disk before Mr. Guru pops up and shuts down the box. In fact you can often use popcli to get a CLI to use to copy files off RAM: before clicking continue to go see the guru. Such files should be inspected carefully for damage though once the system is back up. Loose pointers get program's guru'd and files in RAM: damaged. And for those that REALLY want something to worry over, ;) a loose pointer can also wack a cache just before it gets written to disk... Which makes the grace period given by the "Task Held" requester somewhat suspect, but I'm a bettin' man. I'd rather risk the odds that a loose pointer didn't get my trackdisk.device (or xxxdisk.device) cache than risk that there IS something undamaged in a cache that should be written out. But if the memory in your Amiga goes "soft", like the ram in my Amiga is doing, the odds of a cache going bad DO go up. I've had various files on my floppy and hard disks go bad recently that I've only READ not written. For example I had a header file from C-A that had the misfortune of being on the same track as a file I had been writing to convert to gibberish part way through the file. Since the Amiga doesn't have parity checked main memory it's important to take evidence that the main memory in your Amiga is getting soft SERIOUSLY. The floppy you save could be your one and only copy of something. :) Scott Turner -- L5 Computing, the home of Merlin, Arthur, Excalibur and the CRAM. GEnie: JST | UUCP: stride!l5comp!scotty | 12311 Maplewood Ave; Edmonds WA 98020 If Motorola had wanted us to use BPTR's they'd have built in shifts on A regs [ BCPL? Just say *NO*! ] (I don't smoke, send flames to /dev/null)
perry@well.UUCP (Perry S. Kivolowitz) (06/06/87)
Scott, The order of events on writing with Facc is: 1) search cache - toss out buffer if block to be written is found. (very fast - just a few instructions). 2) write block to disk. 3) load block into cache. That should clear things up concerning writes with Facc. As mentioned before - the upgrade policy of Facc is going to be ``eternal'' and free. Send in original disk with a stamped self addressed envelope and get an update back promptly. FaccII is already well under way. Was it Steve or Tomas who suggested: 1) Enable/Disable retention on writes (step 3 above). 2) Multi-speed ``more'' and ``fewer.'' 3) Direct dialing of number of buffers (integer gadget). These three features are already in - as well as one I'd like to announce now: If you have an application under development which would benefit from Facc like services - please contact me. FaccII has an easily used message interface allowing *your* application to directly controll FacII's oper- ations. We'll make FaccII available for redistribution as a value added part of your application. Please email me any thoughts on new features for FaccII - these will be cited in the FaccII manual of course. Cheers, Perry S. Kivolowitz (201) 563-0529