[time-nuts] HP 59309A Clock runs, sets via GPIB, but no GPIB output?

Francesco Messineo francesco.messineo at gmail.com
Mon Oct 10 03:20:31 EDT 2016

I have a dump of the 1818-2295A somewhere, it should be archived in
one of my backups. I also made a replacement with a board having 2 x
28C64 SO-28 eeproms and it worked in my 59309A as far as I could test
it. However these eeproms present many glitches on the outputs during
address toggling, so it's way better to use a suitable CPLD after
recovering the equations (I'm a bit stuck on this project due to lack
of time...).
If someone needs the dump, just let me know and I'll dig it out.
Frank IZ8DWF

On Mon, Oct 10, 2016 at 5:34 AM, Paul Berger <phb.hfx at gmail.com> wrote:
> Bob,
> I just looked at the clock I am not using and it is 1818-2295A, it is not
> convenient for me to check the other one as it is running and in a place
> where I would have to disconnect it to get it out.   I could dump this ROM
> for you but it may take me a few days as I have other things on the go right
> now.
> Paul.
> On 2016-10-09 10:48 PM, Bob wrote:
>> Hi Tom & Paul,
>> Some progress with the HP 59309A clock debug.  Built a ROM reader
>> (Teensy++, a 28 pin WW socket, jumpers) and read out the HP 59309A U2 ROM.
>> Compared the user manual to my readings, found three stuck output bits out
>> of sixteen, and another few dozen assorted differences out of the 4096 ROM
>> bits.
>> Also, while moving U2 to the reader socket I noticed that the chip is
>> stamped 1818-2295A 2335 vs. the schematic which states U2 is a 1818-2193.
>> Perhaps the U2 state machine was updated?
>> The O1 (part of Next Address) bit, O9 (LOAD) bit and O11 (Rout) bit always
>> read 0.  Together those stuck-at-0 bits compose the vast majority of the bit
>> differences.  LOAD being always zero explains why I don't see data written
>> into the RAM when watching with a logic analyzer.
>> I'm 99% sure there is at least some bit rot, in particular there is a long
>> unused block at the end of the Talk Enable = 1 table, where all addresses
>> should match, and in the middle of that range there are just a few wrong
>> bits.
>> A small number of differences exist in other Next Address and Next
>> Qualifier columns, but there are only a few, not easy to tell if they are
>> just changes to the state machine or more bit rot.
>> Digging further, the serial number prefix 2510A is much newer than the
>> 1632A prefix mentioned in the manual I'm looking at, so there could be
>> differences in the schematic.  Not clear if HP change pages up to 2510A
>> exist, I've not found them so far.
>> At this point, I can think of a few paths to take...
>> a) Leave it alone, still works fine as a desk clock, but useless for
>> reading TOD via HP-IB.
>> b) Build a little adapter board and replace U2 with a self-programmed 16
>> bit EPROM or a pair of 8 bit EPROMs.  I could use the code in the manual,
>> buzz out the circuit to validate the schematic, and (if needed) reverse
>> engineer the state machine.
>> Tom and/or Paul, would you consider lifting the cover off your clock (just
>> 2 screws in the back) and peeking at the part number on your U2 chips?
>> That's the 28 pin ceramic ROM in the socket on the A5 board which is the one
>> at the far left looking from the front.  The ROM is at the top of the board
>> and should be visible without touching anything.
>> If someone happens to have a ROM stamped 1818-2295A 2335, it would of
>> course be great to capture the bits, to remove the remaining guesswork in
>> creating a replacement image.  Naturally, I checked the ROMs on Didier's
>> site, but didn't see any for the 59309A.
>> In conclusion, reading the U2 ROM shows three stuck bits, including LOAD,
>> which explains what I saw on the logic analyzer.
>> Cheers,
>> Bob
> _______________________________________________
> time-nuts mailing list -- time-nuts at febo.com
> To unsubscribe, go to
> https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
> and follow the instructions there.

More information about the time-nuts mailing list