Q68 Ethernet

The Thor, Aurora, Q40, Q60 & Q68 etc. are discussed here.
Martin_Head
Gold Card
Posts: 496
Joined: Tue Dec 17, 2013 1:17 pm

Re: Q68 Ethernet

Postby Martin_Head » Tue Dec 31, 2019 11:35 am

Derek_Stewart wrote:If the TCP/IP stack was written or use of on chip solution. What applications are available?

There's the IP Network driver that replicates the QL Network driver over a TCP connection. It currently works with QPC2, SMSQemulator, Qemulator, and UQLX. So long as Q68 supported at least the TCP parts of the IP device driver it should work.

There is also IPBasic which provides a SuperBASIC interface to the IP device driver.


User avatar
Peter
Aurora
Posts: 960
Joined: Sat Jan 22, 2011 8:47 am

Re: Q68 Ethernet

Postby Peter » Mon Jan 06, 2020 3:50 pm

Interesting to read that I gave an early version of QLwIP to someone. ;) Lost all memories on that.

Meanwhile QLwIP runs stable on the Q68, but writing to SDHC card is slower than I can directly explain by the operations involved, so it must be a bug. Also, I have not yet found why unencrypted SMTP (for sending email) now has problems which it did not have at the turn of the century.

Not that a solution for the SMTP problem would by of much practical help. Mailservers with unencrypted SMTP are very hard to find nowadays. (Which is sad, because the contents of most emails is still unencrypted even today, so forcing encryption only for the client-server connection, but not the route over the internet, is still insecure, while hindering low-end hardware.)


User avatar
Peter
Aurora
Posts: 960
Joined: Sat Jan 22, 2011 8:47 am

Re: Q68 Ethernet

Postby Peter » Mon Jan 06, 2020 4:24 pm

Martin_Head wrote:There's the IP Network driver that replicates the QL Network driver over a TCP connection.

I have always wondered why that driver was not implemented using UDP. Since QL network can deal with retransmissions anyway, why the technical requirement for the highlevel TCP protocol, which is far more complex on the driver side?

If that "IP Network driver" supported UDP, I see a reasonable chance for a simplistic Q68 ethernet implementation that for most LANs and internet routers "looks like" normal UDP/IP. It would not actually support defragmentation, but in today's usual LAN or internet traffic fragmentation does not happen anyway, if suitable settings are made and packets < 256 bytes. While not fully standard-conform, such a simple "QLNET over ethernet" solution would be very nice for low-end hardware and likely work in practice.

(That does not mean I give up on QLwIP which of course supports full TCP/IP.)


Derek_Stewart
QL Wafer Drive
Posts: 1605
Joined: Mon Dec 20, 2010 11:40 am
Location: Runcorn, Cheshire, UK

Re: Q68 Ethernet

Postby Derek_Stewart » Tue Jan 07, 2020 9:01 am

Peter wrote:Interesting to read that I gave an early version of QLwIP to someone. ;) Lost all memories on that.
)

I was also given a copy of QLwIP, with the understanding that it was not for general release.


Regards,

Derek
Martin_Head
Gold Card
Posts: 496
Joined: Tue Dec 17, 2013 1:17 pm

Re: Q68 Ethernet

Postby Martin_Head » Tue Jan 07, 2020 10:39 am

Peter wrote:
Martin_Head wrote:There's the IP Network driver that replicates the QL Network driver over a TCP connection.

I have always wondered why that driver was not implemented using UDP. Since QL network can deal with retransmissions anyway, why the technical requirement for the highlevel TCP protocol, which is far more complex on the driver side?

The original idea was to use UDP. But I could never get it to work as is was supposed to in QPC2, but TCP worked fine (although I think it's been sorted out now in QPC2 V5). Also Qemulator does not support UDP, and although at the time SMSQemulator did not support the IP device driver at all, which it does now. It also does not support UDP.

Once I decided to to use TCP, It made writing the driver much easier. I did not have to worry about sending acknowledgements back and doing data checksums. I could just leave that to TCP to handle.


User avatar
Peter
Aurora
Posts: 960
Joined: Sat Jan 22, 2011 8:47 am

Re: Q68 Ethernet

Postby Peter » Tue Jan 07, 2020 2:05 pm

Unfortunately, the TCP requirement takes away almost every charme of the "IP Network driver" for native hardware. The TCP requirement means going from low level (ethernet packets) up to the highest protocol level (TCP) with all it's CPU and memory management overhead and then back down to low level (QLNET) again. Speed loss and complexity without any benefit. While technically, the QLNET structure is almost ideal to access the ethernet packet level directly. (Still I'd use some tricks to make packets look like UDP, not raw ethernet.)

How hard would it be to resurrect your original UDP idea?


Martin_Head
Gold Card
Posts: 496
Joined: Tue Dec 17, 2013 1:17 pm

Re: Q68 Ethernet

Postby Martin_Head » Thu Jan 09, 2020 11:01 am

Peter wrote:How hard would it be to resurrect your original UDP idea?

Not too sure offhand. Channel opening would need a bit of modifying, so you would not need to do the IP_CONNECT and IP_ACCEPT stuff.

The sending and receiving a data packet would want probably the most work. Use of IP_SENDTO and IP_RECVFROM was the original idea, as you could just send the packet to the station you wanted. You may also get broadcasting working too. All the packet checksums, acknowledgments, and re-requests would need to be added.

I'm not too sure if there would be any problems with FSERVE

However if this was all done, At the moment the only system it would likely work on is UQLX. The UDP in QPC2 v4 is flaky. You may be able to open the UDP channels OK, but IP_SENDTO and IP_RECVFROM don't work.

It should work in QPC2 v5 when it comes out. But you would really want to get the other two emulator writers to implement UDP in their systems as well.


User avatar
Peter
Aurora
Posts: 960
Joined: Sat Jan 22, 2011 8:47 am

Re: Q68 Ethernet

Postby Peter » Thu Jan 09, 2020 6:21 pm

Martin_Head wrote:It should work in QPC2 v5 when it comes out. But you would really want to get the other two emulator writers to implement UDP in their systems as well.

Which two do you mean, Qemulator and SMSQmulator?


Martin_Head
Gold Card
Posts: 496
Joined: Tue Dec 17, 2013 1:17 pm

Re: Q68 Ethernet

Postby Martin_Head » Fri Jan 10, 2020 11:54 am

Peter wrote:
Martin_Head wrote:It should work in QPC2 v5 when it comes out. But you would really want to get the other two emulator writers to implement UDP in their systems as well.

Which two do you mean, Qemulator and SMSQmulator?

Yes. A UDP version of my IP Network driver would not work with them, whereas the TCP version does.

As I understand it, Apart from finding someone to write the network stuff for Q68, your big problem is that TCP would be too much overhead for the Q68's processor to handle.

I was thinking about a UDP version of my IP Network driver, and keeping compatibility with the existing TCP one. Now I admit that I know almost nothing networks, so what I am about to suggest may be a stupid idea from the start.

I have an IP_ROUTER program for my IP Network driver that redirects data packets between a local IP Network (multiple emulators, running on one PC) and a external IP Network (single emulators, running on multiple PC's). This program may be able to be adapted so that it talks to the UDP network driver on one side, and converts the data packets to TCP for the other side. So doing all the hard work.

Now, I would expect that most people, who would want to us my IP Network driver and Q68, would be trying to use something like QPC2, or SMSQEmulator as well. So this Router program could sit on the PC ( or one of the PC's on the network) and all the data packets to or from Q68 could go through it. I have already written a C# version of this program, so a modified form could just run as a background job on one of the PC's on the network.

Taking this idea a bit further, I thought that if you had a UDP (or maybe something simpler) driver for Q68. You could do something like the QL emulator writers have done.
Have this separate program running on a PC, or maybe a Raspberry PI, that handles all the complicated TCP stuff for you. Q68 would have driver that on the 'QL' side mimics the IP device driver's Trap#2 and Trap#3 system calls. And sends instructions, and/or data to the remote program to do what's required.

Unless I have missed something, then you should be able to use my IP Network driver without any changes, or indeed any program that uses the QL IP device driver. So long as Q68 supports the required feature, The same as the current software QL emulators.

As I said, this may not be a very good idea. But it would take most of the load off Q68 for networking.


User avatar
Peter
Aurora
Posts: 960
Joined: Sat Jan 22, 2011 8:47 am

Re: Q68 Ethernet

Postby Peter » Fri Jan 10, 2020 1:22 pm

Martin_Head wrote:As I understand it, Apart from finding someone to write the network stuff for Q68, your big problem is that TCP would be too much overhead for the Q68's processor to handle.

When it comes to full TCP/IP, I'm not really looking for someone else to do the job. QLwIP seems the most realistic (and probably only) native solution anyway. The likelyhood that someone else would ever get as far as QLwIP, seems low. Also, I see no other person pioneering native hardware drivers anyway, and I have functioning ethernet code for both Q40/Q60 and Q68. I think I will slowly keep working on QLwIP, as a background task, while I'm not on hardware projects.

The idea of "QLNET over ethernet" was something I saw as a possible shortcut, so people don't have to wait for QLwIP. With the added benefit of being very efficient. One idea was this: I would isolate the (basically working) CP2200 ethernet driver routines I already wrote for QLwIP, so they can be used "standalone", and someone else familiar with QLNET (like Martyn) would replace the lower level of the QLNET driver with my routines. It could simply be implemented with raw ethernet packets first, already allowing LAN connections between native machines. In a second step, I would try to "fake" UDP, so the packets could also be seen by emulators, or pass internet routers. This simplified UDP implementaion would have some restrictions, but I'm optimistic it would practically work.

When discussing this, it appeared that your driver (if it used UDP) might be a better starting point for "QLNET over ethernet" than the current "QLNET" driver for the Q68. (I mean a variant of your driver running natively on the Q68).

I wouldn't say TCP is too much overhead for the Q68, as I did not yet sufficiently debug the speed issues, and there is room for improvement. But it is certainly much overhead for a 68000-like core. And in case of "QLNET over ethernet" a very unnecessary overhead that has no benefit.

Martin_Head wrote:Now, I would expect that most people, who would want to us my IP Network driver and Q68, would be trying to use something like QPC2, or SMSQEmulator as well. So this Router program could sit on the PC ( or one of the PC's on the network) and all the data packets to or from Q68 could go through it. I have already written a C# version of this program, so a modified form could just run as a background job on one of the PC's on the network.

Do I understand correctly, that such a router program would be a requirement to get communication work at all?

For me personally, every approach that requires a PC, Raspi or emulator is too restrictive to be interesting. Direct communication between several Q68 (or other native machines with ethernet) should also work.

The idea was to maybe to run (an adapted version of) your driver natively on the Q68 to achive "QLNET over ethernet". At the moment I do not see how that idea could work if it still depends on TCP. But maybe I misunderstand.



Who is online

Users browsing this forum: No registered users and 1 guest