Ubuntu 14.04.4 and uqlx2017

[mk79]

The version history says this for the latest original uQLx version:

Code: Select all

17.2.02
   INCOMPATIBLE CHANGE: names for TCP/IP devices had to
     be changed, 'tcp_' -> '*tcp_' etc.

Unfortunately it doesn't mention WHY they "had to be changed"... QPC has had the TCP etc devices for 13 years without problems.

Marcel

[Martin_Head]

I e-mailed Graeme Gregory to ask if the IP Device Driver was working in UQLX 2017. He says that he has never used IP on UQLX.

From a search on the web, I found that back in 2009 someone was having problems getting the IP driver to work when compiling UQLX. Something to do with the version of the software used to the compiling.

So as I can't seem to get the driver working, I am going to assume that the IP Device Driver does not work, or does not work correctly in UQLX 2017.

Have you got a link to that discussion?

Also do you have a simple test case? I think Dilwyn did post one ages ago but I forgot where.

I have a couple of days hols next week so I might get a chance to take a look and see what the deal is with uQlx!

Here's the email from Graeme Gregory

Hi Martin,

I have never used IP on uQlx!

Thanks

Graeme

On Wed, 19 Sep 2018, at 11:23 AM, Martin Head wrote:
> Hi, Sorry to bother you, But could you tell me if the IP Device driver
> is working in UQLX 2017?
>
> I have been trying to test my IP Network Device Driver with UQLX 2017,
> but I cannot seem to make it work. And other tests I try with the IP
> devices give me odd results.
>
> I am using Xubuntu 14.04 in a 32 bit desktop system.
>
> I know that the IP device names have been changed to have a * placed in
> front of them e.g. *TCP_
> I was wondering if that was to indicate that they are not usable.
>
> I will say upfront that I know virtually nothing about Linux, so it may
> be something I am doing wrong.

And here's a link to the discussion https://www.mail-archive.com/search?l=ql-users@lists.q-v-d.com&q=subject:%22%5C%5Bql%5C-users%5C%5D+UQLX%22&o=newest&f=1
Search on the page for 'not working' and 'gcc for cygwin'. I know they go back a bit 2004 and 2009

Here's a patched copy of my Network driver, where I have changed TCP_ and SCK_ to *TCP_ and *SCK_

uqlxNETdriver.zip

(50.55 KiB) Downloaded 39 times

A user manual is available on Dilwyn Jones web site.

The driver does not give any errors. It starts up normally, but just does not work. I was first trying to network to a PC running QPC2, but I am not sure if the the two PC's were talking to each other (I cannot get get then talking via a Windows Workgroup). So I then tried running two copies of UQLX on the same PC, and tried unsuccessfully to get them to to talk to each other.

The *TCP_ etc device names are a bit of a pain, as the other IP stuff I have written (IPBasic) would also need to be re-assembled.

This is why I am trying to find out if the IP Device Drivers are working, before I spend time trying to figure out why my programs don't work.

[swensont]

Martin,

I can make a few changes to the source code of UQLX ( on my system) to edit out the *, and recompile. I will then retest with Dilwyn's test program. If you have a short test suite for your IP driver, I can test out the IP driver on the updated UQLX.

Tim Swenson

[Martin_Head]

Martin,

I can make a few changes to the source code of UQLX ( on my system) to edit out the *, and recompile. I will then retest with Dilwyn's test program. If you have a short test suite for your IP driver, I can test out the IP driver on the updated UQLX.

Tim Swenson

If you recompile you will need the normal Net driver http://www.dilwyn.me.uk/internet/NETdriver112.zip, rather than the one I posted earlier.

Usually the easiest test is to start two copies the the QL emulator on the same PC. Each running the network driver. Then on one enter NET_START 1 and on the other NET_START 2

On the net 1 station enter FSERVE, and on the net 2 station enter DIR n1_win1_ or whatever. If you get the directory, then you are pretty much working.

To test with 2 PC on the same network, with say IP Addresses of 192.168.0.5 and 192.168.0.7 Then start the QL emulator on the 192.168.0.5 PC with NET_START "192.168.0.5".
This QL will be Network station 5. and do likewise on the other PC, and that will be QL network station 7
Then on the net 5 station enter FSERVE, and on the net 7 station enter DIR n5_win1_

I don't know about Linux systems, but on my Windows 8/10 systems. I have to get the two PC's seeing each other before starting the QL network up. This usually involves starting, I think its called Network Discovery.

[swensont]

I have compiled UQLX with the change from "*tcp" to "tcp". I ran TCP test that Dilwyn wrote that gets a web page. That worked.

I then started testing the IPdriver version 112.

I fired off SMSQmulator, loaded NETdriver_cde, then ran NET_START 1 and FSERVE.

I fired off UQLX (./qm), loaded NETdriver_cde, then ran NET_START 2. When I ran the command "dir n1_ram1_" the shell from which I started UQLX was outputting:

possible driver problem ??

This message appears twice in QL_driver.c, in the functions DrvIO and DrvClose. I changed the text output to be "possible driver problem 1 ??" for DrvIO and 2 for DrvClose. I ran the test again and got the output from both functions, over and over and over.....

I also tried "dir n1_win1_" and got the same output.

I decided to switch things up and make UQLX the server. I did the same start then added FSERVE. I then went to SMSQmulator and ran "dir n2_win1_". The shell that I started UQLX in started spitting out:

ip_test: match ip_test: match ip_test: matched .......

This error message comes from QLip.c. It is supposed to be outputing a variable called "name" but it appears to be blank in the output.

I think this is about as far as I can go (not being a C expert).

Tim Swenson

[Martin_Head]

Have you tried running my Network driver with two copies of SMSQemulator, so that you know you have seen it working.

Now you have recompiled QULX, You might like to try http://www.dilwyn.me.uk/internet/IPBasic.zip It's a SuperBASIC interface to the IP device driver, that allows you to use individual IP calls. You may be able to track down what IP driver commands are causing problems.

For anyone interested in what IP device driver system calls my Network driver makes.

They are - IP_BIND, IP_OPEN, IP_LISTEN, IP_ACCEPT, IP_CONNECT, IP_SEND, and IP_RECV

[XorA]

I have compiled UQLX with the change from "*tcp" to "tcp". I ran TCP test that Dilwyn wrote that gets a web page. That worked.

I then started testing the IPdriver version 112.

I fired off SMSQmulator, loaded NETdriver_cde, then ran NET_START 1 and FSERVE.

I fired off UQLX (./qm), loaded NETdriver_cde, then ran NET_START 2. When I ran the command "dir n1_ram1_" the shell from which I started UQLX was outputting:

possible driver problem ??

This message appears twice in QL_driver.c, in the functions DrvIO and DrvClose. I changed the text output to be "possible driver problem 1 ??" for DrvIO and 2 for DrvClose. I ran the test again and got the output from both functions, over and over and over.....

I also tried "dir n1_win1_" and got the same output.

I decided to switch things up and make UQLX the server. I did the same start then added FSERVE. I then went to SMSQmulator and ran "dir n2_win1_". The shell that I started UQLX in started spitting out:

ip_test: match ip_test: match ip_test: matched .......

This error message comes from QLip.c. It is supposed to be outputing a variable called "name" but it appears to be blank in the output.

I think this is about as far as I can go (not being a C expert).

Tim Swenson

The errors seems to mean InitDrivers call stack went wrong somewhere!

[Martin_Head]

I have re-assembled my IPBasic program to use a '*' in front of IP devices. And did a quick test on UQLX2017

IPBasic.zip

(22.82 KiB) Downloaded 38 times

If you open two copies of UQLX on the same PC. Then on one enter

Code: Select all

100 OPEN#8,"*tcp_"
110 IP_BIND#8,5800,"127.0.0.1"
120 IP_LISTEN#8
130 REPeat loop
140  ch=IP_ACCEPT(#8)
150  IF ch>0 THEN EXIT loop
160  IF ch<>-1 THEN
170   PRINT "Error during ACCEPT - ";
180   STOP
190  END IF
200 END REPeat loop

This will be the server. Run the program and it will sit in a loop waiting for a connection request

On the other copy of UQLX enter

Code: Select all

100 OPEN_IN#5,"*tcp_127.0.0.1:5800"

When you run this the first copy of UQLX will return to Basic, and the variable 'ch' will be the opened channel number.

On the first copy enter INPUT#ch,a$:PRINT a$
And on the second copy enter PRINT#5,"Hello"

And this seemed to work OK. So you can get then to talk to each other.

You can also restart the server on the first copy with a GO TO 130, and on the second copy try this, which is basically the same as the OPEN_IN

Code: Select all

200 OPEN#6,"*tcp_"
210 IP_CONNECT#6,5800,"127.0.0.1"

This will open another channel on the server, and change the value of the variable 'ch'

I also tried sending data the other way, which worked OK.

[Martin_Head]

I have been doing a few tests trying to find why my network driver does not work with UQLX2017.

I have found odd behaviour when it tries to read from the network with a system trap call. It does not return an error code in D0, D0 remains unchanged.

Here's a code snippet from my driver.

Code: Select all

; --------------------------------------------------------------

; Read bytes. Read an IP packet
; entry: D2 (maximum)byte count to read, A1 address of buffer, A0 cdb
; exit:  D0=0 or error code, D1 number of bytes read into buffer
;        D7 smashed, A1 set to network running pointer

; Trap #3 calls to the IP channel caused lots of problems here. Trap #3's replaced
; with direct calls to the IP I/O driver routines

ndr_bytes
         move.l   nd_rpnt(a0),a1                ;read multiple bytes into data buffer

; A1 is a pointer to the buffer, D2 is the maximum size of the buffer
ndr_1byte
         movem.l  d2-d4/a0-a3,-(a7)             ;save registers
         move.l   d2,d4                         ;save the maximum number of bytes to be read
   
         move.l   nd_chid(a0),a0                ;get IPchannel ID
         bsr.s    io_ckchn                      ;convert channel ID to the address of the cdb & A3 points to Linkage block
         bne.s    ndr_done                      ;invalid channel?
         
         move.l   $1C(a3),a3                    ;get the start address of the IP I/O routine
         
; Wait for at least 2 bytes of the packet length to be available
ndr_2byt moveq    #$53,d0                       ;IP_RECV
         moveq    #2,d1                         ;peek the receive queue
         moveq    #2,d2                         ;looking for the 2 bytes of the package length
         jsr      (a3)                          ;call the I/O routine directly - Was Trap #3
         tst.l    d0                            ;any error..
         bne.s    ndr_done                      ;..yes         - was ndr_nc2
         
         cmp.l    d1,d2                         ;got 2 bytes..
         bne.s    ndr_nc2                       ;...no, anything less than 2 bytes is no good
         
ndr_2bok move.w   (a1),d2                       ;get the length of

When in ndr2_byte, the IO routine is called with D0=$53, it returns with D0 still $53.
I know that I am not calling the system trap correctly, but it works OK in QPC2.
The address that is called (A3) contains $AAAAAAAC which is not a valid 68000 code, so I suppose it a trap for UQLX to take over.

Is D0 getting set on return in the QDOS TRAP#3 driver, which I am bypassing? QPC2 must be setting D0 while still outside SMSQ/E.

Could someone who knows how to read the sources of UQLX check what it's supposed to do.

[XorA]

I have been doing a few tests trying to find why my network driver does not work with UQLX2017.

I have found odd behaviour when it tries to read from the network with a system trap call. It does not return an error code in D0, D0 remains unchanged.

Here's a code snippet from my driver.

Code: Select all

; --------------------------------------------------------------

; Read bytes. Read an IP packet
; entry: D2 (maximum)byte count to read, A1 address of buffer, A0 cdb
; exit:  D0=0 or error code, D1 number of bytes read into buffer
;        D7 smashed, A1 set to network running pointer

; Trap #3 calls to the IP channel caused lots of problems here. Trap #3's replaced
; with direct calls to the IP I/O driver routines

ndr_bytes
         move.l   nd_rpnt(a0),a1                ;read multiple bytes into data buffer

; A1 is a pointer to the buffer, D2 is the maximum size of the buffer
ndr_1byte
         movem.l  d2-d4/a0-a3,-(a7)             ;save registers
         move.l   d2,d4                         ;save the maximum number of bytes to be read
   
         move.l   nd_chid(a0),a0                ;get IPchannel ID
         bsr.s    io_ckchn                      ;convert channel ID to the address of the cdb & A3 points to Linkage block
         bne.s    ndr_done                      ;invalid channel?
         
         move.l   $1C(a3),a3                    ;get the start address of the IP I/O routine
         
; Wait for at least 2 bytes of the packet length to be available
ndr_2byt moveq    #$53,d0                       ;IP_RECV
         moveq    #2,d1                         ;peek the receive queue
         moveq    #2,d2                         ;looking for the 2 bytes of the package length
         jsr      (a3)                          ;call the I/O routine directly - Was Trap #3
         tst.l    d0                            ;any error..
         bne.s    ndr_done                      ;..yes         - was ndr_nc2
         
         cmp.l    d1,d2                         ;got 2 bytes..
         bne.s    ndr_nc2                       ;...no, anything less than 2 bytes is no good
         
ndr_2bok move.w   (a1),d2                       ;get the length of

When in ndr2_byte, the IO routine is called with D0=$53, it returns with D0 still $53.
I know that I am not calling the system trap correctly, but it works OK in QPC2.
The address that is called (A3) contains $AAAAAAAC which is not a valid 68000 code, so I suppose it a trap for UQLX to take over.

Thats the code for DrvClose()