Glad I could help, I'll be interested to see how it goes!

Have fun.


On 19/05/2018 16:31, Martyn Hill via Ql-Users wrote:
Great observation, Wolfgang!

So, that adjustment to a3 comes out to $1E (30) bytes /*later */in the DDB - so rather, once the ndt_ctab offset of $50 is added, we need to look at $6E through $8E for the timing constant table.

I now see:

$6E:    134
$70:  13570
$72:     19
$74:    328
$76:   2034

This looks more promising! Now I need to check against the expected values.

The calculations carried out in nd/initv take three words for each constant stored by the macros in qxl.asm (time,offset,scale), which for the first 5 values (assuming a 20MHz clock) are:

nqx_wgap:    200,28,28 =   141
nqx_bace:    20000,28,28  = 14185
nqx_csct:    30,28,28     = 20
nqx_esct:    485,28,28    =   345
nqx_wsct:    3000,28,28   =  2141

Aha! We have accounted for the 5% difference between nominal QNET timings and what was measured down the wire from my QXL!

The actual clock-rate is empirically measured somewhere else in the initialisation code and stored in d1 ready for nd/initv to use, rather than a fixed 20Mhz scale-factor which is how the original scaling factor assumed in qxl.asm. Would seem that the measured clock-rate was slightly lower than it really is.

I'll go ahead and switch-out the stored values in the DDB constants table with the 5% higher figures and re-test.

I love a good detective-story!

On 19/05/2018 13:48, Wolf via Ql-Users wrote:

This is what you can find in the NET driver i/o code:

        pea     ndd_test(a3)            push pseudo return address

        lea     ndd.leni(a3),a3         normal linkage ***********

        move.w  io.serio,a2             and do serial IO
        jmp     (a2)

As  you can see, A3 is adjusted there, perhaps you sould look at the DDB with the same offset.



On 19/05/2018 13:15, Martyn Hill via Ql-Users wrote:
Thanks Wolfgang (and Jan via the Forum)

Having now found what looks like the DDB - taking in to account the -$18 offset from the entry in the CDB - the resultant list of words at offset ndt_ctab ($50) looks suspicious, thus:

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

The '20085' at offset $6A in particular looks more like an RTS instruction than the timing constant for 'receive bit timeout'.

Anyway, I'll keep digging. Thanks!


On 19/05/2018 09:41, Wolf via Ql-Users wrote:

The best way would be to get the channel definition block (CDB) for a channel to the device. I don't know offhand of a Basic keyword that will do it for you, Toolkit III used to have such a function, I don't know whether that still available, though.

If you have that, then the pointer to the driver definition block (DDB) lies at offset chn_drvr (=4) in the CDB - you can just PEEK_L that. Be careful, however, the pointer there normally points to offset iod_iolk (=$18) within the DDB, so all other offsets should be reduced by that same amount.



On 18/05/2018 22:01, Martyn Hill via Ql-Users wrote:
Hi everyone

In the spirit of double-posting between here and the QL Forum :-) I thought I'd ask my question here, too...

I'm continuing to explore the QL network across a range of platforms - now with my refurbished QXL2 card (thanks, Derek!)

The bit-timings on the QXL under SMSQ/E v3.33 (and also on v2.76) prove to be slightly-out from the nominal 11.2us, resulting in failed/unreliable comms with both my Iss7 QL and my prototype QNET to USB adapter (still a work in progress.)

Given that the timings-constants for the NET device are exposed under SMSQ/E and stored ready for adjustment in the DDB of the NET device, I'm trying to find the base address of the DDB from SBasic.

Any help appreciated!

The original post appears here, with pictures :-)



QL-Users Mailing List
QL-Users Mailing List

QL-Users Mailing List

QL-Users Mailing List

Reply via email to