uQLx and TCP/IP stack documentation
uQLx and TCP/IP stack documentation
I've created a new page in the Documents part of my website, dedicated to information about the TCP/IP stack included with emulators such as QPC2, uQLx, SMSQmulator and QemuLator.
Personally, I found it hard to come across the information and examples of how to use the facilities from QL BASIC, so after a frustrating few days when I just couldn't find the information to get even the most basic example working, I decided to do something about it myself.
The documents include Richard Zidlicky and Jonathan Hudson's original pages about uQLx (now that Graeme Gregory is pushing ahead with the 2017 update of uQLx for Linux/ARM systems I realised the documentation might be welcome) and the TCP/IP stack originally implemented on uQLx.
I've included a document of mine showing how to use the TCP/IP stack from BASIC to download html pages and read email headers, for example. The document includes example BASIC listings.
There are also links to documents and software from Martin Head, including to his IPbasic software package designed to simplify and enhance the use of the networking facilities, plus a glossary of networking terminology.
I hope this helps generate some interest in the use of the facilities the emulator authors worked so hard to bring us, yet so few people seem to have used.
http://www.dilwyn.me.uk/docs/uqlx_tcp/index.html
Personally, I found it hard to come across the information and examples of how to use the facilities from QL BASIC, so after a frustrating few days when I just couldn't find the information to get even the most basic example working, I decided to do something about it myself.
The documents include Richard Zidlicky and Jonathan Hudson's original pages about uQLx (now that Graeme Gregory is pushing ahead with the 2017 update of uQLx for Linux/ARM systems I realised the documentation might be welcome) and the TCP/IP stack originally implemented on uQLx.
I've included a document of mine showing how to use the TCP/IP stack from BASIC to download html pages and read email headers, for example. The document includes example BASIC listings.
There are also links to documents and software from Martin Head, including to his IPbasic software package designed to simplify and enhance the use of the networking facilities, plus a glossary of networking terminology.
I hope this helps generate some interest in the use of the facilities the emulator authors worked so hard to bring us, yet so few people seem to have used.
http://www.dilwyn.me.uk/docs/uqlx_tcp/index.html
--
All things QL - https://dilwyn.qlforum.co.uk/index.html
All things QL - https://dilwyn.qlforum.co.uk/index.html
Re: uQLx and TCP/IP stack documentation
It's been pointed out that strictly speaking the emulators DON'T have a TCP/IP stack built in as my documents imply, but rather they just use the facilities provided by the host operating system.
I'll make corrections to the page and articles as I get time, but please bear this distinction in mind when studying the information.
Thank you Peter.
I'll make corrections to the page and articles as I get time, but please bear this distinction in mind when studying the information.
Thank you Peter.
--
All things QL - https://dilwyn.qlforum.co.uk/index.html
All things QL - https://dilwyn.qlforum.co.uk/index.html
Re: uQLx and TCP/IP stack documentation
Thanks for posting that info.
I tried a few years ago to get the TCP working just for fun on Qemulator but couldn't figure it out. There are some web and email programs on the Qemulator web site and they run fine. However, when I try to access TCP via SuperBasic nothing seems to happen.
I've run into the same problem with your program. I ran the program but it got to line 150 and just kicked me out to the cursor.
Everything seems to be set correctly as far as I can tell. According to Qemulator help TCP is supposed to be set to on by default anyway (which it is).
Do you have any advice about what to try next?
I tried a few years ago to get the TCP working just for fun on Qemulator but couldn't figure it out. There are some web and email programs on the Qemulator web site and they run fine. However, when I try to access TCP via SuperBasic nothing seems to happen.
I've run into the same problem with your program. I ran the program but it got to line 150 and just kicked me out to the cursor.
Everything seems to be set correctly as far as I can tell. According to Qemulator help TCP is supposed to be set to on by default anyway (which it is).
Do you have any advice about what to try next?
-
- Aurora
- Posts: 852
- Joined: Tue Dec 17, 2013 1:17 pm
Re: uQLx and TCP/IP stack documentation
Testing IP driver stuff on Qemulator is a bit awkward for me as I don't have the full version of Qemulator.dinox wrote: I've run into the same problem with your program. I ran the program but it got to line 150 and just kicked me out to the cursor.
Everything seems to be set correctly as far as I can tell. According to Qemulator help TCP is supposed to be set to on by default anyway (which it is).
Do you have any advice about what to try next?
However a couple of suggestions you could try.
1 If you know (or can find out) the actual IP address of the website you are connecting to. You could try something like OPEN_IN#3,"123.001.121.10:80"
2 Try using my IPBasic package, and replace the the OPEN_IN with an OPEN#3,tcp_ and then do an IP_CONNECT#3,80,"123.001.121.10" These two commands should do the same as an OPEN_IN. In QPC2 when using UDP connections, channel opening and making connections is a bit flaky, and I don't know if Qemulator has similar problems.
Re: uQLx and TCP/IP stack documentation
Thanks for that advice Martin. I've played with it a bit more over the last few days but not got much further. One of the main problems of course is that I don't have a clue what I'm doing!Martin_Head wrote:
Testing IP driver stuff on Qemulator is a bit awkward for me as I don't have the full version of Qemulator.
However a couple of suggestions you could try.
1 If you know (or can find out) the actual IP address of the website you are connecting to. You could try something like OPEN_IN#3,"123.001.121.10:80"
2 Try using my IPBasic package, and replace the the OPEN_IN with an OPEN#3,tcp_ and then do an IP_CONNECT#3,80,"123.001.121.10" These two commands should do the same as an OPEN_IN. In QPC2 when using UDP connections, channel opening and making connections is a bit flaky, and I don't know if Qemulator has similar problems.
1. Using the actual IP address didn't make any difference.
I also double-checked Linx worked OK (run from Qemulator site), then stopped that program and tried the basic program again just in case there was something strange in the settings I was using. No difference.
I checked the channel was closed and the open #3, tcp_ line of basic did seem to open a channel. It does. The next line of code, printing to the channel, seems to were the program kicks me out. I don't see why that should be since it only appears to be writing to an open channel. Or is that telling us that the channel is not really open?
2. I had a look at your IPBasic package but got stuck. Do I run that as an exec file?
All the best.
Stephen
-
- Aurora
- Posts: 852
- Joined: Tue Dec 17, 2013 1:17 pm
Re: uQLx and TCP/IP stack documentation
Just LRESPR it. It will add a bunch of new Keywords to BASIC.dinox wrote: 2. I had a look at your IPBasic package but got stuck. Do I run that as an exec file?
A thought occurred to me that perhaps the IP channel was not being opened, or connected correctly. But not returning an error. The PRINT command would then fail, with an IP device driver error that QDOS did not expect from a PRINT command. So it just dumps you out of the program without an error massage, because it does not know which one show.
Re: uQLx and TCP/IP stack documentation
That does seem to be correct.Martin_Head wrote:
A thought occurred to me that perhaps the IP channel was not being opened, or connected correctly. But not returning an error. The PRINT command would then fail, with an IP device driver error that QDOS did not expect from a PRINT command. So it just dumps you out of the program without an error massage, because it does not know which one show.
After I loaded your new commands and tried suggestion (2): no joy...
I then tried:
Open#3,tcp_
Print #3,"test":print #0,"ok"
It dumped me out without printing ok and no error message.
Also, when I close #3 and then print #3,"test" it reverts to giving me an error message of channel not open.
- janbredenbeek
- Super Gold Card
- Posts: 632
- Joined: Wed Jan 21, 2015 4:54 pm
- Location: Hilversum, The Netherlands
Re: uQLx and TCP/IP stack documentation
You have to do something like this:dinox wrote: I then tried:
Open#3,tcp_
Print #3,"test":print #0,"ok"
Code: Select all
OPEN_IN#3,"tcp_hostname:port"
An example is in the QLTERM v2.35 package in Dilwyn's comms software archive. This includes a S*BASIC procedure which opens a Telnet connection and then starts a terminal program with the specified channel so the program (which was never written with TCP/IP in mind!) now acts as a Telnet client.
Jan.
Re: uQLx and TCP/IP stack documentation
It's just like Jan says.
Network programming is a bit different from opening channels directly to a device like ser or par. The simple S*BASIC I/O interface is not ideally suited for this.You must imagine you open a channel to a switchboard, rather than directly to the target.
Plain OPEN simply opens this switchboard device. Without connecting the switchboard to anywhere, you will not be able to transfer data. A switchboard connect can be done by either having someone else connecting to your switchboard, or you connect to somewhere else using additional commands from Martin's toolkit.
OPEN_IN in comparison actually does two things in the uQLX TCP/IP implementation: It connects the S*Basic channel to the swithboard, the other end of the switchboard to the external server (that is why you must supply external server address and port when using OPEN_IN). Using OPEN_IN to connect to an external server is the simplest way to use the TCP/IP device.
OPEN alone will not do anything useful with the TCP/IP device. It is normally used to be able to provide a server by connecting your channel to the switchboard. You will need to use BIND and ACCEPT to either do the second step of connecting the switchboard over the network or let clients connect into your computer switchboard.
Tobias
Network programming is a bit different from opening channels directly to a device like ser or par. The simple S*BASIC I/O interface is not ideally suited for this.You must imagine you open a channel to a switchboard, rather than directly to the target.
Plain OPEN simply opens this switchboard device. Without connecting the switchboard to anywhere, you will not be able to transfer data. A switchboard connect can be done by either having someone else connecting to your switchboard, or you connect to somewhere else using additional commands from Martin's toolkit.
OPEN_IN in comparison actually does two things in the uQLX TCP/IP implementation: It connects the S*Basic channel to the swithboard, the other end of the switchboard to the external server (that is why you must supply external server address and port when using OPEN_IN). Using OPEN_IN to connect to an external server is the simplest way to use the TCP/IP device.
OPEN alone will not do anything useful with the TCP/IP device. It is normally used to be able to provide a server by connecting your channel to the switchboard. You will need to use BIND and ACCEPT to either do the second step of connecting the switchboard over the network or let clients connect into your computer switchboard.
Tobias
ʎɐqǝ ɯoɹɟ ǝq oʇ ƃuᴉoƃ ʇou sᴉ pɹɐoqʎǝʞ ʇxǝu ʎɯ 'ɹɐǝp ɥO
-
- Aurora
- Posts: 852
- Joined: Tue Dec 17, 2013 1:17 pm
Re: uQLx and TCP/IP stack documentation
Dinox is trying to get a BASIC program to run, that works in QPC2, but doe's not in Qemulator.
I have noticed that if you have problems with making the IP connection. The IP device driver can return an 'Access denied" error $E9. This is a SMSQ/E error, There is no corresponding error in QDOS, so perhaps that is why there is no error being reported.
I have noticed that if you have problems with making the IP connection. The IP device driver can return an 'Access denied" error $E9. This is a SMSQ/E error, There is no corresponding error in QDOS, so perhaps that is why there is no error being reported.