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. In theory, Qubide can be almost as fast as ROMdisq (try doing Lbytes/Sbytes), except it will always be faster for writing. 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), 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. Because of this, the slowdown on Qubide, once reading gets started, is for the largest part a matter of the driver. A fair percentage here is the calculation needed to handle the drive map and the slave blocks, but a lot of the blame lies with reasons of (in)compatibility. The original Qubide driver was made for the Rebel MFM interface which was interrupt driven - when the drive would finish a sector read/write operation, it would generate an interrupt. Qubide is not interrupt driven, so the 'is the operation complete' check has to be done explicitly, by checking a bit in a register, rather than have an interrupt signal that it is. On Qubide the check is a part of the scheduler loop. This makes the maximum speed at which sectors get transferred for file IO be the scheduler loop frequency, which is quite considerably slower than what it could theorethically be when only the limitations of the drive and interface are taken into account. This is the real bottleneck. The basic hardware cycle to communicate bytes of data from memory to buffer or back is exactly the same, and runs at the same speed for both RD and Qubide - it's the overhead that makes the difference. For operations that transfer to/from a block of RAM, such as S*basic SBYTES/LBYTES this mechanism is largely circumvented, because the drive is made to transfer consecutive sectors in a loop as long as there are more to transfer. In these circumstances the speed closely approaches RomDisq, save for the overhead in the handshake protocol between hard drive and QL (once for every [block_size] sectors, and initial head positioning. I have found a way to put interrupts back on the SuperIDE (it simply didn't 'fit' on Qubide, would have required a heavily underused chip just to implement that one line, and every 1/100 monetary unit of preference counts!) but of course, it will need to be supported in software to take advantage of. Writing is faster on CF than on RomDisq even with slow CF, simply because the CF buffers data and writes internally several bytes at a time (to do this it is accessing multiple chips at a time, plus there is extra buffering), whereas RD writes one byte at a time. There is a big difference in the actual mechanism used. RD has data write emulation by putting data on address lines, because you can only read from a normal QL ROM slot. This is slower than the 'usual' way of writing, but the overhead is tiny compared to the actual time to write a byte into the Flash, which is a VEEEEERYYYYY SLOOOOOOWWW PROOOOCESSSSS. 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. Writing woudl however remain the same as the write process inside the flash chips is the real bottleneck. > The only other possibility to reach comparable speeds would be a QubIDE > with a fairly large amount of cache memory on board. No, this would not make a difference, driver notwithstanding, again because once handshake and driver overhead is taken out of the equation, the maximum speed of the bus, that being about 1.8MB/sec becomes the bottleneck. This 'magic number' is the same for every peripheral that is fed off the actual bus signals appearing on the expansion connector. It's a 'historical' thing, to do with the 8301 video ULA not being able to reliably access the original 128k of RAM on the QL motherboard any faster. The GC and SGC literally have to 'put the brakes on' when talking to the QL bus just in case a 8301 may be hokked to it somewhere. >The overall "feel" of any decent speed compact flash card is that it is a >lot faster than the hard drive (mainly because of the almost minimal seek >time). Yes, this is true - seek time is for all intents and purposes non-existent on CF reads, and very small for writes (but then the ability of the CF to buffer and perform clever tricks to avoid the long flash write process takes over as the determining factor for speed). >Since the CF adaptors are my "babies" I have to tell the truth about >them... They're fast and furious ;-) but not faster than a RomDisq. >Time to boot using a 2 Mb RomDisq (From the F1/F2 prompt till windows set >up and everything): 12.8 sec. (Cache_off and SCR2EN) >Same thing with a 26x PQI Flash card : 18.3 sec >With a WDC36400 (2 Mb Cache on board): 22.6 sec > >I think that this says it all... I think you can freely do Cache_on on a SGC because it's a small and simple code only cache which has far less problems (but also less speed impact), and leave it at that. Try if this makes it faster: load all your LRESPR extensions as one file (concatenate all the binaries and remember the offsets of the files, then LBYTES to address X and CALL X, CALL X+offset 1, CALL X+offest 2... Nasta
