The Sinclair QL Forum

quantumDavey wrote:Hey yeah ! Non profit sounds fine to me.

Dave
(The other one

Hey Dave, that's great to hear. The biggest need for help is on the SW side of things. If you feel like writing some assembler, it would be magnificent I have a lot of nice submodules to work on, if you feel inclined to help.

I guess you would need a prototype board to be able to test stuff. Send me a private message if you feel you would like to participate in the project.

Cheers,
Petri

Hi,

Can the existing work on the TCP/IP Stack not be used, SoQL by Jonathan Dent.

Could implementation of the UQLX stack be done, but this is using the Linux interface, this is also implemented in QPC2 as well.

If you need any help with the assembler programming, maybe I could help.

Derek_Stewart wrote:Hi,

Can the existing work on the TCP/IP Stack not be used, SoQL by Jonathan Dent.

Could implementation of the UQLX stack be done, but this is using the Linux interface, this is also implemented in QPC2 as well.

If you need any help with the assembler programming, maybe I could help.

Hi Derek!

The W5300 chip on the card has a full TCP stack implementation including buffers so a software TCP stack on the QL side is actually not necessary (unless using the chip in MAC RAW mode). The driver is essentially nothing more than a translation layer for QL channels to UDP/TCP sockets plus a DNS name resolver and obviously some resource management including a netdb implementation. The driver also caters to the needs of the existing C68 socket library making it possible to use the existing binaries that use TCP functionality.

Thank you for your kind offer to help, I would love to get additional eyeballs on the project! I'm at work now but I'll PM you later tonight with some details and ideas for possible areas of collaboration.

Cheers,
Petri

Derek_Stewart wrote:Can the existing work on the TCP/IP Stack not be used, SoQL by Jonathan Dent.

AFAIR SoQL was for serial line only.

If a native stack was required for Petri's hardware, then QLwIP or (for a non-multitasking, non-socket, single application) uIP would be the better way to go, because of their ethernet support.

Derek_Stewart wrote:Could implementation of the UQLX stack be done, but this is using the Linux interface, this is also implemented in QPC2 as well.

Hardly, as they both don't contain a TCP/IP stack at all, and use emulator specific methods (e.g. for establishing a connection) which are not well suited for a native approach.

Peter

Paul wrote:If you like I can design a pcb for you and have some prototypes made.
Non profit would be great for me.
I'm not into QL software. So I can only help on the hardware side.
Kind regards
Paul

Wouldn't a CP2200 card be easier? All I need to do then, is to replace the RTL8091 specific low level in QLwIP. You have seen QLwIP at Edinburgh.

Just in case the hardware of the card works okay, I should be able to do the software on one weekend (for a multitaksing, multi-application, but single binary approach).

On the ethernet side, you could simply copy my Q68 schematics. The CP2200 is 5V compliant and has an 8 bit bus. Whether you run into the usual QL signal problems, is a different question. (But you have that for any QL hardware with "modern" chips.)

I know it would be another distraction of my time from the Q68 project, but the Q68 uses the CP2200 also - which motivates me.

In any case, Ethernet on a QL will be very slow. People might overestimate what is possible with a 68008.

Peter

ppe wrote: The W5300 chip on the card has a full TCP stack implementation including buffers so a software TCP stack on the QL side is actually not necessary (unless using the chip in MAC RAW mode). The driver is essentially nothing more than a translation layer for QL channels to UDP/TCP sockets plus a DNS name resolver and obviously some resource management including a netdb implementation. The driver also caters to the needs of the existing C68 socket library making it possible to use the existing binaries that use TCP functionality.

Cheers,
Petri

Hello Peter, are you aware that a TCP stack is not needed for this module as it's implemented in the chip already? And Q40 compatibility is not needed for a BBQL
Kind regards
Paul

Paul wrote:Hello Peter, are you aware that a TCP stack is not needed for this module as it's implemented in the chip already? And Q40 compatibility is not needed for a BBQL

Hi Paul,

of course I am aware. That's why I wrote "if a native stack was required" when replying to Derek.

But are you aware that QLwIP already contains a multitasking TCP/IP stack, so an on-chip stack saves no work?

I have no idea why you seem to call QLwIP Q40/Q60 specific. As I pointed out in Edinburgh, I already used it on a QL over serial line. The lowest layer is of course chip-specific, but the same goes for Wiznet.

My post was just meant to show the probably most simple hardware solution.

I am not in opposition to the Wiznet at all. Just notice that losing Q40, Q60 and Q68 compatibility will split TCP/IP development between the native hardware platforms. We would end up with three flavours:

1. TCP/IP stack running on PC (emulators)
2. TCP/IP stack running on QL (QLwIP)
3. TCP/IP stack running on a chip (Wiznet)

It is quite unrealistic to make the software interfaces compatible.

Kind regards, Peter

Hello,

having suffered from some health problems I've been gone quite a while but am now recuperating slowly.

It seems there's been quite a lot of activity and very exciting projects on QL networking! This is excellent!

There was an interesting test with Q68 and the CP2200 Ethernet controller where, I think, Jan measured throughput to RAM disk to be around 35kB/s.

Out of curiousity and purely as an academic exercise I fired up my old prototype W5300 based card and wrote some more software for it. Specifically, I created a "wget" style HTTP file copier and an lbytes replacement that loads a binary from HTTP server direct to memory. I hosted the binaries on my Mac's Apache HTTP server. The binaries are a C/ASM hybrid compiled with XorA:s excellent docker-packaged qdos-gcc. The code adds the utilities as superbasic extensions.

Based on initial testing, it looks like W5300's on-chip hardware TCP stack and the copious amount of on-chip buffer memory are, from a performance perspective, very convenient to have on a black box QL.

So, on my 640kB black box I got a throughput of around 40kB/s to a file in RAM1_ with "wget" and approx 50 kB/s direct to an ALCHP:d RAM buffer. I like this because it's much faster than loading through a flp-controller from HxC SD-card. Plus, this saves me the SD card shuffle between my Mac and the HxC.

If I have the energy, I think I'm going to add Q-Emulator file header and XTcc detection so that it is possible to web_exec a binary direct from a web server.

Hope everybody's well despite the horrible COVID situation in some place. Best regards from a wintery Finland.

ppe wrote:There was an interesting test with Q68 and the CP2200 Ethernet controller where, I think, Jan measured throughput to RAM disk to be around 35kB/s.

Q68 TFTP file transfer througput with Wolfang's driver is > 160 kBytes/s here, even with SD card.

Peter wrote:Q68 TFTP file transfer througput with Wolfang's driver is > 160 kBytes/s here, even with SD card.

Very nice! Great to hear that a modern CPU core and bus architecture gives so good results. On the black box the real limit is the memory bandwidth. The limit is word copy speed from one memory location to another. My code is reading from a word-wide memory mapped IO port that goes to a FIFO on the W5300 and writing to QL main memory in a two-instruction (MOVE + DBF) loop.