Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Path: utzoo!utgpu!water!watmath!clyde!rutgers!cbmvax!daveh From: daveh@cbmvax.UUCP Newsgroups: comp.sys.amiga Subject: Re: The LIVE Digitizer from A-Squared... Message-ID: <1979@cbmvax.cbmvax.cbm.UUCP> Date: Sun, 7-Jun-87 14:21:59 EDT Article-I.D.: cbmvax.1979 Posted: Sun Jun 7 14:21:59 1987 Date-Received: Sun, 7-Jun-87 23:43:58 EDT References: <279@l5comp.UUCP> Distribution: world Organization: Commodore Technology, West Chester, PA Lines: 26 in article <279@l5comp.UUCP>, scotty@l5comp.UUCP (Scott Turner) says: > The figures given by diskperfa for VD0: are VERY enlightening if you know how > to read them. VD0 was done as a device driver rather than as a HANDLER. Thus ^^^^^^^ > is has to go through ALL the same internal stuff that a hard disk driver has > to go through. VD0 by it's very nature has no latency delays etc to slow it > down. Thus it's timings reflect what amigadog is CAPABLE OF. ie we can't go ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > any faster than VD0 thru the device interface. Thus VD0 sets an upper limit, > like the speed of light, beyond which we can't go. Assuming that in your "amigadog" sentence above, you're actually claiming that VD0 reflects the maximum speed of the DOS, maybe you should re-read the first sentence. VD0 is probably very close to all that you can do with the generic FileSystem handler. It says practically nothing about what the DOS itself is capable of with a faster handler. A tightly coded version of RAM: would be a good guess at this. Something that can handle the specifics of the device could scream, in comparison. You could read/write more than 512 bytes at a time, use knowledge of track layout to take advantage of the natural track caching of the floppies or just to avoid disk seeking, etc. > Scott Turner -- 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