Ethernet chit chat...

[Peter]

A lot of "consumer" routers went 1000/100 and just dropped 10 support in my experience

Looking at several big German online retailers, literally every new ethernet router had 10 Mbit support. There is no cost advantage in dropping 10 Mbit, so a shortage doesn't sound likely to me.

[Derek_Stewart]

Hi,

I would not be interested in 10Mb/s Network, which is usually half duplex.

I would want to connect into my home network which is running at Gigabit rates. The 4Tb Server, I have located in a remote part of the house. Which makes the server shares availble like local hard drives. I have disabled 10Mb/s networking on the main Switch, since it is just too slow. I would want 100Mb/s as a bare minimum.

Hope this does cause too much of a problem.

Regards,

Derek

[Peter]

Hi Derek,

a QL is far from achieving even 10 Mbit/s throughput, even without any TCP/IP processing on the CPU.
Why is coexistence of a 10 Mbit QL in a Gigabit network a problem? You have switched traffic anyway, or are you still using hubs to connect your devices?

Peter

[Derek_Stewart]

Hi Peter,

I do not use Hubs, I have 1000/100Mbs Duplex network, most 10Mb/s connections are half duplex and only have CSMA/CD error correction.

Moving to 1000/100BaseT there is no collisons using Switches, which is the layout I have, a Gigabit link to the main server. Maybe overkill in the home, but it was easy to seup.

Ideally, I would want the QL to link into the network at least 100Mb/s Full Duplex, work on the PC running QPC2...

[Peter]

Moving to 1000/100BaseT there is no collisons using Switches, which is the layout I have, a Gigabit link to the main server. Maybe overkill in the home, but it was easy to seup.

But then, a 10 Mbit QL behind a switch won't slow the rest of your network.

Ideally, I would want the QL to link into the network at least 100Mb/s Full Duplex, work on the PC running QPC2...

A PC running Qemulator could indeed make use of 100 Mbit.

But the chat was about a chip for QL hardware extension. A QL can handle several Mbit/s of data in the best case. If you use a faster ethernet bitrate, you will still not get faster throughput, just insignificantly lower latencies.

[XorA]

A lot of "consumer" routers went 1000/100 and just dropped 10 support in my experience

Looking at several big German online retailers, literally every new ethernet router had 10 Mbit support. There is no cost advantage in dropping 10 Mbit, so a shortage doesn't sound likely to me.

It is possible I was mistaken about this as I can no longer find such devices!

[Dave]

So here's the summary of my thinking.

From a coding point of view, one chip stands out from the others. If installed in a system, anyone who reads the datasheet can write a BASIC, C or ASM program that directly transfers data to and from the WS5300. No need to deal with a TCP/IP stack whatsoever. This naturally fits in with the QL design philosophy of having intelligent peripherals. It looks like, with even a little prompting, even a less skilled programmer like myself could get the WS5300 working at a basic level. That cannot be said for any of the other options presented.

The second attractive thing about the WS5300 is that it can work as well on a 7.5MHz QL as a 25MHz one. The system overhead would be relatively light.

Now, the reality is that the WS5300 does have some limitations; for example, it only supports 8 ports when used in intelligent mode. However, that limitation disappears if used in the same mode the other options are used in. Therefore it has the same development hurdles, no more and no less if used in that mode.

I suspect the "quick start" nature of the WS5300 means we will quickly see new applications developed for it, or existing applications made aware of how to use it.

The CS2200A which is used in the Qx0 is the other contender. What I struggle with is that this option has been available to owners for 15+ years and yet nobody has used it in QDOSMSQ... Since it is unsupported, using a different chipset doesn't create a compatibility split - which was something I expressly wanted to avoid. My fear is that the same thing will happen if the WS5300 is used. What if I build it and they don't come?

So, currently, my thinking is to use the WS5300. It represents the best opportunities for use at the widest range of skill levels. It is easy to incorporate. It's just the path of least resistance.

The feedback so far has been very interesting to read. I want to express my gratitude to you all for keeping things civil and constructive.

I'll leave discussion open for another day. This period will be for anyone to raise a specific objection / deal-breaker to using the WS5300 that hasn't already be addressed. This isn't a democracy: Sandy get to decide what's a deal breaker, because Sandy will be making the commitment to build it and support it. I have a couple of very skilled advisors guiding me, and I trust their judgment.

It will also be the time for those who are interested in doing any development work with the WS5300 to email me off-forum/list at dave@sinclairql.com with a two-paragraph outline of what they'd do if they had one: what they'd work on, and where they expect things to go with it in the future. You also need to give a commitment to the openness principles in the first post:

1. You'd join a developer mailing list and report occasionally on progress you'd made to the other three people and me. Others could join the list to provide feedback, etc. The list would allow you to self-co-ordinate your efforts within the group. I would not be the boss of you. I would not own your work. There is no schedule or deadline.
2. Anything you do, once reaching a state of development greater than "alpha", would be open source and freely distributable. A GIT repository or similar would be nice.
3. I would, upon release, host information and downloads at SinclairQL.com so people can explore the code or develop it further.

If I get more than 3-4 interested people I might have a couple more questions for some of you - or if your ideas are really great I might make a couple of extra prototypes.

Remember, email me off-list if you're interested in the beta program.

Thank you.

[tofro]

All,

not specifically related to the choice of Ethernet chips, but more on the application side:

What I would really like to see is a "Native QL Network"<->Ethernet bridge, i.e the ability to transport native QL networking over an Ethernet (or IP) tunnel. This would allow networking between "real" QLs, the QXL and emulated boxes. This is maybe not something that needs to run on a real QL but could be done using an embedded headless controller that sits "on the wire". But the capability to do that should be considered with the driver, as QLs connected to "real" Ethernet should be able to understand both types of traffic.

When Ethernet-based networking is being introduced on the QL, anything that does only concentrate on standard IET protocols, e-Mail and Web not incorporating things like FSERVE or transparent network output that the QL had 25 years ago would be a step backwards.

Regards,
Tobias

[Peter]

The CS2200A which is used in the Qx0 is the other contender.

Qx0 uses RTL8019 (NE2000 compatible). The CP2200 ("P" not "S") is used on the Q68.

[Nasta]

All,
not specifically related to the choice of Ethernet chips, but more on the application side:
What I would really like to see is a "Native QL Network"<->Ethernet bridge, i.e the ability to transport native QL networking over an Ethernet (or IP) tunnel.

A long time ago I explored using a National Semi AT/Lantic 10Mbps ethernet chip on the QL and step 1 in software support would have been exactly what you propose, specifically QL network through ethernet (not IP). Given some basic routines to send and receive packets as well as resolve MAC addresses (which is pretty much standard stuff one needs to do anyway!), it should not be difficult to put QL net on top of that, because it's a packet network to begin with. The packets are quite easily encapsulated into ethernet. The 'meat' of the problem is addressing as ethernet is MUCH more extensive in that matter, as well as routability.
To be clear I am talking here of TK2 style networking.
Ultimately, IP encapsulation may end up being simpler because we are now in the domain of IP addressing, which has a clear definition of a local area network address pool, which can be handled by an inteligent ethernet chip like the above mentioned Wiznet, which I suppose is one more plus for that hardware solution.
As far as I remember (it has been more than a decade!) FSERVE is a job that implements a protocol akin to remote call, which builds on top of the existing net protocol.
A while ago there was a discussion on various types of drivers where I mentioned the possibility to use a non-directory driver as a directory driver to circumvent the 36 character name limit. This ugly beast rears its head again in networking. TT did the best job he could without having to completely redo the file system by naming the net device with a single letter, I suppose the ethernet variant would then be 'e' instead of 'n'. I suppose some sort of 'address offset' to translate ex (x being the station number) to say 192.168.a,b+x would be supported by a configuration command.