Wojtek ben (=byte enable) is TRUE (1) if you want to access a byte and FALSE (0) if it is a word access. When you access your memory chip, you have to convert these boolean/logical values to active low or active high depending on the meaning of the control lines of your chip. For the memory chip used by ProjectOberon, the real memory access looks like this (RISC5Top.v): assign SRce0 = ~(~ben | ~adr[1]); assign SRce1 = ~(~ben | adr[1]); assign SRbe0 = ~(~ben | ~adr[0]); assign SRbe1 = ~(~ben | adr[0]); br Jörg Am 19.12.19, 01:38 schrieb "Oberon im Auftrag von Skulski, Wojciech" <oberon-bounces@lists.inf.ethz.ch im Auftrag von skulski@pas.rochester.edu>: All: trying to decipher the firmware I am now puzzled with the individual byte access logic in RISC5 and RISC5top. For the individual byte access, the processor is outputting "ben" described in PO.Computer page 2 as follows: "ben indicates a byte (rather than word) access". There is no further information in PO.Computer whatsoever. There is no truth table. Using my ingenuity I am guessing "ben" is active LOW because otherwise it would have been named "be". But this is not a strong basis to be sure. Exploring the open source did not bring definite knowledge. Namely, inside RISC5.v "ben" was made wonderfully clear: assign ben = p & ~q & v & ~stallX & ~stall1; // byte enable where both "p" and "q" are clear to everyone: assign p = ins[31]; assign q = ins[30]; where "ins" is obvious to at least some students, as follows: assign ins = PMsel ? pmout : IR; // decoding After exploring all this great information I am not sure whether "ben" is active LOW or HIGH, and where to find the answer. Does anyone know? Thanks! Wojtek -- Oberon@lists.inf.ethz.ch mailing list for ETH Oberon and related systems https://lists.inf.ethz.ch/mailman/listinfo/oberon