Code: Select all
17.2.02
INCOMPATIBLE CHANGE: names for TCP/IP devices had to
be changed, 'tcp_' -> '*tcp_' etc.
Marcel
Code: Select all
17.2.02
INCOMPATIBLE CHANGE: names for TCP/IP devices had to
be changed, 'tcp_' -> '*tcp_' etc.
Here's the email from Graeme GregoryXorA wrote:Have you got a link to that discussion?Martin_Head wrote: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.
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!
And here's a link to the discussion https://www.mail-archive.com/search?l=q ... newest&f=1Hi 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.
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.swensont wrote: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
The errors seems to mean InitDrivers call stack went wrong somewhere!swensont wrote: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
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
Code: Select all
100 OPEN_IN#5,"*tcp_127.0.0.1:5800"
Code: Select all
200 OPEN#6,"*tcp_"
210 IP_CONNECT#6,5800,"127.0.0.1"
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
Martin_Head wrote: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.
When in ndr2_byte, the IO routine is called with D0=$53, it returns with D0 still $53.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
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.