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!
Stand-by!
M.
On 19/05/2018 13:48, Wolf via Ql-Users wrote:
Hi,
This is what you can find in the NET driver i/o code:
nd_io
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.
HTH
Wolfgang
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!
Martyn.
On 19/05/2018 09:41, Wolf via Ql-Users wrote:
Hi,
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.
HTH
Wolfgang
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 :-)
https://qlforum.co.uk/viewtopic.php?f=3&t=2462
Regards,
Martyn.
_______________________________________________
QL-Users Mailing List
_______________________________________________
QL-Users Mailing List
_______________________________________________
QL-Users Mailing List
--
"There are 10 types of people in this world. Those who understand binary and those
who don't."
_______________________________________________
QL-Users Mailing List