> I found this a while ago.

>> I found a method to reconstruct the hostid and ethernet address from
>> the printed string on the NVRAM label.  [convert from base 36 and
>> subtract 0xaa8c0, then add 0x27b00 for MAC address]

This works for two of the six samples I have at hand - the two with
first hostid byte 0x56.  The rest seem to be different:

(works for)
GMA1 03:a7:09 56012c09
GRH4 03:c1:58 56014658

(doesn't work for)
DLHX 08:ed:07 53000cf3
GK5P 0b:cd:c7 572043c3
RUSJ 0d:5b:8c 57217143
S1YX 0d:88:a9 5721957b

Of course, it's possible the others have been meddled with; they
haven't all been under my control since initial delivery from Sun.

I also wrote

>> I'll also be looking at mine to see if there is an obvious
>> correspondence between barcodes and four-character codes.

There is, and a trivial one at that, at least for my sample (size 13).

The barcode is 77 "units" wide and consists of a fixed pattern at each
end with the four characters each corresponding to a 12-unit block in
the middle.  Using . for blank and - for black, with *s for the 12-unit
variable pieces, the barcode is

-..-.--.--.-.************.************.************.************.-..-.--.--.-
               1st char     2nd char     3rd char     4th char

The character code table, with *s for entries I don't know:

0  ************    9  ************    I  ************    R  --.-.-.--..-
1  --.-..-.-.--    A  --.-.-..-.--    J  -.-.--..--.-    S  -.--.-.--..-
2  -.--..-.-.--    B  -.--.-..-.--    K  --.-.-.-..--    T  ************
3  --.--..-.-.-    C  --.--.-..-.-    L  -.--.-.-..--    U  --..-.-.-.--
4  -.-..--.-.--    D  -.-.--..-.--    M  --.--.-.-..-    V  -..--.-.-.--
5  --.-..--.-.-    E  ************    N  -.-.--.-..--    W  ************
6  -.--..--.-.-    F  -.--.--..-.-    O  -.-..--.--.-    X  -..-.--.-.--
7  -.-..-.--.--    G  -.-.-..--.--    P  -.--.--.-..-    Y  --..-.--.-.-
8  ************    H  --.-.-..--.-    Q  -.-.-.--..--    Z  ************

It's possible that the code I have down for O should be for 0, with O
unknown; I have not seen both 0 and O.

I find the coding scheme somewhat more comprehensible when represented
with one character for a width-1 bar, whether printed or space, and a
pair of another for a width-2 bar.  Using _ for one and xx for two, the
above becomes

0  ************    9  ************    I  ************    R  xx_____xxxx_
1  xx__xx____xx    A  xx____xx__xx    J  ____xxxxxx__    S  __xx___xxxx_
2  __xxxx____xx    B  __xx__xx__xx    K  xx______xxxx    T  ************
3  xx_xxxx_____    C  xx_xx__xx___    L  __xx____xxxx    U  xxxx______xx
4  ___xxxx___xx    D  ____xxxx__xx    M  xx_xx____xx_    V  _xxxx_____xx
5  xx__xxxx____    E  ************    N  ____xx__xxxx    W  ************
6  __xxxxxx____    F  __xx_xxxx___    O  ___xxxx_xx__    X  _xx__xx___xx
7  ___xx__xx_xx    G  _____xxxx_xx    P  __xx_xx__xx_    Y  xxxx__xx____
8  ************    H  xx____xxxx__    Q  ______xxxxxx    Z  ************

I see a provocative resemblance to binary counting, with the LSB at the
left end something akin to a parity bit at the right, but haven't
solidified it into anything algorithmic...but it does look as though
___xxxx_xx__ more likely goes with O than 0.

Three of my samples have the width-1 white bars between characters
slightly wider than other width-1 white bars, to the point where I put
some of them down as width-2 white bars at first.  Especially on the
black-on-white stickers (as opposed to the black-on-orange ones), if
you see a white bar that looks wider than width 1 but not as wide as
width 2, check to see if it's placed so's to be one of the character
separator bars.

/~\ The ASCII				der Mouse
\ / Ribbon Campaign
 X  Against HTML	       mouse@rodents.montreal.qc.ca
/ \ Email!	     7D C8 61 52 5D E7 2D 39  4E F1 31 3E E8 B3 27 4B