Announcing availability of a QLNET driver for the Q68 (ND-Q68)

[bixio60]

<>
This is the simple program that run on Q68:

110 ch=FOP_IN ("tcp_time.nist.gov:13")
<>

I just get Not found. What driver do you load?

I load in the Boot:
...............
360 DEFine PROCedure Net_Initz
362 LRESPR IPBasic_cde
365 LRESPR QOENet_bin : PAUSE 10
370 ETH_SETIP : PAUSE 10
375 PRINT 'Q68Net 0.44 ..... loaded'&' ---> IP addr. '&ETH_GETIP$
380 LRESPR netdriver_bin
390 INET_START ETH_GETIP$
395 MAP_I 1,18 :

.......Mapping of all Lan devices

410 IFSERVE
412 END DEFine Net_Initz
415 :
416 DEFine PROCedure QLNet
417 LRESPR win1_q68net_ndq68
420 NET 2 : FSERVE
422 DEV_USE 1,n1_win1_
423 DEV_USE 2,n3_win1_
425 END DEFine QLNet
...........

QoENet 0.44 load ethernet driver for Q68, IPNet 1.15 is the Network Manager, ndq68 is the QLNet driver for Q68. You can find all driver packages on the forum.

Fabrizio

[tofro]

<>
This is the simple program that run on Q68:

110 ch=FOP_IN ("tcp_time.nist.gov:13")
<>

I just get Not found. What driver do you load?

That happens to me as well, sporadically.

That's when the driver couldn't resolve a hostname in time. I tend to do that resolving by hand then and insert the IP address. A bit inconvenient, but works for me.

[Martin_Head]

FSERVE on the Q68 should just strip the n2_ bit off then try to open the tcp_ channel on the Q68, which is known to work.

I'm a bit tied up at the moment to try to replicate it. And the last time I tried to get my QL's to work on the QL network it was a bit of a disaster.
I also don't have a land line internet connection, and I would have to try to get the Q68 to work over WiFi. I think I did it once, I would have to try remember what I did.

[martyn_hill]

Ciao Fabrizio!

I don't have an answer to why your Q68 should restart like that, though I have some ideas.

However, if you are more interested in getting a working solution to time sync your QLs to the Q68, you might want to take an older, less exotic but perfectly effective approach that was originally documented in the Minerva manual and that I use to sync all my QLs on startup to (in my case) one QL which I maintain the clock manually.

It relies on the ability to OPEN_NEW a temporary file, say "tempDateFile$", on the remote 'clock host' (N2) from each of the 'clock peers' (N1 and N3) from their respective boot files, then CLOSEing it again.

Then simply query the Create Timestamp of the file just created using netTime=FUPDT(\tempDateFile$), followed by an SDATE netTime.

Finally DELETE tempDateFile$ from the clock peer host.

Meanwhile, you've got me thinking about the Q68 restart...

[dilwyn]

But be aware that SDATE time (i.e. one parameter) is a Minerva and SBASIC enhancement. IIRC it doesn't work on Sinclair ROMs

On other ROMs, SDATE 0,0,0,0,0,0:ADATE time could probably be used to avoid having to break down 'time' into the six values for SDATE (easy enough with DATE$(time), although I'm not sure if you need to be careful with the sign of the time value - I *think* the sign of the value becomes an issue after sometime in 2029 in some contexts.

[martyn_hill]

Good point, Dilwyn!

Fortunately, Fabrizio is running SMSQe on his SGC equipped QLs (lucky fellow!)

[Martin_Head]

You might like to try to see if the Q68's I2C driver can be accessed over the QL Network.

You could then read the Q68's backup clock. I think the example in the Q68 I2C manual will read the clock as four bytes into a string (If I remember correctly the bytes are in the 'wrong' order (little endian).

My clock setting utility here https://dilwyn.qlforum.co.uk/q68/Q68RTC100src.zip will show you how to read the Q68's RTC and convert it to set the date.

EDIT. Sorry, I forgot that the I2C driver is not a QDOS style driver. So this probably won't work.

[tofro]

What could be of interest in this context is the mem_ device driver which is part of the DIY toolkit (in the v_n section) - That allows you (amongst some really "magic" (or is it dubious?) other stuff) to PEEK and POKE into a remote machine's memory over QLAN (George Gwilt's NET_PEEK does something similar, but allows only read access).

Unfortunately, the Q68 does not emulate the QL real time clock at $18000, so its not possible to remote-PEEK the time with mem_ from there, but you could supply the current clock value at some "known address" and read it from remote, or have the Q68 actively write to it's QL companions directly to the RTC hardware.

[dilwyn]

I forget where I saw this (maybe DIY Toolkit?). Wasn't there a device driver which let you peek the memory of one computer from another over the network? I think it was called MEM or something like that.
If the clock is PEEKable, that might be another way to access the date.

EDIT: It was Volume N of DIY Toolkit, along with the NETPAL software which allows executing commands over QL network. Obviously, no idea if it works with the Q68 network drivers.

EDIT2: Oops, crossed posts with tofro again.

[Derek_Stewart]

HI,

Would NET_PEEK by George Gwilt help in this siuation, where Netpeek loaded on each network statiion can read the ram of the other station.