livingcomputermuseum.Darkstar/D/Notes/Ethernet.txt

The Ethernet hardware is not well documented; no official docs exist.  This is a collection of notes
gleaned from source code and experimentation.


(from EtherInitial.mc)
{The Laws of the Ethernet Hardware:

	-- EICtl¬ and EOCtl¬ can occur in any cycle.  They must occur in c1 or c2  when turning off wakeups.
	-- ¬EIData must occur in c2.  When read in c3, it retrieves the previous input word.
	-- EOData¬ can occur in any cycle.
	-- EStrobe for throwing out input packet must occur in c2.
	-- EStrobe for writing the data from EOData into the FIFO must occur in c1 or c3.
}

Values used for ctl registers

// From EtherBootDLion
Set[Off, 0];                    Both
Set[EnableTransmit, 1];         EOCtl<-
Set[EnableTransmitLastWord, 3]; EOCtl<-
Set[EnableTransmitDefer, 5];    EOCtl<
Set[EnableReceive, 1];          EICtl<-

// From EtherDLion
Set[eEnableRcv, 1];
Set[eTurnOff, 2];
Set[eLocalLoop, 4];
Set[eLoopBack, 8];
Set[eOff, 0];
Set[eEnableTrn, 1];
Set[eLastWord, 2];
Set[eDefer, 4];
Set[eEnableTrnDefer, 5];
Set[eEnableTrnLastWord, 3];

EOCtl<- : Controls output
EICtl<- : Controls input
EStrobe : Loads FIFO

EnableTransmitLastWord : "EOCtl ¬ EnableTransmitLastWord tells the hardware that no more words will 
    be placed into the FIFO, and must occur in c1 or c2.  Wakeups will not occur again until the 
    FIFO has been emptied onto the Ethernet."




Input:
------

{As each word of the packet is inputted, we check the Attention bit.  Attention in this case indicates 
timeout or the end of the packet has been received.  Since the normal exit to the receive loop is for 
the length to count down to zero, an Attention is an abnormal occurrence.  If it has been set, we throw 
out the rest of the packet by doing an EStrobe.  This EStrobe must occur in c2.}

"<-EIData not in Cycle2 is rereading EIData in the case of a uCode PageCross."


Output:
-------

EStrobe: Must be in c1 or c3.  Moves data from EOData<- to fifo. 

Loopback:
---------
If loopback is specified, the fifo output is not cleared and will be read by <-EIData


Status             Bit (in Xerox order)
--------------------------------
TurnOff'        :  15
R. EvenLen      :  14
R. GoodCRC      :  13
R. Overrun'     :  12
R. GoodAlign    :  11
T. Underrun'    :  10
T. Collision'   :  9
RcvMode'        :  8
EnableTrn       :  7
LastWord        :  6
EnableRcv       :  5
LocalLoop       :  4
Loopback        :  3
DiagVideoData   :  2
VideoClock      :  1
DiagLineSync    :  0


EICtl:             Bit (xerox order)
------------------------------------
EnableRcv          15
TurnOff'           14
LocalLoop          13
LoopBack           12


EOCtl:             Bit (etc)
----------------------------
EnableTrn          15
LastWord           14
Defer              13


EtherDisp (aka YIODisp)
-----------------------
Pin 139 (YIODisp.1) : Hooked to "Attn," which appear to be whether any attention is needed by the receiver or transmitter.
Pin 39 (YIODisp.0) : "(schematic) Must be zero for the transmitting inner loop uCode.  It is also used to determine if the 
                      Option card is plugged in."



Transmission:
-------------

When EnableTrn is set, the microcode appears to:
- Send 4 words of preamble bits (0x5555x3, 0x55d5 x1) which are strobed in as usual
    - From schematic "Last 2 1-bits of Preamble indicate 'PreamDet', Last 2 0-bits of Preamble indicate 'IgnorePacket'.  Bits received least bit first."  
     (Standard preamble + SFD.)
    - Does FIFO enqueue these, or do they get sent directly?  (looks like they get enqueued like everything else)
- Send data for the packet (strobed in).  This appears to include the header + CRC
    - Assumption: Ether task must be put to sleep when FIFO is full, awoken when space is available -- how does this work?
        - See schematic, pg 2; ethernet requests (wakeups) generated by:
            TxMode & BufIR & Defer' & LastWord' (i.e. transmit on, fifo buffer not full, not deferring, not the last word)
                OR
            Defer & TickElapsed (microcode asked for the transmission to be deferred, and that deferral time has elapsed)
                OR
            RcvMode & BufOR & Purge' (i.e. rcv on, fifo data ready, not purging fifo)
                OR
            Attn    (i.e. hardware has a a status to report)
- For last word, LastWord is set -- this tells the hw that no more words are to be put into the FIFO; wakeups are removed until the
  remainder of the FIFO has been transmitted.


Receiving:
----------



- How does loopback function?
    - LoopBack signal Appears to avoid clearing the fifo when rcv mode is enabled (see pg. 6 of schematics) 
    - LocalLoop causes transmitter output to be fed into receiver input, this then goes back into the FIFO...
      Also stops transmission start by preventing IPG from being generated (end of which starts xmit machine)
- What does Defer do?
    - Causes a wakeup after a delay; 
      DeferCount timer is reset when EOCtl is loaded in c1 or c2, TickElapsed goes high after 51.2uS.  
    - Inter-Packet Gap (start of next packet?) is started only after Defer has completed
- What raises "Purge"
    - Looks like an EStrobe in C2.

- How are odd-length packets denoted by the microcode?
    - Early (?) schematic has an OddLength bit in EOCtl, this is not present in the later (?) schematic.

- When are CRCs generated?
    - Based on notes in the schematic, it looks like EndWithCRC is set on the last byte if loopback is not enabled.
    - If loopback is enabled, it appears that the CRC is generated by the software-side and is strobed in with the rest of the data,
      diagnostic code seems to bear this out.