On 1/6/02 at 7:32 AM Thierry Godefroy wrote: [PCI on the QL]
>> the problems are QDOS specific... >> ...Not many people around who have the thorough knowledge about the >> hardware and software to write more complicated drivers. >True, but knowledge can be acquired by anyone, the problem being the time >needed to do so... Note that most of the knowledge to acquire is NOT >QDOS/SMS specific, whatever driver you are going to implement on whatever >plateform, you need to learn about protocols, standards, etc... >As an example, for the ATAPI thing and the CDROM device driver, most of >the development time was spent searching, printing, reading and under- >standing the ATA, ATAPI and ISO specs (nothing less than 10Mb of PDF >files...). The actual implementation of ATA/ATAPI took about 40% of the >total time... Thierry made several good points. Of course, many will not find them as valid if they come from a standpoint of modifying an existing driver (and recompiling it for a speciffic platform) rather than building one from scratch. The way things are done under SMSQDOS (assuming you have divined this 'from the source' :-) ) actually makes attempts at converting existing drivers (unless they already come from SMSQDOS) quite unproductive. Unfortunately, faced with extra time to either figure out an existing driver (and possibly end up figuring the work was in vain) or reverse engineer part of SMSQDOS code, the programmer may decide it's too much time for too little effect. >> filesystem is hardwired into device driver. This actually is not great problem in itself - it's the lack of standardized ways to interface with existing code (which may or may not be a part of a driver) that's the real problem. As things now stand, new file defice = yet another copy of the file system code. All the more ironic considering that there are means to construct drivers differently, as Thierry says. What I really like about Thierry's approach here with his CD driver, is making good decisions and implementing it, rather than having the endless _ or \ discussion influence it :-) >The problem is rather the lack of professional programmers that could >actually work full time on QDOS/SMS... TT is not the only man that >can write device drivers or OS extensions for QDOS/SMS, there are still >talented programmers around, but none of them are able to spent signifi- >cative time (i.e. a few months - full time) on QDOS/SMS software >development... >Now, with some good motivation, most of these programmers will be ready >to "sacrify" significant part of their free time to do some software >development. The equation is very different if a huge potrion of that time, or even MORE than that time is needed to first reverse-engineer code. Doing that is far more time consuming than actually writing working code. In light of the comments regarding access to SMSQ/E source code, it begs the question: what would it take to BUY the source code from Tony Tebby? Or, some kind of licencing agreement that would effectively have the code in the open but with someone as the 'code cuistodian' - i.e. it would not be freely distributable, rather under something liek a GPL. > New hardware (INCLUDING UNSUPPORTED ONE under QDOS/SMS) is a very good > motivation as far as I am concerned... IF a new 680x0 board with PCI > bus is built, then I could well find enough motivation to write a bus > initializer for it... Which, of course would be the first 1% of the job since something has to be plugged into it, and that's when all the fun begins :-) >The old debate "should software be designed before hardware ?" is a >nonsense to me: IF there is hardware I can test software on, THEN I >can write software for it. Actually, it's a kind of chicken and egg argument. For some hardware to actually start doing ANYTHING usefull it has to be initialized. In many cases all of this has to be done first, before QMSQDOS loading isn't really even in the long term plans (speaking in terms of CPU time, of course), and developing such software is VERY difficult because much of it has to be done 'blindly' - you write the code, program it into an EPROM or some equivalent, or download to the hardware by another method, and hope it works. If it does not, figuring out what is wrong can be a matter of using some quite fancy and expensive tools and instruments. This seriously impacts the job of a hardware designer - one would be foolish to implement the hardware in such a way that requires extensive mods to the OS and add-on driver code, knowing that the OS and driver sources are not available - even if such implementation would ultimately be the better one. Also, assuming such the initialization code was done and working, it has to have a means to load the actual OS from wherever it's stored - frequently from devices included in the initialization sequence. Unfortunately, the way it's built now, this is a part of the OS, and this means there is no easy way to modify it unless you have the source. There is a ton of other problems such as non-modular drivers (or, at least not documented to be modular), which is a serious problem for SBCs because they don't necessairly implement all the standard peripherals, etc, and THEN we get to the general need to overhaul some aspects of driver construction, some OS data structures handling, etc. Nasta
