[Oberon] Re. MTU, MaxPkt, EthernetFrameSize & etc.

[Chris Glur]

Peter E. wrote:

>Can anyone explain this statement in Net3Com509.Mod?
>
>SYSTEM.PORTOUT(port+14, SYSTEM.VAL(INTEGER, mode+8000H))	(* set rx filter *)

IMO ETH-Oberon's implementstion of 'low-level', ie. regs & ports is
a disgracefull nightmare.  Which is remarkable, given Wirth's 
background in hardware.  

To get some idea of the significance of the '14'

Net3Com509.Mod  shows:
(* RepOut14 - Block port output instruction (14 bytes). *)

	p := port+14; <-- conceptually: port is the 'base' & 14 is the offset
    like an array of 32[? or 16]-bit-words
..
PROCEDURE SetMode*(mode: INTEGER);
..
	SYSTEM.PORTOUT(port+14, SYSTEM.VAL(INTEGER, mode+8000H))	
     (* set rx filter *)
END SetMode;
===========
So, parsing the nested exprn from inside out:
Oberon.Report.Text  > 
"VAL(T, x)	T, x: any type	T	x interpreted as of type T"
  explains the awkward type-matching.

A nice syntax would be:
" mode+8000H  -> Port(port+14)"

I.e. add 8000H to mode and send to Port(port+14) for output.

>From the source text we see that '14' is special for this hardware.
It might have been better if a declared constant had been used 
instead of '14'.

Re. "+8000H" consider the following simplified 4-bit scenario:
registers & ports can be considered as 'sockets with 4 wires,
b3...b0', which can individually be either at 5 Volt or 0 Volt.

The aim is to control/change the voltage on individual wires of 
individual ports.

Typically the multiple ports have consecutive addresses, like an array.
In your example it's the 15th port [14+1] which needs to be changed.
Important, is that the bits of a reg/port can't be written to individually.
So if the present 4 bits are to be changed from: 0101 to 1101, ie. only the 
most significant bit [b3] is to be changed from 0 to 1, the whole new 
word [1101] must first be constructed before being sent to the reg/port.
In your example, the 'word construction' is done by "mode+8000H".
"8000H" represents a binary number with a single "1" bit, presumably
in the position/weighting which is needed to be switched.

|<this is only OK if the previous bit-value was 0, else you can get 
overflow/carry. Normal design is to use logical-OR, which will set the 
bit to 1, whether is was 0 or 1 previously; but ETH-Oberon wants to 
force circuit design into plain-Oberon>|

Example
Bit No.=3,2,1,0
Bit Val=0,1,0,1
Hypothetical Meaning of fields:
B3=Left,Right; B2=Fast,slow; B1,0=red,blu,grn,yellow[00,01,10,11]

So: Left, slow, grn =  0   1   10
   and if you want to change this to: Right, slow, grn,
ie. change only the Left/Right field,
you can [provided you know that the Left/Right field is currently 0]
just add 1000 ie. 8 to the port's current value,
to get from 0110H=6 to 1110H=14.

But if the reg/port was already set to 'Left' you crash, if carry/overflow
occurs !!

NB. there's extra confusion because we write from left-to-right, with
the most significant digit first; but we count in increasing order.

BTW 8000H is bit (3 +4 +4 +4=15) Ie. the most significant bit
of a 16-bit word.  I think a lot of the hardware has 16-bit wide
reg/ports. Ie. desgned pre-32-bit days ?

If you suspect the statement:
  SYSTEM.PORTOUT(port+14, SYSTEM.VAL(INTEGER, mode+8000H))	
you could trace port and mode, and see if port+14 gives an address
which is expected. I think the hardware has allocated a consecutive
set of ports for specific jobs. And is the bit which is 'trying to be set'
the one that corresponds to the correct field/function ?
What function of the hardware is switched by bit15 of port(X+14) ?

.etc..

== Chris Glur.