On Mon, 15 Apr 2002 at 03:19:06, ZN wrote:
(ref: <[EMAIL PROTECTED]>)
>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.
Indeed. RomDisq has to go through hoops to get the data in as the port
only has 16k addressing and 8bit data.
Writing is always going to be slower as the flash chip write is slower,
and also the write operation on the ROM port is more complex.
TT though gives this only 50% priority so QL can carry on, slowly.
Was there a technical reason why flp writes (and reads?) excluded any
other task?
> <snip>
>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.
We did think of a cable - much like the essential one on sH, but that
would have made portability difficult.
> <snip>
>>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!
... and TT would not want to be involved at all. I will ask him to make
RD driver open source.
--
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
