On Mon, 15 Apr 2002 at 00:22:23, ZN wrote:
(ref: <[EMAIL PROTECTED]>)
>On 14/04/02 at 16:38 Phoebus Dokos wrote:
>
>>Speed comparable to the RomDisq will only be attained by using the
>>superIDE interface WITH a GoldFire card. It is totally impossible for
>>a standard Qubide equipped SuperGoldCard QL to reach these speeds PERIOD!
>
>I hate to spoil the fun, but NO.
>The reason RomDisq is so quick is because it needs no interaction and
>handshake with the Flash array in order to read the data, and it's file
>system is drastically simpler than a hard drive (the 'map' is smaller).
>Once the appropriate page is selected, it's right there, mapped to 2k of
>addresses, all there has to be done is copy it to where it's supposed to
>go.
RD has 64k pages. I am not 100% sure of the precise read method, but
certainly A0 is used serially to get the high address, and of course
data is read a byte wide.
>In theory, Qubide can be almost as fast as ROMdisq (try doing
>Lbytes/Sbytes), except it will always be faster for writing.
It will interesting to see Phoebus' figures. Yes - LBYTES is the
fastest way, rather than COPY. I think that is what I used for my
original speed test.
That raises another point. I was trying to use Simon Goodwin's program
at Manchester AGM to output sound to the I2C analogue I/F.
He used a Turbo command (PEEK$ was it?) to assign a block of memory to a
string. Am I right that there is no TT toolkit equivalent?
BGET is so SSLLOOOWWW, even compiled.
>
>Let me explain why, and tackle a few more points while at it:
>
>In order to read a sector from an IDE drive, you have to tell the drive
>which one, then (unlike RomDisq) there is a delay until the heads are
>positionad, the disk rotates to the right point, and data is read and
>checked. After that it appears in a buffer. Once it does, it can be read
>from there just as fast as it can be read from RomDisq (and yes, faster
>with the GF - but even RomDisq would get a boos there),
'boost' I hope (8-)#
>assuming the rest
>of the computer KNOWS the data is ready. Readyness is implied on the next
>access on RD, and takes place in a matter of nanoseconds. FOr a hard drive,
>it's potentially 3-4 orders of magnitude longer. Fortunately, the drive
>itself (usually) isn't designed by morons so it has tricks up it's sleeve -
>it will as a matter of course read the whole track - as long as the head
>stays over it, it's reading data anyway, so might as well store it, in the
>event it will be needed. As it happens, in a large percentage of cases it
>is, as it's very likely the next consecutive sector will be read soon.
><snip>
>GF could easily give a speedup to both RD and any type of IDE, with Qubide,
>you risk running into signal integrity problems quite soon, because unlike
>SuperIDE it's not designed with 'countermeasures' included. I don't know
>exatly how fast RD could go, it depends on the speed grade of the chips
>used, but I am quite certain it could be at least twice as fast.
I use the 90ns chip - second fastest flavour.
>Writing
>woudl however remain the same as the write process inside the flash chips
>is the real bottleneck.
Yep.
--
QBBS (QL fido BBS 2:252/67) +44(0)1442-828255
tony@<surname>,demon.co.uk http://www.firshman.demon.co.uk
Voice: +44(0)1442-828254 Fax: +44(0)1442-828255
TF Services, 29 Longfield Road, TRING, Herts, HP23 4DG
