On Tue, 10 Feb 2004 15:46:28 -0000, 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>
