Author Topic: HP 3468A in continual reset/init?  (Read 18128 times)

0 Members and 1 Guest are viewing this topic.

Offline SailorTopic starter

  • Regular Contributor
  • *
  • Posts: 170
HP 3468A in continual reset/init?
« on: April 12, 2014, 07:48:46 am »
My HP 3468A that I bought in 1983 finally died a few months ago - sort of. It looks like it is in a continual initialization loop, every segment and every annunciator is lit, and blinks about once per second. At the time I had a quick look at the supplies (don't you just love the old days, a *complete* manual with every piece of equipment :-+) and all was ok, so I just put it aside. Even now, I don't plan on rushing into it, but I saw it sitting in the cupboard the other day so I thought I'd ask if there is a common cause, or if anyone has had this symptom before. The manual uses Signature Analyzer numbers for trouble-shooting, and guess what I don't have...
 

Offline SailorTopic starter

  • Regular Contributor
  • *
  • Posts: 170
Re: HP 3468A in continual reset/init?
« Reply #1 on: May 07, 2015, 08:50:44 am »
I've just got back to look at this, and my first thoughts are RomRot of the Mostek 36K control ROM. I've taken a dump of mine and I am hoping that someone else might have done the same at some time and I could compare them. One of the possible self-test errors implies that it checks the ROM, but whether it's a checksum (8?16?32) or a CRC (16?32), and whether it would be a single value over the whole 8K, or two checks of 4K, or even 4 checks of 2K (because the 'Memory Bank' segments are 2K in size), is all unknown. I can put together a program to compute those possibilities, but there is still guesswork involved, and a non-match wouldn't be definitive. Of course, a proper match would :)

I've hooked up my TLA715 and taken some state and timing files, but the first thing that comes out of those is that it's not stuck in a small loop anywhere - it's executing *huge* amounts of code until the hardware timer hits the RESET again (a simple 20-bit count of ALE pulses without being zero'd by keypad scanning operations).

I've run my dump through the D48.exe disassembler, but there are a couple of issues with that - one being that it naturally doesn't know about the way the 3468A handles an 8KB ROM. I'm not even sure myself how HP would have written the code.

Lots to learn. If anyone does have a ROM image, I'd appreciate a copy. All comments welcome.

Sailor
 

Offline dom0

  • Super Contributor
  • ***
  • Posts: 1483
  • Country: 00
Re: HP 3468A in continual reset/init?
« Reply #2 on: May 07, 2015, 09:37:57 am »
Is the ROM in yours socketed? I don't think any of the ICs in mine is socketed, only the input hybrid circuit is.

You'll also want to check the floating circuitry, I know mine goes into general reset if the A/D controller hangs.
« Last Edit: May 07, 2015, 09:39:37 am by dom0 »
,
 

Offline SailorTopic starter

  • Regular Contributor
  • *
  • Posts: 170
Re: HP 3468A in continual reset/init?
« Reply #3 on: May 07, 2015, 10:59:15 am »
No, it's soldered in. I didn't want to disturb it, so I pulled the 8039 ($1.95 from Jameco) and put a socket in for that. Then I lashed up an AVR mega (an Arduino) to that socket and had it read the ROM and output IntelHex records.

That's interesting about the ADC putting it into reset - I guess it's the same timeout mechanism. But I would hope in my case that it could have output something to the display if it found a fault, 'cause that's the purpose of a self-test after all :P

I've just been reading the manual (again, for the umteenth time!) and it does use the word checksum in the ROM error paragraph. It's not definitive, because I've seen a lot of technical writers use the word 'checksum' wrongly, probably because they don't know what a CRC is ::). Still, I'll check that first.
 

Offline SailorTopic starter

  • Regular Contributor
  • *
  • Posts: 170
Re: HP 3468A in continual reset/init?
« Reply #4 on: May 24, 2015, 09:29:07 am »
A bit of an update:
I fixed a slight problem with the D48 disassembler and now have code listings of the upper and lower 4k sections of the control ROM. I then started tracking (in the listings) execution from the time /RESET is released. That was tedious enough, but combined with the programmatically controlled hardware switching between the upper and lower 4k memory blocks (not to be confused with the 8039 internal Bank0 and Bank1 code switching, which also comes into play) it gets old very fast :(

I have now made an adapter/8039 that I can control from the Arduino so that I can single-step the 3468A, and that is working as of a few minutes ago. I will expand the commands so that it can do a few extra things like STEP_n instructions, STEP_UNTIL_<address>, set address breakpoints, etc. I should get some of that working tomorrow.

Coming at the ROM checksum identification from another angle (after I had gotten up to speed on the instruction set) it became apparent that it is not easy (or not as easy as it is on a modern micro) for an 8039 to compute/perform a checksum on an 8k ROM. and that it would have to make use of a specific instruction as part of such a routine, and that there would need to be certain supporting constructs throughout memory. It probably took less than an hour of examining the dumps before I was able to identify what I believe to be the ROM checking routine. In one of those quirks of life, the entry into that routine turns out to be approx another 20 instructions further on from where I stopped my manual decoding ::), although I'm not sure that I would have recognized it for what is was, at the time.

I'm quitting for now (the Monaco Formula 1 race is on soon :))

If there is anyone else (besides Kjelt, who I've PM'd a couple of times) who has a broken 3468 and would like to follow or participate, please let me know.

 

Offline MarkL

  • Supporter
  • ****
  • Posts: 2120
  • Country: us
Re: HP 3468A in continual reset/init?
« Reply #5 on: May 24, 2015, 09:39:40 pm »
There's a kernel test procedure that you don't really need a signature analyzer to use.  It appears to jam a 0xff onto the data bus which is a single cycle "MOV A,R7", and also disables watchdog counter U504.

The kernel test allows the processor's PC to increment through the full address space.  The ROM may be dead, as you suspect, but you should at least be able to check that the output of address latch U508 is incrementing.

Perhaps you've already done this with the LA, but just thought I'd mention it.

With a problem like this I'd prefer to use a scope to check for indeterminate logic levels.
 

Offline SailorTopic starter

  • Regular Contributor
  • *
  • Posts: 170
Re: HP 3468A in continual reset/init?
« Reply #6 on: May 25, 2015, 12:04:32 am »
Yeah, I'm well past those sorts of things now, thanks Mark. Apart from all my initial work with the scope when I verified that all signals on the data, address, and ports were moving ok, nothing stuck, and all levels good, I then drove the system with my Arduino/Atmega2560 i.e. with the 8039 removed. The ROM contents disassemble into 8k of what appears to be rational code, although it only takes one bad bit in the wrong place to screw everything.

There is some rational operation occurring, though. For example, the display is set to the correct configuration (all segments, annunciators, etc ON, except the top dots), and then, approximately 35msec after the release of /RESET there is a single scan of the keyboard, after which the CPU continues with whatever it is that prevents any further KB scanning, with the end result being the timeout/reset by U504.

But here's the thing - if I initiate a reset (e.g. by momentarily grounding the /RESET line) while holding one of the KB buttons depressed, the single scan of the KB turns into a never-ending sequence of scans (separated by ~ 600usec) that will continue as long as I hold the button down. U504 naturally doesn't time out, and the CPU is obviously detecting the 'stuck button' situation. So it's not totally brain-dead.

The saga continues...
 

Offline MarkL

  • Supporter
  • ****
  • Posts: 2120
  • Country: us
Re: HP 3468A in continual reset/init?
« Reply #7 on: May 25, 2015, 01:30:53 am »
It seems that you like a good challenge.  If you're really into it, you could use the TLA to capture a state analysis of the pins on U502 after putting the unit in SA1, as described in section 7-D-26.

Then from the capture you could compute on a per pin basis what a signature analyzer would display.  The signature analyzer algorithm is described in HP Journal, May 1977:

  http://www.hparchive.com/hp_journals.htm

That would at least answer the question about the ROM, and now you have a signature analyzer to dig further if necessary.


And of course there's always the lazier way of picking up a used 5004A or 5006A.  They can be had for around USD$75.
 

Offline SailorTopic starter

  • Regular Contributor
  • *
  • Posts: 170
Re: HP 3468A in continual reset/init?
« Reply #8 on: May 25, 2015, 03:26:55 am »
Thanks for that reference, in the past I've briefly (VERY briefly) considered duplicating, simulating, or otherwise deriving some benefit from the SA tests, but not knowing exactly how the SA functions, whether it both drives and senses signals, what sequences it uses, etc etc, I have never pursued the idea. I'll read that, in conjunction with one of the SA manuals (can you tell me the difference between the 5004 and 5006?) and see what I can piece together.

There are a couple of things about the SA0 and SA1 tests that I'm confused about - maybe you can help:

(...delete about a half-hour of writing here...)

Errrr, no. After labouring over my questions for quite a while and writing a page of questions, during which I had to think really hard about the way the tests worked and what they were measuring, I worked out my own answers. I really must thank you Mark, forcing me to think it through so thoroughly has been a great help.

Given that I already have a dump of the ROM, I should be able to lash up a simple Matlab script to process the file and derive the signatures - I think. And the SA0 signatures should just be the values from the bits of a binary count pattern (I think), which I can duplicate in Matlab, thereby validating my script.

But there is still the question about the difference(s) between the 5004 and 5006 - if you know.

Thanks again,


And of course there's always the lazier way of picking up a used 5004A or 5006A.  They can be had for around USD$75.


No no no, that would be cheating :)
 

Offline MarkL

  • Supporter
  • ****
  • Posts: 2120
  • Country: us
Re: HP 3468A in continual reset/init?
« Reply #9 on: May 25, 2015, 02:10:00 pm »
Given that I already have a dump of the ROM, I should be able to lash up a simple Matlab script to process the file and derive the signatures - I think. And the SA0 signatures should just be the values from the bits of a binary count pattern (I think), which I can duplicate in Matlab, thereby validating my script.
I agree on the SA0 values.  It should be a good validation.

But I don't think it's as simple as computing the CRC (that's really what the SA is doing) across all the bits in the ROM dump you have.  Whereas SA0 disables the ROM, SA1 re-enables the ROM and holds processor pin 31 (P14) low.

My guess is that the processor samples P14 at boot and, if low, goes into a loop where it reads all the locations in ROM, and probably pokes at all the other places described in table 7-D-4.

So, the ROM contents are jumbled in the with CRC of the program running and all the other probing going on in the SA1 loop.  Since you've disassembled the code maybe you can spot this loop.

I guess, in theory, you could actually do a software re-creation of the 8039 and compute the CRC of the ROM accesses, but wow... Now that's a lot of work.  The more sane approach would be to capture a state analysis on the ROM, clocked by /CE and delimited by JM503 going low and then high.  Then run that through Matlab.

Quote
But there is still the question about the difference(s) between the 5004 and 5006 - if you know.
The 5006A allows a faster clock (25MHz vs. 10MHz), and also has a qualifier input.  I don't recall ever seeing a qualifier in any HP test procedure, so it's probably if you wanted to develop your own in house SA procedures for your own products.  The 5006A also GPIB, but I think that's a weird thing to have on a piece of equipment that's almost exclusively designed for interactive use.

But the shorter answer is: For troubleshooting this old HP gear they both do the same thing.


Quote
And of course there's always the lazier way of picking up a used 5004A or 5006A.  They can be had for around USD$75.

No no no, that would be cheating :)
I thought the easy way might not be appealing to you!


EDIT: Fixed html quote.
« Last Edit: May 25, 2015, 03:24:13 pm by MarkL »
 

Offline Kjelt

  • Super Contributor
  • ***
  • Posts: 6459
  • Country: nl
Re: HP 3468A in continual reset/init?
« Reply #10 on: May 25, 2015, 03:42:27 pm »
If there is anyone else (besides Kjelt, who I've PM'd a couple of times) who has a broken 3468 and would like to follow or participate, please let me know.
my update: you have an email. Not good news I am afraid.  :(

I finally had some time today to desolder the HP ROM and make a transfer pcb to an Intel 2764A.
You can see the details in the picture. I connected the /CE of the intel to the /CE of the ROM (intel has /CE and /OE , the ROM only /CE).
Unfortunately this results in only 0xFF return values over the entire 8kB.
So next attempt from me was to connect the /OE of the intel to the /CE of the ROM, same result: only 0xFF  :(  I am very dissapointed as you probably are to.
 
Maybe I should try a different chip, anyone a better candidate then the 2764A ( I have a batronix BX40 Bagero II programmer so can read everything in this list: http://www.batronix.com/pdf/BX40Bagero-II-DeviceList.pdf )

Or should I perhaps use an OR gate to multiplex both /OE and /CE of the Intel to the /CE of the ROM?

Another even worse explanation can be that my ROM is really dead (broken).
 

Offline MarkL

  • Supporter
  • ****
  • Posts: 2120
  • Country: us
Re: HP 3468A in continual reset/init?
« Reply #11 on: May 25, 2015, 04:36:40 pm »
...
Maybe I should try a different chip, anyone a better candidate then the 2764A ( I have a batronix BX40 Bagero II programmer so can read everything in this list: http://www.batronix.com/pdf/BX40Bagero-II-DeviceList.pdf )
...
You might want to try reading the MK3600 as an 87C64.

The MK3600 latches the address lines on /CE going low.  The 2764 does not do latching and just outputs whatever is on the address inputs after a lookup delay.

So, the Batronix may set /CE low and *then* set the address pins which wouldn't matter on a 2764, but would cause erroneous data to be read on the MK3600.

It's a possible explanation.  It doesn't seem likely you'd get all FF's, but it's possible depending on exactly how the Batronix is controlling the address and /CE pins.

The 87C64 is another type of latching EPROM, so the Batronix should order the changing of address and /CE pins appropriately.
 

Offline Kjelt

  • Super Contributor
  • ***
  • Posts: 6459
  • Country: nl
Re: HP 3468A in continual reset/init?
« Reply #12 on: May 25, 2015, 05:04:08 pm »
You might want to try reading the MK3600 as an 87C64.
Thanks good thinking, I just tried but unfortunately the same 0xFF result.
Makes me wonder if the timing is crucial, the MKB can be as slow as 300ns twice as slow as the xxC64 chips. Set it at -35 (350ns) and that doesn't work either.
Perhaps I should do the same as Sailor did, hook it up to a 8 bit microcontroller board and program my own readout sequence. Will take some time though. :(
« Last Edit: May 25, 2015, 05:08:22 pm by Kjelt »
 

Offline MarkL

  • Supporter
  • ****
  • Posts: 2120
  • Country: us
Re: HP 3468A in continual reset/init?
« Reply #13 on: May 25, 2015, 06:42:57 pm »
...
Perhaps I should do the same as Sailor did, hook it up to a 8 bit microcontroller board and program my own readout sequence. Will take some time though. :(
You could also take a quick look at what's happening in the programmer with the data and address pins in relation to /CE transitions.  And make sure power is showing up on the right pins.
 

Offline Kjelt

  • Super Contributor
  • ***
  • Posts: 6459
  • Country: nl
Re: HP 3468A in continual reset/init?
« Reply #14 on: May 25, 2015, 07:30:53 pm »
You could also take a quick look at what's happening in the programmer with the data and address pins in relation to /CE transitions.  And make sure power is showing up on the right pins. 
Power is correct, I checked that. All address and datalines are checked with multimeter.
I am a bit afraid using the scope on the programmer since the PC is earthed and the programmer is on the USB, I do not want to blow anything up. I am not sure what the Batronix GND on the connector is related to earth (scope ground).
Tried with an USB isolator I had laying around but then the Batronix does not work anymore, bummer  :(
 

Offline MarkL

  • Supporter
  • ****
  • Posts: 2120
  • Country: us
Re: HP 3468A in continual reset/init?
« Reply #15 on: May 25, 2015, 08:50:20 pm »
Understood on not wanting to connect the scope.  It's fine as long as you check first that the potential between the Batronix ground and the scope ground is 0V, but don't do anything you're not comfortable with.

You have a point that since the Batronix can change the function of a pin, the 2764 ground pin may not be ground all the time, but hopefully the Batronix is protected against that since it needs to handle completely shorted chips.

I'm noticing on your little diagram in the upper right of your paper that the 2764 is numbered clockwise, which is incorrect when looking from the top.  Maybe it's not wired right?
 

Offline SailorTopic starter

  • Regular Contributor
  • *
  • Posts: 170
Re: HP 3468A in continual reset/init?
« Reply #16 on: May 26, 2015, 01:13:40 am »
Hi Mark



But I don't think it's as simple as computing the CRC (that's really what the SA is doing) across all the bits in the ROM dump you have.  Whereas SA0 disables the ROM, SA1 re-enables the ROM and holds processor pin 31 (P14) low.

My guess is that the processor samples P14 at boot and, if low, goes into a loop where it reads all the locations in ROM, and probably pokes at all the other places described in table 7-D-4.


You are, of course, quite right. I had let my thoughts (of getting the signatures from SA0) run far ahead of registering the significance of the change to the start/stop connection for SA1 :palm: Oh well, I may still be able to use my Arduino as a SA. I think the speed (16MHz) will be sufficient, given some careful assembler code, and provided the SA1 sample size (start/stop time) isn't too long (I'll capture pin states to a RAM array and post-process the CRC).

The use of S501 to ground P14 during SA1 is a bit strange, because that inherently denies *any* access (and therefore signature check) of the upper 4k of the ROM. And as it is that upper 4k that the 3468 boots into during normal operation, well ...???

@Kjelt
I haven't had time yet to read your posts in detail, just skimmed them.  I (we all) would like to think that it's finger trouble in some way, total 0xff as a reality is too horrible to think about :(  I'll get back to this in an hour or two.


 

Offline SailorTopic starter

  • Regular Contributor
  • *
  • Posts: 170
Re: HP 3468A in continual reset/init?
« Reply #17 on: May 26, 2015, 03:36:54 am »

I'm noticing on your little diagram in the upper right of your paper that the 2764 is numbered clockwise, which is incorrect when looking from the top.  Maybe it's not wired right?


Mark, Kjelt sent me a photo of his transition/adapter board - the ROM socket is on the underside of the board, so it's mirrored. Power, ground, and 27C64_20 --> ROM_20, etc all look OK.

I agree, it's time for the 'scope. I'd just meter the Batronix frame ground to the PC ground (without the USB isolator) and if that's ok, then clip the scope probe ground to the Batronix frame and start looking at signals. They probably ::) won't be pretty to look at, but you'll get an idea of what's going on, and what relative voltages are on the pins.

Strange that it should be so dead...

I've had aquick look at JM503 while running SA1. It goes low for ~1msec, then high for ~20usec, then low again for more than 700msec before going high again to complete the cycle. I would like to think that the 1msec interval is the intended SA measurement window, but how is a 5004 to know? Or is the 'double window' just another symptom of what's wrong with my 3468A :-//
 

Offline MarkL

  • Supporter
  • ****
  • Posts: 2120
  • Country: us
Re: HP 3468A in continual reset/init?
« Reply #18 on: May 26, 2015, 11:44:26 am »

I'm noticing on your little diagram in the upper right of your paper that the 2764 is numbered clockwise, which is incorrect when looking from the top.  Maybe it's not wired right?


Mark, Kjelt sent me a photo of his transition/adapter board - the ROM socket is on the underside of the board, so it's mirrored. Power, ground, and 27C64_20 --> ROM_20, etc all look OK.
Oh well.  It was worth mentioning just in case.

Quote
I've had aquick look at JM503 while running SA1. It goes low for ~1msec, then high for ~20usec, then low again for more than 700msec before going high again to complete the cycle. I would like to think that the 1msec interval is the intended SA measurement window, but how is a 5004 to know? Or is the 'double window' just another symptom of what's wrong with my 3468A :-//
The 5004 wouldn't know.  It's constantly updating its display, so it would display one value, and then flip to the other.

If you can locate the loop in the disassembled code maybe you could tell if it's flying off into la-la land, or if its doing some initialization first.


And you're right - it's also quite odd that SA1 is only checking half the ROM.  Maybe the lower half contains a ROM check routine and if that's intact it can check the rest of the ROM and display an appropriate error.  So, it's only critical that the lower half is ok.

Building an analyzer with an Arduino is going to take some really tight coding.  The 8039 with a 6MHz crystal has a minimum cycle time of 2.5us, and the PSEN width (which is the MK3600 /CE) is only 400ns.  That would be your analyzer clock for SA1.  This is all according to the data sheet, but since you have it in front of you, you can say for sure.

 

Offline SailorTopic starter

  • Regular Contributor
  • *
  • Posts: 170
Re: HP 3468A in continual reset/init?
« Reply #19 on: May 26, 2015, 02:13:04 pm »
Maybe the lower half contains a ROM check routine and if that's intact it can check the rest of the ROM and display an appropriate error.  So, it's only critical that the lower half is ok.
I think you must be right with that.

Building an analyzer with an Arduino is going to take some really tight coding.

Indeed.

I didn't bother with Matlab - it was far easier to do it in assembler on the Atmega. The code generates the correct signatures for the count patterns from SA0, so I now know that part works (but it's post-processing of captured data, not real-time). With a simplistic approach, but tight coding, the CRC shift register update takes 19 cycles. At 16MHz that is just a fraction under 1.2usec. The stack operations in an interrupt/return is slightly more expensive than simple testing of an input bit (which is the way I handle the detection of the ALE and PSEN signals in my Single-Stepper implementation). Start condition detection can be handled the same way, and the stop condition could be handled by interrupt. So it may well be do-able.

I've got a fuzzy idea floating in my brain about another algorithm that might shave a few cycles off the present 19 ... I'll sleep on it.

 

Offline MarkL

  • Supporter
  • ****
  • Posts: 2120
  • Country: us
Re: HP 3468A in continual reset/init?
« Reply #20 on: May 26, 2015, 06:13:12 pm »
If you can't speed up your code enough, you could try slowing down the processor clock to say 3 or 4MHz (or whatever your code needs).  You could use a function generator and feed it into XTAL1 (pin 2).  Note that XTAL1 is not TTL compatible.  With some level adjustment, you could also use one of the PWM outputs from the Arduino.  In either case, I'd lift the crystal since I don't know how happy the driver on XTAL2 (pin 3) will be with a large input signal coming at it.

I don't see anything off-hand that wouldn't tolerate a slower clock.  The only thing that might not like it is the ADC, but that's not part of SA1 and is tested in the next section.

Admittedly this is changing the test conditions, but maybe it will show the ROM contents are ok.  I'd keep in mind that if the ROM shows ok, you still might be subject to some kind of strange race condition that's developed over time at the higher clock speed.  But at least you might end up with a basis for comparison for further analysis using the TLA.

Another interesting thing would to put the unit in normal mode and see if it gets any further with a slower clock.
 

Offline Kjelt

  • Super Contributor
  • ***
  • Posts: 6459
  • Country: nl
Re: HP 3468A in continual reset/init?
« Reply #21 on: May 26, 2015, 06:56:22 pm »
While at work today I remembered that a few years back I bought a cheap logic analyzer (and never really used it).
Because that is also powered with the same USB source I thought that would be ok to use it.
So here are two screenshots I just made, I used the 87C64 setting of the Batronix because indeed the 27C64 setting was wrong (good catch Mark).

A0..A6 are the address lines A0..A6
grey (A7) is the /CE of the ROM
B0..B7 are the data lines D0..D7

So as you can see the datalines keep on staying high which corresponds to the data read from the Batronix software.
I am not sure what is going on, but looking at the zoomed in (second capture) and knowing the internal sampling clock is 25MHz and the nr of samples the /OE is high is about 15,
that would correspond to about 60ns which I guess is too fast (too little time high) to work for the MKB36k ROM (pre charge time tp=125ns).

I am sleeping 15 times (25MHz = 40ns) is 600ns which should be more then enough.

What do you guys think?
« Last Edit: May 26, 2015, 06:59:08 pm by Kjelt »
 

Offline MarkL

  • Supporter
  • ****
  • Posts: 2120
  • Country: us
Re: HP 3468A in continual reset/init?
« Reply #22 on: May 26, 2015, 07:50:45 pm »
...
I am sleeping 15 times (25MHz = 40ns) is 600ns which should be more then enough.

What do you guys think?
I agree - 600ns should be fine.

But I'm also seeing that the Batronix /CE pulse width (when it's low) is in the ballpark of 10000ns, which is listed as the max on the MK36000 datasheet.  Are there any adjustments for that?

I don't know what the impact would be from going over the max.  I'd expect to see at least *something* coming out of the data pins, but maybe that's the issue.

So, I assume your MK36000 also came from a 3468A?  Want to put it back in there and look at it with the logic analyzer?


(I keep calling it a MK3600... I mean MK36000.)
 

Offline Kjelt

  • Super Contributor
  • ***
  • Posts: 6459
  • Country: nl
Re: HP 3468A in continual reset/init?
« Reply #23 on: May 26, 2015, 09:08:02 pm »
I am afraid that there is not enough room for a socket in the 3468a since the plastick powerswitch extension runs over it  :(
So I would have to make some temporary thing then. That can easily be reversed.
 I will have to see how to do that, any suggestions?
Its bedtime for now for me.
BTW, another open issue that we might discuss is with which other memory device we are going to replace the MK36000 if we have the final content. It could well be that we need a microcontroller to emulate it?
 

Offline MarkL

  • Supporter
  • ****
  • Posts: 2120
  • Country: us
Re: HP 3468A in continual reset/init?
« Reply #24 on: May 26, 2015, 10:26:36 pm »
I am afraid that there is not enough room for a socket in the 3468a since the plastick powerswitch extension runs over it  :(
So I would have to make some temporary thing then. That can easily be reversed.
 I will have to see how to do that, any suggestions?
Its bedtime for now for me.
It was just a suggestion to see if we could get some data out of the ROM.  I didn't realize it was mechanically difficult.

Do you want to post a picture of the area?

Quote
BTW, another open issue that we might discuss is with which other memory device we are going to replace the MK36000 if we have the final content. It could well be that we need a microcontroller to emulate it?
From what I see, the circuit design does not take advantage of the MK36000 address latching feature; there is a separate address latch U508.  So, I think even a 27C64 with 250ns access time or less would work fine.  But there's obviously a pin count problem, so some kind of adapter will be needed.
 


Share me

Digg  Facebook  SlashDot  Delicious  Technorati  Twitter  Google  Yahoo
Smf