Ethernec drivers & NetUSBee on TT: I think I see the problem.
Posted: Fri Apr 20, 2018 11:18 pm
I've been trying to investigate why the Ethernec (ENEC.STX/ENEC3.STX) drivers don't work with my NetUSBee-lite when all the test programs do and I think I may have found the issue, lack of delays before reading the ethernet chip registers.
I've been reading through the source of the Amiga cnet driver to try to work out how the NE-2000 device should be accessed and within the comments is a nice tidbit about having to leave at least 2ms between issuing the request for the data and reading from the chip registers. On the standard Amiga (and hence ST) the processor is often slow enough to not need a delay added but on faster processors it does.
Tellingly, the ethernec NE.S driver source seems to have only one delay in the probe routine on the first read and not for subsequent ones, so I guess that if you happen to have a fast reacting NE-2000 chip in your device, or your TT is fast at reading for some reason, the data won't be ready.
This may explain why the test programs, such as HT2NEC.TOS can read the chip ROM correctly and extract the MAC address but the driver just gets zeros.
I must admit that I'm a bit dubious of the code, especially in BUSENEC.I where there's a macro which uses tst.b with a comment, "write by reading". I have no idea how that might work as it seems tst.b only updates the status register.
Unfortunately I don't have Turbo-C 2.0, though I can get Devpac2, so I can't experiment with building the drivers with delays added. :-/
I've been reading through the source of the Amiga cnet driver to try to work out how the NE-2000 device should be accessed and within the comments is a nice tidbit about having to leave at least 2ms between issuing the request for the data and reading from the chip registers. On the standard Amiga (and hence ST) the processor is often slow enough to not need a delay added but on faster processors it does.
Tellingly, the ethernec NE.S driver source seems to have only one delay in the probe routine on the first read and not for subsequent ones, so I guess that if you happen to have a fast reacting NE-2000 chip in your device, or your TT is fast at reading for some reason, the data won't be ready.
This may explain why the test programs, such as HT2NEC.TOS can read the chip ROM correctly and extract the MAC address but the driver just gets zeros.
I must admit that I'm a bit dubious of the code, especially in BUSENEC.I where there's a macro which uses tst.b with a comment, "write by reading". I have no idea how that might work as it seems tst.b only updates the status register.
Unfortunately I don't have Turbo-C 2.0, though I can get Devpac2, so I can't experiment with building the drivers with delays added. :-/