On 1/10/02 at 9:19 PM Peter Graf wrote: >Hi Nasta, > >>Two more plus a CF socket adds hot-swappable CF card capability... >>...PC87C307, an AD1816, a 91C96 (or possibly 91C111?). That more or less >>covers all the necessary ISA components.
>Would it be worth considering to make a Q40/Q60 extension card with the IO >components you have in mind for XY-Fire (plus one or two goodies)? >The card wouldn't have much size constrainst, and almost no high-frequency >challenges, so placement and routing shouldn't be too tricky. The card >could be a "playground" to get familiar with the chips and write the >software. Certainly it is worth considering - if you look back at some older messages, you will find I already suggested something like it. It really depends on the user interest, but I think it would be a good project that could ultimately benefit all platforms, though at first, of course, the Q40 and GF (or should I now say XY-F :-) ). I myself would prefer to be the consulting party on such a design, offering the existing implementation on the GF and anything I already designed as a start - and then hoping to share experiences as the project goes along, while concentrationg on GF. As for the design and logistics... If the parts were procured with both Q40/60 IO card and GF in mind, it would make both cheaper as the quantities would be higher. While some functions would not appear on the GF (such as IDE), they could be fully implemented on the IO card. Driver-wise, with some atention to detail, most of the hardware on this new IO card that duplicates the hardware on a regular IO card would instantly be usable by existing Q40/60 drivers. On the GF the addresses of some registers would have to change, as well as the interrupt handling for some devices. The ethernet would most probably be usable 'almost instantly' under Q40/60 Linux, after register addresses are modified. Possibly even extended sound could run 'almost instantly' under Linux if tehre are Linux drivers for an AD1815/1816 chip, and it would not be a great problem to implement under QMSQ/E for Q40/60, even with no changes to interrupt structure - and it would be compatible to SSSS because the audio chip can be configured to use the required sample rate and word width. Extras such as an integrated CF card slot would be VERY easy. Two IDE channels also very easy (not so easy to find on ISA...). MIDI is already supported by the sound chip (although on the GF external line drivers/receivers are needed) and there are even extras such as I2S (should anyone want SPDIF digital IO) and a DSP port. The PC87307 also has IRDA. The card could be designed to use Q40/60 ISA environment (i.e. no DMA) which is exacttly the way GF uses the chips too. All in all, there are 3 problems: 1) Someone to implement it (design is largely done already - just copy/modify the GF circuits) 2) Cost justification - presumeably from the extras on it 3) Where to put all the connectors for the multitude of features :-) >> Any chance to get USB (for digital still camera for instance, as even >> fast RS232 is very slow) ? > Our QDOS/SMSQ software development shortage practically prohibits to > work on USB host hardware. And even the hardware is a bit difficult > because of the lack of suitable USB *host* chips. Completely agreed there. Although, it would actually be easyer making the Q40/60 an USB _peripheral_ to something else, the question being if that's of any use. Certainly it would be on a SBC, to upload/download programs. Also, the phrase 'suitable USB host chips' is really telling it better than it is. The only way to get real USB would be to introduce a PCI bridge, then hang one of the rapidly becoming obsolete USB adapter chips on it. That would make USB a (huge problem)^2 - requiring the solution of PCI _and_ USB support. Very unlikely. Oh yes - MOT, in their infinite 'wisdom' have ONE ColdFire chip with integrated USB host - and it's the least compatible (read: useless) kind :-( When I looked at TT's ATAB, if that ColdFire were 68k compatible, it would have been the IDEAL chip for the job :-(((( > I already have a *fast* hardware solution for digital cameras and > Q40/Q60 (Much faster than USB!) Which is a CompactFlash adaptor. Agreed - every camera I have seen (and even some very high-end ones) use 1.2M USB and with CCD sizes going into the 4M territory, and CF card sizes increasing with prices falling, it takes forever to transfer the pictures. OTOH reading directly from a CF is (almost) as fast as an IDE hard drive. >> Yes, except for the interrupt system which is very different. Depending >> on the required speed of the peripheral they are mapped to three interrupt >> levels. The highest levels also have the shortest service routines, and >> service hardware that has FIFO buffering built-in. > I also thought about it, but went back to the QL way of one level for all, > except sound. Mainly because I wasn't sure about the need for software > changes. Actually, the changes themselves are not that extensive, surprisingly. Of course, the required locations for the autovectors for the new interrupt levels have to point to the right places. There would be two ways to do this: 1) Quick and dirty - the drivers that use the extra level would have their own 'private' code to handle FIFO filling and emptying and the new interrupts would not be visible on the system level otherwise. In effect this would mean that the new levels would be 'hard-wired' into the drivers that require them. 2) The 'proper' way: there would be a thing to handle linked lists to which any driver that wants to use a new interrupt links into, in effect this would implement additional lists more or less duplicting existing interrupt list behaviour for new interrupts. It would then also be a new system resource, thus avoinding the need to introduce new Trap calls. Incidentally, the GF also introduces a high frequency periodic interrupt just like the Q40 does, but it's not as fast as on the Q40. It's also intended primairly for sound, but it can be lower frequency because the sound chip has a rather large FIFO both for sound output or input (64 bytes). It can also be used for other things. In theory, it could be made to work almost exactly the same way it does on the Q40/60. In principle, I have nothing against high frequency periodic (polling) interrupts but they sometimes use up more time than one would think - because they poll hardware which is VERY slow compared to memory - so it's a good idea to keep the frequency the lowest one that still does the job. The real question is what that lowest frequency is. At this point I have not researched in great depth, but the hardware which generates the interrupt is programmable and the frequency can be chosen from a wide range. Nasta
