Adjusting the QNET timings on a QXL2

[martyn_hill]

Hi everyone

Question:
How do you find the Device Definition Block (DDB) base-address from SBASIC for the NET device on a QXL under SMSQ/E?

Context:
Whilst still exploring the QNET capabilities across various platforms, I purchased a refurbished QXL2 (8MB, 40MHz osc => CPUCLK @ 20MHz) from Derek a little while ago and am now testing the network.

Derek had fitted an 68RC040 on the card that apparently came from a Q40 - runs very nicely using the latest SMSQ/E v3.33.

My first testing of the network on this little beastie failed between both an iss7 QL as well as my prototype QNET to USB adapter attached to my QPC-running laptop (still a work in progress - see elsewhere...).

Attaching my cheapo digital analyser, I see that the bit-timings are just a bit too short to allow reliable connection with the QL. By adjusting the timings on the QNET/USB adapter, I can read the packets from the QXL OK. The difference is just 5% off - accumulatively (?) half a bit-time after 9-bits (START+8-bits) - and just enough for the receiving QL to misinterpret the STOP bit as the final/MSBit of the sent byte.

QXL also delivers a relatively shorter set of STOP bits, but the QNET protocol takes that in its stride.

See attached screen-captures - the nominal QNET bit-timing is 11.2us, resulting in 100.8us for the 9-bit (partial) frame. The QL meets this, but the equivalent QXL frame runs to only 96us. The sample rate was only 1Mbps, so to the nearest 1us...

QL Iss7 NET frame timing

QXL NET frame timing

I've tested with CACHE_ON and CACHE _OFF - same results.

Referring to the SMSQ/E sources for the QXL Net code, we see that the the timing constants are exposed in the DDB for the NET device, which is handy (though not as handy as the hardware timer approach that we could use on the Q68.)

We can pick-up the Driver Linkage Block address from the Channel Def Block (CDB) for an open NET channel, but I'm struggling to follow all the redirection to find the DDB base address itself from where the NET timing-constants table - ndt_ctab @ $50(a3) - could be read and altered (extended by 5%.)

I'd like to experiment with some adjusted timings in the DDB before attempting to recompile SMSQ for the QXL with the adjusted timings.

Any help finding the DDB address for an open Net Channel from SBasic would be appreciated!

M.

[janbredenbeek]

The pointer to the linkage block can be found using PEEK_L(base_of_channel_definition_block+4). The pointers to the I/O, open and close routines are then at offset 4, 8 and 12 respectively. But when calling these routines register A3 is set to point 24 bytes below this, to allow for linked lists for external, polled and scheduler tasks. So you should calculate A3=PEEK_L(chan_def_base+4)-24 to get the base of the linkage block.

Jan.

[martyn_hill]

Thank you Jan (and Wolfgang, via the QL Users list)

Having now found what appears to be the DDB and taking account of the -$18 (24) offset from the link in the CDB, I can identify the NET device pointers from $18 through $33, with the distinctive RTS ($4E75/20085) appearing at $34 as expected.

However, from the ndt_ctab offset $50 onwards, I can't make sense of the words that appear there. They should hold the timing constants (not actually the values shown below, but after some manipulation in the nd/initv code) thus:

Code: Select all

ndt_ctab equ    $50
ndt_wgap equ    $50     wait for gap constant                200us
ndt_lsct equ    $52     look for scout                     20000us
ndt_bace equ    $52     look for broadcast acknowledge end 20000us
ndt_csct equ    $54     check scout                        30;40us
ndt_esct equ    $56     end of scout                     475;485us
ndt_wsct equ    $58     wait to send scout                  3000us
ndt_tsct equ    $5a     timer for scout active / inactive   4;59(2)
ndt_bsct equ    $5c     broadcast scout detect               500us
ndt_back equ    $5c     broadcast acknowledge detect         500us
ndt_xsct equ    $5e     extension to scout                  5000us
ndt_xack equ    $5e     (extension to) acknowledge          5000us
ndt_bnak equ    $60     broadcast NACK delay                 200us
ndt_stmo equ    $62     serial port timout                 20000us
ndt_paus equ    $64     pause before send                120;140us
ndt_send equ    $66     send loop timer                     2;33(0)
ndt_rtmo equ    $68     receive timout                      2500us
ndt_rbto equ    $6a     receive bit timout                    80us
ndt_rdly equ    $6c     receive delay start bit to bit 0    6;63(0)
ndt_rbit equ    $6e     receive bit loop timer              5;32(0)
ndt_ctop equ    $70

But what I find there looks like:

Code: Select all

50:       0
52:     124
54:  -18236
56:       0
58:      36
5A:       1
...
6A:   20085
6C:       0
6E:     134

That '20085' at offset 6A in particular looks more like another RTS rather than the 'receive bit timeout' constant.

So, I'll need to dig a little deeper. Thanks for your answers!

M.

[martyn_hill]

Hi again everyone

With thanks again to Wolfgang in identifying a further adjustment to the start of the NET timing-constants table (ndt_ctab) held in the DDB of the NET driver, I can confirm that an adjustment of 5% to each of the timing-constants allows successful net operation on the QXL.

Whether the original timing error was specific to my QXL card, or might be relevant for other QXL users as well, I can't say, but for the record I present here the original and adjusted timing-constants as held in the DDB:

Code: Select all

T/C#    Old T/C Old+5%  New T/C
====    ======= ======= ========
0       134     140     141
1       13570   14248   14284
2       19      19      20
3       328     344     345
4       2034    2135    2141
5       17      17      19
6       338     354     356
7       3391    3560    3570
8       134     140     141
9       13570   14248   14284
10      94      98      99
11      35      36      38
12      1695    1779    1784
13      53      55      56
14      20      21      22
15      36      37      39

Note that the adjusted constants here may not be 100% correct - but sufficient to get the network running again.

Here's the end-result:

Here's also the SBASIC I coded to make the changes directly in the DDB:

adjust_NET_TCs_bas.zip

(566 Bytes) Downloaded 234 times

My next step would be to update the QXL SMSQ/E source and re-compile with the adjusted timing-constants (not what you see above, but the original micro-second values that are used to calculate the final values.) But that's for another day.

Thanks to Wolfgang and Jan for their advice.

Martyn.