07:17 <tnt> Heh ... interesting, I have this 93c66 eeprom that returns different content if I read it at 2 kHz or 100 kHz ... (1 bit is flipped)

07:17 <tnt> (2 kHz is the bad response)

07:17 <whitequark> free copy protection feature

07:18 <tnt> hehe :)

07:18 <tnt> I'm kind of wondering what failure mode that is ...

07:19 <whitequark> yeah, same

07:22 <tnt> Some marginal charge on the storage cell that cause the read to be 'unstable' maybe ?

07:23 <whitequark> maybe

07:50 <tnt> Whatever it was, rewriting the cell fixed it ...

10:29 <electronic_eel> tnt: the checksum algo is from some old hp equipment?

10:30 <electronic_eel> you might get some answers on the hp/ag/keysight equipment mailinglist

10:30 <electronic_eel> https://groups.io/g/HP-Agilent-Keysight-equipment/

10:39 <owo> eev🅱log forums might be another good place to ask

11:13 <tnt> Thanks for the tups, but, the instrument is fixed now. So I'll leave it at that.

13:56 <sorear> that rules out a lot of things

14:52 <_whitenotifier-3> [Glasgow] smunaut opened issue #144: Microwire and 93xx EEPROM support - https://git.io/fjiGd

15:55 <tnt> ok, turns out it's just a 2's complement sum so that the total sum of all 16bits word is 0. But you need to do an endian swap on each 16-bit words you get from the EEPROM ... (you get them as a 16-bit value out of the EEPROM).

16:36 <sorear> If it’s 16 bits wide, how does it have an endian

16:36 <tnt> I guess they decided to swap the bytes for ... whatever reason ?

16:38 <tnt> They do use it to store strings and to get the string in the "right order" you have to take the LSBs first.

16:50 <sorear> Do you just mean the pinout is mislabeled and D0 is actually D8?

16:50 <tnt> sorear: it's a serial EEPROM