On 15 Oct 2003 at 3:05, Phoebus R. Dokos (è á . ç ) wrote: > I do not think that the Qx0 and QPC are directly competing with each but > they do indirectly. > To explain: Basing an OS around an emulator, tempts users to totally > abandon hardware for software only.
Oh boy, do I disagree with you. Allow me to take my own example. I just have to use a PC at the office. A good word processor, spreadsheet, PRINTER, Internet access etc are just things I need. So are other, homewritten, programs. Now, the word processor runs on the PC. So I need a PC. There just is no way around it. Am I going to put 2 computers in my office? Have twice the noise? Use twice as much electricity? etc.... No way. I could justify that at home (it's a hobby) but not at the office, where I receive people. OK, so a PC it is. Now, I also need some homemade programs. If I can't have them under some kind of SMSQ emulator, I'll need them on the PC. So I start PC programming - what do you think will then gradually happen? Sooner or later all of my programming will be done on the PC, because, the homemgrown programs are also done at home. Exit SMSQDOS.... So, for me, QPC is a very real reason TO CONTINUE TO STAY WITH THE QL WORLD! (...) > However (and that is the user's preference not Marcel's doing of course) > when the emulator becomes the only place where the software is run, then > first the hardware becomes totally obsolete and then the emulator itself. OK, I can agree ith that -it was one of the reasons I did buy a Q60. > If the trend for emulation-based only QL work continues, then we might as > well totally abandon QPC/QemuLator/uQLx etc and rewrite QDOSMSQ (to use > Thierry's term ;-) in a higher level language and use it natively on PCs, > MACs and what have you. Don't tempt the devil... > The purpose of existence of any QL derivative OS is to run on hardware > after all and to take advantage of that hardware. If that doesn't happen > what is the point of still using the OS? Oh well, of we go into this debate again - QPC does run on hardware and can take advantage of it - I can read CDs, I can use USB printers etc... > It is (and according to my belief illustrated above) therefore imperative > that the users choose to invest in hardware instead on only software (in > the best situation both) if there is any point in all of this. Yes, and despite the above I still agree. But for me, conceptually, there is not that much difference between an QPC machine and a Q60 machine. (...) > I don't think that the Q60 was ever sold as a Linux machine (although it > runs it very capably) but with the *ability to run* Linux. (Similar to > saying PC with the ability to run QL software via QXL or QPC!.. It's not > primarily therefore a QL ;-) No, but what can you use it for if not to run SMSQ/E (ok, Qdos classic, but I want MORE than a QL from a modern machine). > > Apart from that I fail to see how the Q60 is being developed actively? > Software development and hardware development are distinct processes. The > Q60 is completed and working fine. Peter designed and implemented the > hardware and we're asking him to make the software for it too? (Don't get > this in the wrong way I am just asking a legitimate question). Nobody asks > Marcel or you to design hardware to fit the software right? Just as we > never asked Miracle to write SMSQ. TT did that! > The fact that Peter has the ability to contribute software is unrelated to > the fact that he designed the hardware. Again, I disagree in practice. If the hardware is there but no software to take care of it, what use the hardware? > Now, if you mean by developing to create new hardware solutions more > extended than the current Q60 offering that's a different process that > involves a substantial and immediate investment. Even to make my new ED > drives it took me several hundreds of dollars and that's an easy task... Sorry, I don't understand the reference to "making" ED drives. But let's use this as an example. If you want ED drives, you have to upgrade the OS for it. And who could help there better then Peter Graf? > imagine tackling a whole machine in say a ColdFire implementation with PCI > bus... can it be done? Sure... will it be done? Probably not, and one of > the reasons was explained by Peter... he doesn't feel that the current > license of SMSQ/E can help a potential design. Noted. I disagree, of course. (...) > I think that the issue is a lot more complicated than that. Unfortunately, > in order for the Q60 hardware to be fully utilised, a lot of processor and > hardware specific code has to be written. Unfortunately the current > situation of the license permits that only for one's own leisure. Wrong. See my other message re the open software question. > The > license is what it is and has to be respected regardless of one's personal > opinions. A solution to that would be extensive patches on the code and > the list has seen a tremendous disagreement over that in the past. As for > the sound system what do you mean? If you mean sound generation by tapping > into the DACs directly it has already been done (and a future version of > QWord will include that code which I am now perfecting thanks to the > always valuable assistance by Simon Goodwin) but we should not forget that > many of the hardware capabilities are severely restrained by the software. So you do agree that hardware and software are interdependant. On this specific question - wouldn't it be better if the OS itself had these sound facilities built-in. Even better, if some kind of common sound generation code or at least interface could be made for QPC, Qx0 and the Atari (which also has capable sound hardware). Yes I know, I'm dreaming here. Sorry. (...) >Why shouldn't the Q60 be able to use the MMU or FPU natively and > HAS to rely on the "compatible" code if it is to stay "official". Sure you > can patch it later on, but then the whole premise of the registrar and > "compatible" code goes out the window anyway. Sorry, this argument is based on a flawed premise - see my other email. > As for Marcel's involvement in Q60 development, I don't think that anyone > expects him to do it... we are very grateful for what he has done so far > and if he would stop right now any development he would have still made > more than enough contributions... Agreed. > As for Thierry's CD driver it still is severely hindered by the structure > of the IOSS which needs a VERY serious overhaul. CD ROMS being inherently > slow devices lock the machine completely. Thierry's work is great but > without substantial improvement on the way I/O is handled by SMSQ/E and > QDOS it is good only as a once-in-a-while access for massive files that > need only scarce access. The funny part is that by allowing 040+ commands > in the code you could save a lot of time in many I/O operations and you > would at times double the effective speed on many operations on Qx0s. But > this is not allowed is it? Yes it is. Actually, your example is a damn good one. I agree that another IOSS would be VERY nice. MUCH of that code could be common to all machines and I think that my insisting that it be done in a way that would, then, benfit all machines is only very reasonable. Of course, there could AND WOULD be code specific to the Qx0, QPC, Goldcard, the Atari and do on. Would I disagree with that? Not in the slightest. As an example: Fabrizio Diversi made Qx0 specific versions of some code that used the MoveP instructions. These MOVEP instructions are beneficial for the GoldCard versions and were present in all of the others. It was common code but did hamper the Qx0. Fabrizio kindly undertook the work to get rid of that and made new source code (based on the old ones, of course) and gave them to me. Thus, today, these parts have been taken out of the common code tree and made into a Qx0 specific version. I never once "protested" against it. Why should I? However, then you can't complain if the same thing would be done for QPC with "native" code, or, for GoldCard with Movep instructions of what have you. I do reserve the right to make suggestions every time to make code more common to all machines. > Everyone would. One lost developer is one too many :-) Agreed Wolfgang
