Ethernec drivers & NetUSBee on TT: I think I see the problem.

News,announcements,programming,fixes,game patches & discussions.

Moderator: Petari

stephen_usher
Posts: 118
Joined: Mon Nov 13, 2017 7:19 pm
Location: Oxford, UK.
Contact:

Ethernec drivers & NetUSBee on TT: I think I see the problem.

Post by stephen_usher » 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. :-/

User avatar
arf
Posts: 57
Joined: Sun Oct 29, 2017 9:30 am

Re: Ethernec drivers & NetUSBee on TT: I think I see the problem.

Post by arf » Sat Apr 21, 2018 12:54 am

PureC as a fully compatible replacement of TurboC is available online, including the assembler.
--
Against signature spam!

Petari
Posts: 452
Joined: Tue Nov 28, 2017 1:32 pm

Re: Ethernec drivers & NetUSBee on TT: I think I see the problem.

Post by Petari » Sat Apr 21, 2018 1:35 am

'Write by reading' is necessary in case of Atari cartridge port. Which normally allows not write. So, some tricks are used to make possible write. For instance reading some area will write part of address as data.
There is 2 kind of people: one thinking about moving to Mars after here becomes too bad, the others thinking about how to keep this planet habitable.

Steve
Posts: 132
Joined: Fri Sep 15, 2017 11:49 am

Re: Ethernec drivers & NetUSBee on TT: I think I see the problem.

Post by Steve » Sat Apr 21, 2018 4:07 am

that's weird, my netusbee has no issues with my TT. Its always connected to irc and ftp without problems.

Steve
Posts: 132
Joined: Fri Sep 15, 2017 11:49 am

Re: Ethernec drivers & NetUSBee on TT: I think I see the problem.

Post by Steve » Sat Apr 21, 2018 4:08 am

Just FYI I use the assemsoft driver not the Dr Richard one.

stephen_usher
Posts: 118
Joined: Mon Nov 13, 2017 7:19 pm
Location: Oxford, UK.
Contact:

Re: Ethernec drivers & NetUSBee on TT: I think I see the problem.

Post by stephen_usher » Sat Apr 21, 2018 12:05 pm

Steve wrote:
Sat Apr 21, 2018 4:08 am
Just FYI I use the assemsoft driver not the Dr Richard one.
OK. I'll take a look at that. It won't help get UIP-Tool working though (I think the author uses the ethernec code internally).

Some TTs work fine with the ethernec driver, some don't. I'm guessing that there may be timing differences between motherboard revisions and it's pot luck if it works with your machine or not. From what I've seen, it's only TTs which have any issues and they are, of course, running double the clock rate of the Falcon.

stephen_usher
Posts: 118
Joined: Mon Nov 13, 2017 7:19 pm
Location: Oxford, UK.
Contact:

Re: Ethernec drivers & NetUSBee on TT: I think I see the problem.

Post by stephen_usher » Sat Apr 21, 2018 12:07 pm

Petari wrote:
Sat Apr 21, 2018 1:35 am
'Write by reading' is necessary in case of Atari cartridge port. Which normally allows not write. So, some tricks are used to make possible write. For instance reading some area will write part of address as data.
I see. Basically using a hardware bug/feature to get something working. :-)

stephen_usher
Posts: 118
Joined: Mon Nov 13, 2017 7:19 pm
Location: Oxford, UK.
Contact:

Re: Ethernec drivers & NetUSBee on TT: I think I see the problem.

Post by stephen_usher » Sat Apr 21, 2018 12:11 pm

arf wrote:
Sat Apr 21, 2018 12:54 am
PureC as a fully compatible replacement of TurboC is available online, including the assembler.
From the comments in the code, it's not a plug-in replacement at the assembler level if you want to link in external assembler routines.

I'm not sure why the developers used Turbo C/Devpac2 and not Pure C/Devpac3 given that it was written in 2000. The 030 version of the driver has to use hex values of the instruction codes as Devpac2 only supports the 68000. Devpac3 would have fixed this as it supports the 030 natively.

stephen_usher
Posts: 118
Joined: Mon Nov 13, 2017 7:19 pm
Location: Oxford, UK.
Contact:

Re: Ethernec drivers & NetUSBee on TT: I think I see the problem.

Post by stephen_usher » Sat Apr 21, 2018 12:17 pm

Steve wrote:
Sat Apr 21, 2018 4:08 am
Just FYI I use the assemsoft driver not the Dr Richard one.
Oh, no STiNG driver, only newer MiNTnet one and no source. I've only MiNT 1.10 installed until I can port my MiNTOS code to a newer kernel. I'm not sure I like the way MiNT changed direction in the late 90s, after Eric Smith left the project. (I wonder how much of my loadavg code is still in there.)

Petari
Posts: 452
Joined: Tue Nov 28, 2017 1:32 pm

Re: Ethernec drivers & NetUSBee on TT: I think I see the problem.

Post by Petari » Sat Apr 21, 2018 12:19 pm

stephen_usher wrote:
Sat Apr 21, 2018 12:07 pm
...
I see. Basically using a hardware bug/feature to get something working. :-)
Not exactly. Cartridge port is designed to be read only. Any write command to it's address area will cause bus error. But devices like this must write some parameters out. I designed some 30 years ago EPROM programmer for cartridge port, and of course needed to have write possibility. And used way what probably most used - accessing some address area will not read from (non) existing ROM, but write somewhere what is on address bus. And there are faster ways ..
There is 2 kind of people: one thinking about moving to Mars after here becomes too bad, the others thinking about how to keep this planet habitable.

Post Reply