HP 3468A owners UNITE: a storm is coming! But together we found the solution!

[Sailor]

I'd like to know how it's driven, it would help me deciphering the code. The cable connecting the display to the main board has 16 conductors. Even disallowing power, ground, unused etc, there are still six signals that are actively driven. They are:  Phi1, phi2 (two clocks), PW0, INA, ISA, and SYNC. The 3468 / 78 manuals are pretty sketchy when it comes to the display. The inference is that data and commands are on two different lines, with a 'Command-framing' signal on the SYNC line. Perhaps the two clocks are used separately for command and data. Some timing waveforms would be nice. And a list of commands. And a segment decode table. and ... you get the idea.

Thanks.

[Deathwish]

Ok,. will get onto that, If I can find anything I will post it here.

[Deathwish]

something here.
http://hparchive.com/hp_PARTS.htm

this looks interesting ( hp parts in general ) including roms.
http://www.sphere.bc.ca/test/hp-parts/hpparts3.html

[free_electron]

a bit of information about this rom ( you may or may not have this bit of information )

this is a SYNCHRONOUS rom !!! meaning you need to toggle the OE for the data to change !!!!

reading the rom
apply address
make OE low : the rom latches in the address
wait a moment
read byte
make OE high
apply next address.

the eprom verson of these things is the motorola 68766 BUT it does NOT have the latches on the address lines.
i do not know if it will work for this machine.

[Sailor]

Thanks, Deathwish. That sphere site looks like a keeper, I've entered it in my website lists.

@free_electron
Yes, we are aware, thanks.

[all_repair]

I have 2 running sets that are used daily, the tool and the skill to desolder.  What is the chip to replace the ROM, and what is the tool to read out the ROM?  (Unlikely my readers can read this chip, I shall check later and report back if I got a positive)

[nuno]

If you have only small portions of corrupted data, a less invasive method could be to connect a logic analyzer capturing all memory accesses on a good unit, luckily you'll eventually capture the data of interest by exercising the device.

[Deathwish]

God my brain is fried, what with reading about having to latch this or that and all the other stuff on these 36xxx devices !. anyway, apart from the dataman programmers being able to read them these programmers also popped up on my radar.

http://www.elnec.com/device/Mostek/MK36000/

http://www.minato.co.jp/jp/dpexralist/M1883dlist_150429/M1883dev/mostek_dev.htm

[mikeselectricstuff]

If you have only small portions of corrupted data, a less invasive method could be to connect a logic analyzer capturing all memory accesses on a good unit, luckily you'll eventually capture the data of interest by exercising the device.

If it does a checksum you may find it runs through all addresses on startup.

[Sailor]

If you have only small portions of corrupted data, a less invasive method could be to connect a logic analyzer capturing all memory accesses on a good unit, luckily you'll eventually capture the data of interest by exercising the device.

If it does a checksum you may find it runs through all addresses on startup.

Yes, it does, sort-of. The checksum routine only runs through the upper 4k of the ROM. There is no checksum code in the lower 4k, and no way for code executing in the upper 4k to simultaneously read data from the lower 4k - well, no way that I know of, given my understanding of the 8039. Granted, it was a long time ago (nearly 40 years), but I did write a fair amount of 8038 - 8048 assembler for some laboratory equipment that I designed. That said, however, the SA1 test routine claims to check the ROM, yet it is constrained by the setting of switch S501-6 (which grounds P14 (address<12>)) to only execute in the lower 4k

[Sailor]

@all_repair
Thank you for your generous offer. Unfortunately we don't have a turn-key solution at the moment (Kjelt, MarkL, et al, please double-check me on this), as I believe the others are still searching for a commercial programmer that is qualified to read the Mostek 36000. There are two considerations that must be kept in mind, firstly, that the Mostek device has only 24 pins, whereas most other 8KB devices are in 28-pin packages. Making an adapter is simple, and has been done by Kjelt. The second consideration is that the Mostek device latches the address inputs on the falling edge of /CE, which is also used to enable its output buffers. This means that /CE must be cycled back 'high' and then 'low' with new address values in order to read successive locations. It is possible, perhaps even likely, that programmers would cycle the chip-select, output-enable, etc when reading a device, but it probably isn't something that is specified. It may, or may not, be relevant to note that Kjelt was unable to get anything other than 0xff from his ROM when using the adapter. It may be simply because his ROM is completely dead, or it may be related to the access protocol of the programmer he used. I have successfully read my ROM in-situ by replacing the 8039 micro with an Arduino hookup, described elsewhere. Of course, it would be simple enough to make an adapter board that accepted the de-soldered ROM and which plugged directly into an Arduino.

So, reading the ROM isn't a two-minute job, at least not at the moment.

Now, about the replacement device for the ROM. We have blithely assumed that we would use an MCM68764 or MCM68766 EPROM, because it is directly pin-compatible with the MK36000, and there are undoubtedly a number of programmers around that will handle those devices e.g. an old Sunshine EXPRO-60 of mine has them listed.

However,

Kjelt, MarkL, and anyone else reading this / contemplating replacing their ROM, please check my reasoning and understanding of the 8039 in the following paragraph.

I had unconsciously considered the 8039/ROM implementation in the 3468 as (to me, anyway) a standard external memory system using a multiplexed data/address bus, where the lower 8 bits of address need to be latched, and the higher address bits are provided statically from other pins on the microprocessor. The 3468 provides the necessary latch (U504) and address bits <12:8> come from P14 and P2<3:0>, so I didn't see any reason why the non-latching MCM68764/6 shouldn't drop straight in. It was only this evening that I realized there are no timing specs associated with P2<3:0> when it is used to provide the higher-order address bits for external memory access. For those unfamiliar with the 8039 series, P2<3:0> can be used as normal I/O bits, but during external program memory access they will be replaced by address<11:8> for the access, then restored automatically. The exact words from the MCS-48 manual are:

'... the I/O information previously latched will be automatically removed temporarily while address is present then restored when the fetch is complete'

I would like to hope that this means that those address bits will be present right through to the end of the /PSEN signal, which would then mean that there is no problem with us using the MCM68764/6 ROMS which don't latch any of the address lines. However, the fact remains that the MK36000 latches *all* address lines at the leading edge of /PSEN, and so it doesn't care what happens to them after that.

Adding to my concern is that all the example / system block diagrams for 8039 expansions show the use of the Intel 8355/8755 Peripheral_IO/ROMs which latch all address bits, or show generic EPROMs with an address bus latch (width unspecified).

It should be noted that in the 3468 the outputs of P2<3:0> are latched (into two separate 4-bit latches) for use driving the keypad and the display, although I am not inclined to read too much into that.

Tomorrow I will get the scope hooked up and see if I can resolve it. But until I do, it may be prudent to wait until there is a definitive answer.


As a further thought, it might be worth foregoing the convenience of the MCM pin-compatability, and use a more modern/common EPROM which will also run cooler (the MCMs draw 85mA, vs ~20mA for a 27C64A). The necessary adapter could also carry a high-order address latch, if it turns out to be necessary.

[amyk]

I've just opened up another bad Mk36000 from a repaired HP 3456A that I had in my parts box. Couldn't find bad wire bondings in this one (but also no obvious other faults like melted discharge spots), so this theory might be wrong. But I have opened chips from similar generation (broken HP-8165A VCA output amp), where the bonding wires just could be wiped from the surface of the chip.

Any idea what storage method is used in this one? Always thought they were mask programmed, but these storage cells don't look much like that (look quite regular to me), more like diode anti fuse?

A clear, focused image of the ROM area itself would help identify exactly what type of mask ROM it is (and could give hints as to the failure mode); there are several types and not all of them have visible bits:

https://siliconpr0n.org/wiki/doku.php?id=rom:mask

[Deathwish]

at the risk of adding nothing more new or unknown, I spotted this in a longer convo than i found before. I have attached the convo and << the bit I found of interest and might be of use.

I tried to read the MK36xxx's as a MCM68766 on my Data I/O 29B, but it did not
work. I guess the Data I/O does not strobe the /CE pin between addresses.

All the data was a duplicate of the first location. The latch had "latched". <<<<<<<<<<<<<<<

I guess I will still need to use the adapter (it's already built). Some
programmers may be able to read them if they strobe the /CE line. It's hit or
miss, I guess.

I am on my way to pick up a bunch of `766's, and I will let you all know if they
work in the instruments. I do not think there should be a problem.

Thanks for the tip. You were right!

Cheers,
Paul Grohe

[Deathwish]

Kjelt. I have had a reply from Walter in the states, he wants to know if the ROM you have is socketed ?. Can you confirm it is or not.

to me
Garry,

by any miracle, is it socketed in the instrument?

w.

Walter Shawlee 2, President
Sphere Research Corporation

[MarkL]

Sailor:

Here's at least one commercial programmer that can read MK36000:

  http://www.elnec.com/sw/dev_html/mostek_dev.htm

But given this only needs to be a one-time shot, it's not terribly difficult to do it on a Arduino, like you have, either in or out of circuit.  And use a scope to make sure all the MK36000 min/max timing requirements are met.


I think your concern about P2<3:0> staying valid through the end of the instruction fetch is well founded.  I couldn't find any information either on the timing of /PSEN with respect to P2<3:0> specifically for the read of the instruction byte on the bus.  I was assuming it works the way you would want it (which is not a good engineering principle).

I've attached the Fujitsu 8039 datasheet which has a timing diagram on 2-40 which says P2<3:0> is held until /PSEN goes high.  There's also a block diagram on 2-36 that shows an address latch only being used on DB<7:0>, and P2<3:0> flowing through to what is labeled "Expansion ROM".  Both of these would imply it's ok to do it without a latch.

Of course, there's nothing better than actually looking with a scope.

If it turns out a latch is needed, that dictates use of an adapter anyway, so I would try to use a 28-pin 87C64 which has an integral latch.

BTW: The MCM68766 draws a continuous 85mA max, while the MCM68764 has a 20mA standby mode.  That's the only difference I could find between the two.  But what's a few milliamps on this power-hungry old gear anyway.


All: Anyone trying to read a MK36000 could try reading it as a 87C64, with of course a pin-mapping adapter.  This will force the programmer to properly sequence the /CE and address lines for the integral latch.


(Seems that we're reliving the other thread a bit here...  But the extra help and attention is appreciated!)


EDIT: Fixed typo.

[Kjelt]

Kjelt. I have had a reply from Walter in the states, he wants to know if the ROM you have is socketed ?. Can you confirm it is or not.

No it is soldered to the PCB but can be desoldered as I did. So my ROM is now outside the instrument.
Concerning a socket, there is unfortunately not enough room for a socket since the plastick extension to operate the powerswitch is directly above it.

[Kjelt]

Kjelt, MarkL, and anyone else reading this / contemplating replacing their ROM, please check my reasoning and understanding of the 8039 in the following paragraph.

I share your concern and think it might be valid. I also think that this will be step2 and that there will always be a solution for this step.
Step 1 is getting the original ROM contents which is the biggest challenge.
Step 2 is replacing the original ROM with a replacement IC or even a new smd PCB with a modern small cpld/fpga or microcontroller that simulates the original ROM.

The ROM is 350ns that is less than 3MHz, surely we have something in 2015 that can replicate a ROM from the 70's ?

[iDevice]

I have restored a few T&M devices with Mostek MK36k ROMs in the last few years, notably 3 Tek 468.
I didn't remember having had any trouble reading them nor programming replacement EPROMs.

Granted, at first, I didn't need to read them as the files were available on the net.
So I just had to make 28>24 adapters and program 27C64 with the files.

At some point I bought a 468 which was defective but still booting, meaning working roms and even if I had the files, I was too curious not to try to read and compare them to the downloaded files, just for fun, so I made a 24>28 adapter and read them without any problem.

So when reading this thread, I didn't understand the difficulty some of you experienced trying to read.
But about an hour ago I remembered that at that time I used my old Hi-Lo GANG-08 programmer.
So I was wondering if the programmer really could make the difference.

A few minutes ago, I pulled my MiniPro from the drawer, found my adapter and some MK36k I didn't trash and tried to read them as INTEL 2764A and succeeded without any problem.

So I guess if someone encounters some difficulty, it should come from the adapter or procedure.

That said, my 3468B is still working perfectly and I didn't know it was one of those dreaded Mostek again, so I guess I'm in the same boat now...
I teared it down a long time ago, so someone can tell me if there is enough room to allow an support + adapter stack ?

[Kjelt]

So I guess if someone encounters some difficulty, it should come from the adapter or procedure.

That is me, I only get 0xFF from all adresses with a Batronix 40-II which reads a 2764A and 87C64 without problem. So I am now almost sure it is totally dead (the ROM that is).

That said, my 3468B is still working perfectly and I didn't know it was one of those dreaded Mostek again, so I guess I'm in the same boat now...
I teared it down a long time ago, so someone can tell me if there is enough room to allow an support + adapter stack ?

Not much room above U502, the plastick mains power extension bar runs over it. Ofcourse for debugging etc. you can remove it but for permanent solution not much room.
If you however desolder the ROM you could use a flatband cable to bring an adapter board to the side.

[iDevice]

Kjelt. I have had a reply from Walter in the states, he wants to know if the ROM you have is socketed ?. Can you confirm it is or not.

No it is soldered to the PCB but can be desoldered as I did. So my ROM is now outside the instrument.
Concerning a socket, there is unfortunately not enough room for a socket since the plastick extension to operate the powerswitch is directly above it.

Ok, I found some pictures here and indeed the plastic extender is an issue.
As I have no time to disassemble mine right now, could you check how much clearance there is between the rom and the plastic thingy ?
I was thinking about some sidecar assembly or two of those old DIP24 flat cable connectors and a short run of flat cable to move the rom to the side.
I don't think the added wire length would be a concern in such low speed environment.

[MarkL]

I said:

I think your concern about P2<3:0> staying valid through the end of the instruction fetch is well founded.  I couldn't find any information either on the timing of /PSEN with respect to P2<3:0> specifically for the read of the instruction byte on the bus.  I was assuming it works the way you would want it (which is not a good engineering principle).

I've attached the Fujitsu 8039 datasheet which has a timing diagram on 2-40 which says P2<3:0> is held until /PSEN goes high.  There's also a block diagram on 2-36 that shows an address latch only being used on DB<7:0>, and P2<3:0> flowing through to what is labeled "Expansion ROM".  Both of these would imply it's ok to do it without a latch.
...

Ok, brain loses another race versus keyboard...

Again on the Fujitsu datasheet, on the previous page 2-39, it shows the relationship between /PSEN and the data bus when reading the instruction byte.  Looking at just 2-40 you can't conclude it's ok, but it is of course the same /PSEN on 2-39.

So combining these two timing diagrams, it should be fine without a latch.  2-40 shows P2<3:0> being held to PCH during /PSEN low, and 2-39 shows the instruction on DB<7:0> being latched on the rising edge of /PSEN.

[Kjelt]

As I have no time to disassemble mine right now, could you check how much clearance there is between the rom and the plastic thingy ?

I have to assemble mine again since it is fully disassembled    Will try to make some time somewhere this week.

[Sailor]

Ok, brain loses another race versus keyboard...

Again on the Fujitsu datasheet, on the previous page 2-39, it shows the relationship between /PSEN and the data bus when reading the instruction byte.  Looking at just 2-40 you can't conclude it's ok, but it is of course the same /PSEN on 2-39.

So combining these two timing diagrams, it should be fine without a latch.  2-40 shows P2<3:0> being held to PCH during /PSEN low, and 2-39 shows the instruction on DB<7:0> being latched on the rising edge of /PSEN.

Thanks for the Fujitsu spec, I only had the Intel and the Toshiba sheets. The Fujitsu is more comprehensively spec'd, and I believe that you're right - it *should* be ok, if you read between the lines . It's just that the min and max values on a couple of the specs don't actually tie it down. In any case, I'll be looking at it today.

The ROM is 350ns that is less than 3MHz, surely we have something in 2015 that can replicate a ROM from the 70's ?

The reason that I was looking so closely at the P2 timing last night was because I'm working on getting my Arduino to act as a memory server i.e. I will disable the 3468 ROM (with a jumper on /PSEN as per SA0) and have the Arduino respond  in its place. I intend this to run in real-time, but the anti-metastable synchronizers on the Atmega input pins makes the timing of the address latching a bit tight. If we're right about the P2<3:0> timing being held throughout /PSEN, then it makes life a lot easier.

(Seems that we're reliving the other thread a bit here...  But the extra help and attention is appreciated!)

Absolutely! The new voices have been most welcome 

[MarkL]

There's another good write-up on the MK36xxx and substitution strategies on the BAMA site.  Seems that the 3456A uses these Mostek ROMs too.

  http://bama.edebris.com/manuals/hp/3456a/


I have a 3456A but at least the contents are available.  Tick... tick... tick...

[all_repair]

Give me a day or few, or stop me if an image is found.  I shall read mine out as 2764 format and try it out before I post the captured.  Please be patient with me, you guys are too fast for me.
-----
After hooking up an MK36000t-2764 adapter , I found the U-502 was too big for the 24pin socket, and it was a 28pin chip.  The version I have turn up to be a NS27C64, eprom dated: 9313A.  Top numbering (maybe a part number) is 03468-65501.

Attached are the readout by a minipro  v6.1 TL866 programmer. checksum 0x0010 28c8