On 1/6/02 at 7:12 PM Thierry Godefroy wrote: >The only thing I regret about most "QL" (in the largest meaning of the >QL term) hardware is that there is generally no consultation between the >hardware designer and the software writers... for Aurora (there, it >looks like someone took for granted that once Aurora would be available, >TT would write the screen drivers for free, the result is: no enhanced >screen driver for Aurora!)
Actually, TT was probably the very first person to receive the Aurora specs, while it was still a prototype, and a long way from production. Result: NOTHING. Not even an answer. For all I know, there was a shredder linked to the output of his fax machine, since that was the only way he communicated (if that could be called communication) at the time. Maybe I should ave promised money? Not that I am faulting TT, because I _DO_ understand his posittion. OTOH, I never really dealt with the people who wrote the software myself, rather that was done by Ron Dunnett. Originally, I really wanted to make the specs completely public, but since I did get signals about more colors (for the QXL, though) from different sources, I decided to give the specs to only a few people, until I made them freely available on my (ex) web site. Guess what: NOTHING, for years. IMHO before the community was largely web connected, waiting for a response before the hardware was built, would mean the hardware never would have gotten built in the first place. The situation is a little bit different now, not as much as you would think: > Note that this is not always the case (Nasta did publish the GoldFire > specs and asked for advices)... And got VERY little. I am sure once the GoldFire becomes available, I will hear no end to complaints about decisions made in it's design. However, at this point, as detailed as the descriptions are (and they need to be to make it possible to write software for it or decide about any aspect that should be changed), they seem to be too detailed to have many people bother actually reading them. This is highly disconcerting considering there are aspects of GF that are 'new' to SMSQDOS. For instance, people will complain about disk operations stopping everything, but when a solution is offered to this problem, which involves hardware (and unfortunately, this is the only way to address it), and associated changes to the drivers (or better yet OS because the feature introduced is generally usefull), the feedback equals more or less zero (with notable exceptions). I certainly hope this is not the way open hardware developement on the QL is going to work. >What I would really love to see are open specs of hardware before it is >actually prototyped, so that software writers have a chance to spot >the potential programming difficulties/limitations and warn the designer >about them before it is too late... Well, there's the GF stuff - feel free to open fire. >> Furthermore I doubt that PCI would really be a good motivation for >> possible software writers. Most of the things that we lack and eagerly >> wish, can already be implemented in a more simple way than PCI. There >> is not much use in wasting enormous software-writing resources, just >> so we can say "hey look how modern we are, we have PCI". If there are >> easier ways, why chose the almost impossible ones? ...and further more software writing resources we don't have. >Soon the motivation will result from the choice: PCI support or no more >cheap add-ons for the "QL" plateforms... >But you are right, many things are still to be implemented, even in the >current Q40/Q60 design. ;-) This begs the question: WHAT PCI expansion devices do you want to see on a QL platform? I would be willing to bet they could easily be numbered on the fingers of one hand... and that most of these already exist, just in QL speciffic form. I am not opposed to PCI on a QL hardware platform as a bus, rather as a bunch of connectors into which the user can plug in any old PCI card and then expect it to magically work - this is like opening a can of worms. People will then expect that they can go and get their $12 10/100 Ethernet card, plug it into the PCI slot and then have it work. Regardless the fact that any data about the chip on it may not be obtainable. If lucky, it may be possible to find a Linux driver. And if so, we may get lucky to have it in source. 'All' that would then remain is to reverse-engineer the source and then using that data write a SMSQDOS driver. And remember, I have actually selected an easy example - it is most likely that whatever chip is used is similar to many others and it could be programmed using a common subset of features. Then, when all that is done, you can't get the card any more. The situation would be somewhat different if one decided to use a certain chip that just happens to be PCI based on a new QL 'motherboard'. In this case, although you are still subject to chip availability, at least you only go through the above 'design process' only once - and of course, starting off with a ship that you CAN get data for. Nasta
