[En-Nut-Discussion] Recommended compiler?

Harald Kipp harald.kipp at egnite.de
Mon Oct 7 11:31:55 CEST 2002


Austin,

> > The 8019AS has its own internal 16 bit address decoder.
> > So all ATmega address lines are connected and the
> > controller occupies address space 0x8300 to 0x831F only.
> >
>
>         Other implementations I've seen only have the first four addresses
>lines connected. If you can't access the buffer memory, why connect the
>other pins? I'm not trying to be difficult, I'm just trying to understand.
>I've been programming for a bit, but this low level stuff is a little new. :-)

:-) If you're using 4 lines only, the RTL8019 registers
will appear in the whole address space. Either the other
implementation didn't use any other addresses or the
Controller is connected to port pins, not address lines.


>         I have a copy of the 'at/lantic Software Developer's Guide' which I
>think is the right document. It says there's a "shared memory mode" where
>that memory is (appears to be.. haven't actually tried it of course)
>accessible. I couldn't find a specific DP8390 guide, the closest seems to be
>the DP83905 from NS's website. I'm not sure if that's because the
>DP83905 is a specific type of 8390, or because the 83905 is a newer
>version which is backwards compatible. It wasn't clear from the guide.
>
>         Does the 8019AS support this mode? I know it's ne2000 compatible, but
>there are a few realtek-specific extensions. Also, since I don't have the
>specific DP8390 guide, I'm not sure if the original ne2000 supported it.


In any case you have to use the Realtek data sheet.
The 8390 (and 83905) can only be used as a second
source document. It much better explains the NE2000
buffering, but that's it. Specially on error recovery
you can't trust any of these datasheets, but use
a good oscilloscope or logic analyzer with trial and
error programms.

Harald




More information about the En-Nut-Discussion mailing list