On 10/12/04 at 10:46 Phoebus Dokos wrote: [Qubide driver changes]
>> Possibly, the initialization sequence could be simplified. All of this >> assumes that the Qubide source (latest version) is available, and AFAIK, >> it is >Yes it is :-) >The latest QubIDE v.2.02 is already incorporated in QDOS Classic btw :-) Great, so we do have someone who knows how to poke around the source. In essence, the only truly important thing to do is change the IO addresses to a fixed value for GC/SGC systems. It uses a small area in the QL's IO block, which to the best of my knowledge doesn't interfere with anything. Also, the initial copying of the ROM to RAM is handled slightly differently, there is more space available and once the ROM is copied from it's initial address that switches off the ROM slot, it restores the ROM slot and whatever is in it should then be initialized as usual (the procedure is outlined in both the extended UM and the technical guide). >> The major part is more radical. It is high time that hard drive >> partitions and formats be unified on QL platforms... >> does not directly conform to the norm. It should be possible (indeed, it >> should not be much work) to convert the SMSQ/E win drivers for Qx0 to run >> on Qubide hardware. The problem here is the lack of utilities. >Absolutely true... and when the QubIDE software is run on a Q40 or Q60 >thanks to the wonderful work of Derek Stewart, many of the problems >experienced with the regular QubIDE software (ie Not a QubIDE partition >message appearing out of nowhere) are now gone. Same would be true for the new Qubide. Signal integrity is well taken care of. >However in all truth, there is a GREAT SMSQ/e partition tools only it >doesn't run under SMSQ/e... it runs under Linux (atari-fdisk) and it's >worth to boot a ram-based linux only for atari-fdisk :-) Actually, if the driver was extended to support direct sector access (ah, shades of metadevices again!), porting that or even using modified Qubide tools would be possible. It strikes me as quite strange that no-one has done this yet for the Qx0... >> Still more radical, it should be possible to >> support both types of partitions as well, but that requires a lot of work >> on the driver(s). >I am not sure if it feasible without major changes in the QubIDE software Not necessairly - internally, QubIDE partitions are stand alone just like Atari style ones - they could fairly easily be made conformant with the FAT16 style partition table, there are very few places in the Qubide driver where this is accessed (notably win_use, either explicit or implicit at initialization time). From there on, two drivers could exist, win and something else (qub?), with win_use and qub_use commands. The usual win_use parameters would apply to both, but each driver would only link in a partition if it was the required type (QLWA or QLW0 respectively). Even so, we really need to unify the format at some point... [Ethernet] >> The hardware here is almost trivial, but the software isn't, unless one >> limits oneself to a modified NET driver that can run on Ethernet >> hardware. >For that it is most likely that Peter's work on QlwIP will be almost >trivial to adapt to a new EtherIDE (AFAIK Peter's hardware driver is for >the Realtek chipset which is IIRC what you were going to use too) Actually, I use the SMSC LAN91C96 which is similar but also different from the Realtek. The Realtek has turned out to be a dead end - they only have PCI versions now and they are not compatible with the ISA based one used on the Qx0. Also, this assumes that Peter would be willing to do the work, which I am not sure he would (and I hope I get to be proven wrong). SMSQ/E licencing issues are likely to rear their head again but this could be circumvented by supplying the module separately, though it should REALLY be a part of both OSs. >>> 3. SGC-type expansion... a plug in and go Miracle-style expansion, or a >>> much more radical path... >> Actually, it is likely that both will be made available. >When is the keyword here :-D I'm looking at 10 68SZ328 chips right in front of me at the moment, SDRAM and Flash are scheduled to arrive in a few weeks. PCB design is still to be started once a definitive spec is drawn... >> The video output can also be used as an interface to a TFT LCD, >Without an inverter or is it a DVI output? It's a raw digital output to connect directly to a TFT panel, and I do have a supplier for same plus inverters... in the USA... but I haven't as yet been able to find a nice small 640x480 color TFT with touch screen... As such, this digital output can be used to connect a DVI transmitter chip as well, so that option is also covered. >> GF design introduces dual processors (I have been going on about this for >> years now and lo and behold this is the next step the mainstream is >> taking, admittedly with dual core CPUs instead of dual CPUs... >> ...Lots of OS and driver work that should prove essential in the future... > Stop it you make us all salivate :-P Supporting this kind of multiprocessing would be worthwhile work even on an experimenter or university degree level. It has been done before but not for a 'universal' machine. Most if not all IO tasks including the rather hefty task of drawing the graphics or maintaining burried windows could be switched over to the second CPU, with system software running on one dealing with application scheduling, and the other with IO scheduling - the two use quite different strategies, which can sometimes be in the way of each other. >> In the case of the particular CF chip I had in mind, it is also possible to use >> a PCI bus. This can simplify interfacing to some desirable chips, but can immensely >> complicate initialization and drivers in some cases. >PCI bus software already exists in open source for Big Endian CPUs (one of >which is the ColdFire V2 series) and even for regular 68K CPUs (via way of >Amiga-Minix) If the PCi interconnect was restricted to on-board devices (i.e. of the 'known in advance' type), the software simplifies quite considerably it seems. The 'I need to plug in any-old-card' is where the problems begin ;-) N. _______________________________________________ QL-Users Mailing List http://www.q-v-d.demon.co.uk/smsqe.htm
