On 15/04/02 at 05:40 Dexter wrote: >> Unless you two know something I don't (like how to locally change the >> Planck constant, speed of light, gravitational constant...) that's as >> fast as anything will currently go on native QL hardware, give or take >> a few 10s ok K/s...
>What?!?!? >You don't know how to change the speed of light? >I'm disappointed in you, Nasta! Sadly, I'm not Q. If I were, I'd wave-my-hand-ed myself to greener pastures already. (and let's not even start about what I'd do to Micro$oft) >Seriously though, my point was that it isn't necessary to hook up a CF >card to an IDE interface to use it - there are ways to hook it up directly >to the buss. Through the ROM slot it would not be that different than it already is. > That way, you can do direct reads and writes without having to wait and > poll to check it's finished the previous operation. That would be quicker. OK, there is ambiguity here. There is no reason why Qubide should necessairly use polling (in the sense it uses interrupts), the reason it does what it does the way it does is because that was the only driver available at the time. Now that SMSQ/E source may become available, we might be able to convert the win driver already done by TT for Miracle, and expanded for QXL, QPC, Q40/60 to work on Qubide. Even the RomDisq driver could be converted to handle a CF hanging off an IDE interface, but it would have to be VERY considerably altered. Polling as a concept is unavoidable for anything on the ROM slot, and there is a reason why RomDisq is a ROM slot device, so that it can be easily removed and plugged in elsewhere. Reason: no interrupt line on ROM slot. This is also proof that CF on Qubide could work just as fast (strictly speaking, slower due to larger overhead of a task file, but this would be imperceptible). Setting up the task file and doing it's little protocol is only writing and reading a couple of bytes, nothing compared to transferring 8k or so of data after that. Remember, next to no 'access time' on CF media. No interrupt on Qubide, but no interrupt on RD either. A wait on write is also unavoidable for any type of Flash media due to characteristics of the media itself. Reading from the Flash takes nanoseconds, writing may extend to the order of a few milliseconds. >Either way, the point that a version two of RomDisq could be based around >CF instead of traditional flash, for price and size considerations, still >stands ;) True. If you read the specs though, you will notice that the different CF modes really are not THAT different. Even in the 'memory' mode it's not just 'flat' memory, but bank-switch, and the polling on write becomes more explicit, similar to actual flash chips. The good thing about CF, even in IDE mode, is that it MUST implement byte-wide data bus (unlike hard drives which do not, and they VERY rarely do), although it's natively a 16-bit wide device. Interfacing it to the QL bus on it's own would be nearly trivial, as long as it's directly coupled to it (and that means NO cable to the front of a box like in the case of Qubide!!!). A RomDisq II (maybe 'superRomDisq') would be very similar to what it is now, except without the actual Flash chips of course, but with CF socket instead. Things would get a bit (but only a bit) more interesting if the CF card was hot-swap, the biggest challenge for that would actually be mechanical stability. Another challenge would be having the data organization such that data could be read on other CF capable systems! Nasta
