Re: [ql-users] QLiberator
On Wed, 11 Feb 2004 10:36:44 +0100, Claude Mourier 00 [EMAIL PROTECTED] wrote: Because it is far more easy to use then Turbo : you have can compile your code directly when you need to adapt it with Turbo (at least versions I know) That is not true. You do not need to adapt any code apart from what you would normally do with any compiler. You cannot use SAVE and LOAD etc but you cannot do that in QLiberator anyway. As for Turbo directives like IMPLICIT etc. these are optional. There's nothing that says that you HAVE to use them. And Qlib is the only one implemented as Thing in QD (you can parse and compile without line number) and used by tool like the Linker. (and I don't know if all features such as overlays etc is supported in Turbo). That's not really an advantage, compared to the speed, superior math libraries and availability of Turbo. But it's true that Qlib as some limitation due to is status (no more developpped) and (good) work made around Turbo is a good news (my intention is not to critic this work). Turbo updates come in days once a feature is requested or a bug spotted. When I first encountered the BLOCK high-colour bug (Turbo would not assign GD2 colour values to blocks) it took George about half a day to fix it. Since Q-Liberator is not being developed any more (based on what you said as I do not know anything about it, only used it once at a friend's QL; never liked it anyway :-) I think that the choice is obvious. Phoebus -- Visit the QL-FAQ at: http://www.dokos-gr.net/ql/faq/ (Still uploading stuff!) Visit the uQLX-win32 homepage at: http://www.dokos-gr.net/ql/uqlx.html Visit the uQLX-mac home page at:http://www.dokos-gr.net/ql/uqlxmac.html
Re: [ql-users] Quanta
On Tue, 10 Feb 2004 15:46:28 -, P Witte [EMAIL PROTECTED] wrote: Dilwyn Jones writes: What I'm getting at (not being familar with PC networks) is would you need a driver to access Ethernet in general (or another QL on ethernet), another driver to access a PC over a network, another driver to talk to a printer hub, another to talk to a Mac etc etc. I am still smarting a bit from other QL hardware like Aurora which for all their promised merits (no blame fired at anyone here) were not fully usable until the drivers eventually came along (thinking of Aurora 256 colours which were not fully supported until Marcel took the law into his own hands). You can probably see what I'm hinting at, if drivers are an issue, and we were asking Quanta to assist with development costs, need this only apply to the hardware or do we need to think of the software costs too. How about the existing NET driver; could that be easily converted to run over Ethernet? At least that would enable non-QL QLs with Ethernet capabilities to communicate.. Per Over Ethernet I would imagine. An hardware ethernet skeleton driver already exists (works with the alpha version of qlwIP) You would still need some adaptation of the OSI model be it TCP/IP or otherwise to talk over the ethernet connection however. There are several layers of which the current NET driver would cover only two. You would still need level 1 to begin, some method of addressing, NetBIOS or otherwise etc... In any case, it's a fairly complicated implementation. The only logical solution would be to support Peter Graf with qlwIP as it already works fine (although slow due to the round-robin style QL scheduler). A hybrid-type of scheduler should be implemented in order for the existing driver to be able to speed up to its full potential. (Hybrid meaning a combination of multi-threading and cooperative semi-round robin scheduler). The easiest (in theory) solution would be to provide within the scheduler a mechanism for jobs to operate in a semi-supervisor state; ie have all the properties of supervisor mode -ie full control- but not being in ACTUAL supervisor mode. The theoretical mechanism would be to allow for a job generated user-interrupt to stop the regular scheduling of jobs and revert control for this timeslice back to the requesting job as needed. The job therefore would determine how long it would execute instead of the other way round. Using this method we could have a 'super' job category but for all purposes the scheduler would look exactly the same to the outside world. Phoebus -- Visit the QL-FAQ at: http://www.dokos-gr.net/ql/faq/ (Still uploading stuff!) Visit the uQLX-win32 homepage at: http://www.dokos-gr.net/ql/uqlx.html Visit the uQLX-mac home page at:http://www.dokos-gr.net/ql/uqlxmac.html
Re: [ql-users] Quanta
Phoebus R. Dokos (Öïßâïò Ñ. Íôüêïò) wrote: In any case, it's a fairly complicated implementation. The only logical solution would be to support Peter Graf with qlwIP as it already works fine (although slow due to the round-robin style QL scheduler). A solution that should work with existing SMSQ/E versions has been provided (rescheduling after IRQ). All Peter says to this is it didn't work under QDOS. Anyway it's not even sure whether his current approach fails under SMSQ/E. According the the mails I've read it hasn't even been tried! So, even if we really needed a new scheduler, which I think we don't, Peter wouldn't be able to use it as he refuses to use any new SMSQ/E version. Catch 22. OK, perhaps somebody could provide QDOS classic with a new scheduler. But then again, I could also win the lottery on Saturday. Marcel
Re: [ql-users] Quanta
On Fri, 13 Feb 2004 04:13:59 +0100, Marcel Kilgus [EMAIL PROTECTED] wrote: Phoebus R. Dokos ( . ) wrote: In any case, it's a fairly complicated implementation. The only logical solution would be to support Peter Graf with qlwIP as it already works fine (although slow due to the round-robin style QL scheduler). A solution that should work with existing SMSQ/E versions has been provided (rescheduling after IRQ). All Peter says to this is it didn't work under QDOS. Anyway it's not even sure whether his current approach fails under SMSQ/E. According the the mails I've read it hasn't even been tried! True. In any case I was talking about QDOS (Classic) and Minerva. Unbelievable as it may seem, there are users that still require full compatibility with QDOS and SMSQ/e is not an option for them. I have talked to a few (one used Flashback that will not work properly under SMSQ/e AFAIK) and a couple of others running custom QDOS-based software, that unfortunately cannot work with SMSQ/e either. So, even if we really needed a new scheduler, which I think we don't, Peter wouldn't be able to use it as he refuses to use any new SMSQ/E version. Catch 22. You are absolutely right. SMSQ/e's scheduler is indeed adequate (although it could potentially be made better but that would require so drastic a change that wouldn't be worth it). As far as Peter's choice for compatibility and openess, without getting back in the same argument, let's say that it is his choice after all and no one can actually say anything about it :-). Regardless of that, qlwIP indeed works fine and is the only high-speed option available at least for ethernet. With an appropriate driver soQL could do the same things, and potentially better as it is a new implementation, unlike qlwIP that is a port (of sorts). -Note here that I know that Peter has done extensive modifications to the lwIP suite so it's not a 100% port but a combination port and original software-. The not-so-obvious advantage of QlwIP is that it is tested and working for years in a variety of machines, the least of which is a Commodore 16! (If that can work then apparently the software is very good :-) soQL is still being tested and from time-to-time does things in inexplicable ways so one has to choose which one he likes :-) OK, perhaps somebody could provide QDOS classic with a new scheduler. But then again, I could also win the lottery on Saturday. I hope you do ;-) And since I keep my fingers crossed for you, I'll be happy with a 10,000 Euro grant from your winnings :-P Hehe Phoebus -- Visit the QL-FAQ at: http://www.dokos-gr.net/ql/faq/ (Still uploading stuff!) Visit the uQLX-win32 homepage at: http://www.dokos-gr.net/ql/uqlx.html Visit the uQLX-mac home page at:http://www.dokos-gr.net/ql/uqlxmac.html
Re: [ql-users] Quanta
On 13 Feb 2004 at 0:03, Phoebus R. Dokos (Φοίβος Ρ. Ντό wrote: True. In any case I was talking about QDOS (Classic) and Minerva. Unbelievable as it may seem, there are users that still require full compatibility with QDOS and SMSQ/e is not an option for them. Why should that be inbelievable? I have talked to a few (one used Flashback that will not work properly under SMSQ/e AFAIK) Flashback was quite a progmming feat, (very fast), but severely limited in other ways IIRC. I think it interfered with the ALT/Hotkey system. I wonder, if it is only that, whether it wouldn't be possible to set up a simple hotkey to call it up? and a couple of others running custom QDOS-based software, that unfortunately cannot work with SMSQ/e either. custom often meant pretty dirty; didn't it? Anyway I, for one, would be interested to know why his wouldn't work under SMSQ/E (if you have any info on that). (...) As far as Peter's choice for compatibility and openess, without getting back in the same argument, for heaven's sake! Wolfgang
Re: [ql-users] Quanta
On 13 Feb 2004 at 4:13, Marcel Kilgus wrote: But then again, I could also win the lottery on Saturday. Well I hope you don't - you'd probably off to laze in the sun in Barbados, and the QL world still needs you... grin (what you mean you actualyl play the lottery?) Wolfgang
