Author Topic: Some old school instruments showing how it's done (HP 3325A and Fluke 8506a)  (Read 59700 times)

0 Members and 1 Guest are viewing this topic.

Offline SilverSolderTopic starter

  • Super Contributor
  • ***
  • Posts: 6126
  • Country: 00
Re: Some old school instruments showing how it's done (HP 3325A and Fluke 8506a)
« Reply #150 on: February 05, 2021, 11:01:23 pm »
Perhaps just turning off the Filter will have the desired (noise) effect?

The filter will suppress any signal over 7.5Hz or 75Hz, respectively, so it is unclear how much effect adding a signal would have unless sample periods get very long?

The noise may need to be added later in the chain, perhaps in the R2 converter itself...

Good point.

One interesting feature of the R2 ADC design is that each reading from the ADC is 6.5 digits. So with S0 sampling, that’s 250 6.5 digit readings per second. To see if there really are missing codes and how the filters might affect the results, it could be worthwhile to do the averaging remotely on a PC than at the 8505/6A. Simply wait for 1024 samples before computing the mean and place that value into a new time series (which would be equivalent to an average mode reading direct from the DMM). This way we eliminate any limitations with the precision of the internal data types and can quantify the noise of the ADC from the raw samples. This also lets us compute 7.5 digits with any of the three filter settings.

Exactly, I also suspect we may be seeing an artifact of the math doing the averaging, rather than missing codes from the A/D converter.

Unlike integrating ADCs, it makes more sense to use the fastest sample rate possible from a R2 ADC and perform the appropriate conditioning at the PC, rather than on the DMM. At least for these ancient boat anchors. With an auto zero circuit and more advanced controller and display, the 8506A could have been a much more impressive instrument. The "analyze" features on the DMM4050 (trend plot, stats and histogram) are be perfectly suited for the 8505/6A and its high speed, high resolution sampling. And with finer sample size control, speed vs noise could be better optimized for a given measurement. Then there is the possibility of using digital filtering to avoid the need for analog filters.

Agree, the 8505/6A coupled with a PC is the way to go.  I have all of them on a GPIB bus, and you can do stuff like trigger two (or more) of them to read at the exact same time, for example.  Then, as you say, you can do a ton of math on the numbers afterwards.   -  unfortunately, no matter how much math you do, if the last few digits are pure noise, they remain as pure noise afterwards too! :D   

Averaging works really well if the numbers are high quality in the first place, which they obviously are from these instruments if you dot the i's and cross the t's.
 

Offline SilverSolderTopic starter

  • Super Contributor
  • ***
  • Posts: 6126
  • Country: 00
Re: Some old school instruments showing how it's done (HP 3325A and Fluke 8506a)
« Reply #151 on: February 05, 2021, 11:04:36 pm »
Outside of a short note about the there being a fast (Y) and slow (Z) filter and them being a 3-pole Bessel with different cutoffs, they seem to provide very little detail about them.  Maybe the schematic IS the document.   

With Dave's UEI meter, I would feed a chirp into it and record the filters response.   Seems like you could do something like this to test out the hardware filters.

I ran the filters from the diagram in LTSpice and came up with the figures in red, in the Active Filter circuit diagram I posted earlier  (i.e. 7.5Hz and 75Hz, 18dB/octave for the slow and fast sections respectively).

I think those numbers are unrelated to the 50ms and 550ms "timeouts" as they are called in the manual.  My theory is that when one of the "timeouts" is activated, the meter simply waits that number of ms after a trigger before performing the reading (to guarantee the filter has settled).  Should be easy to verify on GPIB (still not set up here!)

Odd they wouldn't have documented the filters better and that you had to run SPICE to sort it out.     

Log sweep from 100mHz to 10Hz, attempting to collect the data as fast as the meter will allow it (about 20Hz).  Showing the rolloff with the slow filter enabled.

Agreed, we shouldn't have to jump through hoops to learn what the response of these filters are.  They obviously impact measurements at low frequencies so you need to take them into account.

Awesome, -6dBV at 7.5Hz....   exactly what SPICE predicted -  and now confirmed experimentally!  :D

The 75Hz filter is very close to the SPICE result as well.



« Last Edit: February 05, 2021, 11:09:24 pm by SilverSolder »
 

Offline SilverSolderTopic starter

  • Super Contributor
  • ***
  • Posts: 6126
  • Country: 00
Re: Some old school instruments showing how it's done (HP 3325A and Fluke 8506a)
« Reply #152 on: February 05, 2021, 11:17:37 pm »
[...] With an auto zero circuit and more advanced controller and display, the 8506A could have been a much more impressive instrument. [...]

I have done the "auto zero" externally by GPIB -  i.e. have a GPIB controlled relay regularly short the input, take a reading, set the zero, then switch back to what you are measuring.  This approach works surprisingly well, but obviously has pitfalls (thermal EMF, etc.) which means you have to go slow and steady...   but hey, these meters wouldn't be so cheap if they were easy to use as well as being accurate!  :D
 

Online joeqsmith

  • Super Contributor
  • ***
  • Posts: 12277
  • Country: us
Re: Some old school instruments showing how it's done (HP 3325A and Fluke 8506a)
« Reply #153 on: February 06, 2021, 02:00:49 am »
The fastest I can pull down data is about 65ms a sample.  That's with S0 (4ms), filter off and internal triggering.  The software is just pulling out data when it's available and stitching it together.  Another process checks for a valid frame and pulls it out to be processed.   The serial port only supports up to 9600 BAUD.  They also have a minimum of 2 stop bits.  A message is 14 bytes (using ASCII), or 14.6ms to send.   I tried using asynch which brought it down to 54ms  but it seems like it's slower than it should be.    Maybe the binary format would improve it.   

What are you able to achieve when using GPIB?

Offline SilverSolderTopic starter

  • Super Contributor
  • ***
  • Posts: 6126
  • Country: 00
Re: Some old school instruments showing how it's done (HP 3325A and Fluke 8506a)
« Reply #154 on: February 06, 2021, 04:27:49 am »
I use a serial-to-GPIB interface, with the serial side running at 38.4bps and I can get to about 15ms-20ms per "transaction".

The manual claims 500 readings per second for these Flukes, which is only 2ms per reading...  so it looks like the serial baud rate is the limit in both cases!

If you have a fast GPIB host controller, perhaps you should take up @garrettm on his offer for his spare GPIB interface?
 

Offline garrettm

  • Frequent Contributor
  • **
  • Posts: 319
  • Country: us
Re: Some old school instruments showing how it's done (HP 3325A and Fluke 8506a)
« Reply #155 on: February 06, 2021, 11:43:22 am »
The fastest I can pull down data is about 65ms a sample.  That's with S0 (4ms), filter off and internal triggering.  The software is just pulling out data when it's available and stitching it together.  Another process checks for a valid frame and pulls it out to be processed.   The serial port only supports up to 9600 BAUD.  They also have a minimum of 2 stop bits.  A message is 14 bytes (using ASCII), or 14.6ms to send.   I tried using asynch which brought it down to 54ms  but it seems like it's slower than it should be.    Maybe the binary format would improve it.   

What are you able to achieve when using GPIB?

I'm still in the process of getting my GPIB setup figured out, but I should have it up here soon. (It's much more complicated than serial!)

Looking at Tables 606-1 through 606-3. The Bit Serial Interface can be set to 1 stop bit (S3 on) and no parity (J3 removed).

Assuming the remaining jumpers and switches are set to

J1 installed
J2 removed
S1 off
S2 off
S4 off
S5 on
S5 on
S7 on

the serial bus would be configured for 9600bps RS232C with 1 start bit, 7 data bits, 0 parity and 1 stop bits, for a total of 9 bits (7N1) transmitted for each char.

This implies a maximum of 1067 chars per second over the bus. Each reading from the DMM is a string of length 13. Then we have the termination chars <CR> and <LF> tacked on for a total of 15 chars per reading. This implies a maximum of 71 6.5 digit readings per second.

Using command J to suppress the <LF> termination character allows for a maximum of 76 6.5 digit readings per second.

Since ASCII data over the serial bus is so slow, changing the DMM's sampling rate to S1 or S2, would allow you to perform some averaging at the DMM without lowering the reading rate at the PC. This would indirectly get you closer to the 250 samples/s reading rate, if cheating somewhat by "compressing" more samples in to each reading.

Assuming binary data and 8N1 frame length, then 960 bytes can be transmitted per second. Each reading of the DMM is then 6 bytes. Assuming terminating chars <CR><LF> are tacked on at the end of the payload, then a maximum of 120 readings per second are possible. (Or 137 if line feed is suppressed.)

Looking at the schematic for the Bit Serial Interface circuit, it seems like it would be pretty easy to modify. The serial port and level shifters could be replaced with a TTL level RS232 to USB or Ethernet board for ease of use. Though the bus would still be limited to 9600bps and no hardware flow control. It's possible that modifying the circuit around U3 could allow for higher baud rates. Though replacing U9 with an Arduino Micro would give hardware flow control and much faster communication over the virtual COM port. This would be even faster than the stock GPIB interface.
« Last Edit: February 07, 2021, 01:54:51 pm by garrettm »
 

Online joeqsmith

  • Super Contributor
  • ***
  • Posts: 12277
  • Country: us
Re: Some old school instruments showing how it's done (HP 3325A and Fluke 8506a)
« Reply #156 on: February 06, 2021, 02:55:19 pm »
Looks like I had sorted out the stop bits before.   The previous data was taken with eight data bits and a one stop.  10-bits/byte.   9600bps/10 = 1.04ms/byte.  With 14 bytes I get 14.58 or the 14.6 I mentioned earlier.   It's not a bit or byte off here or there, its a long way off.   

I doubt I will invest anytime modifying the meter but I may try the binary format.     

**********
The manual mentions a high speed reading mode "!" but it's only supported with parallel and GPIB.   I tried it anyway with the serial interface and it doesn't appear to work.  No surprise.   

Binary does improve things a bit.   The meter sends out 6 rather than 14 bytes.   About an 8ms difference.  Looks like it takes about 32ms per reading vs 54ms using ASCII.   One thing I notice is if I use asynchronous trigger, the unit suppresses the carriage return.   So there would be some gains there if I were able to sort out a way to synchronize with the data.
The other thing I noticed is when I use binary, regardless of the trigger setting, the display is off.     
   
The schematic shows a AY-5-1012 UART but the BOM shows a 13.  Looking at the clock generator, it looks like little effort to run it at 19.2kbps.     
http://sintran.com/sintran/library/libother/extern/F4702.pdf
« Last Edit: February 06, 2021, 06:05:01 pm by joeqsmith »
 

Offline SilverSolderTopic starter

  • Super Contributor
  • ***
  • Posts: 6126
  • Country: 00
Re: Some old school instruments showing how it's done (HP 3325A and Fluke 8506a)
« Reply #157 on: February 06, 2021, 05:16:34 pm »

Letting the meter do the averaging is probably the best - provided we can trust the numbers!
 

Offline garrettm

  • Frequent Contributor
  • **
  • Posts: 319
  • Country: us
Re: Some old school instruments showing how it's done (HP 3325A and Fluke 8506a)
« Reply #158 on: February 06, 2021, 07:16:59 pm »
[...]
The manual mentions a high speed reading mode "!" but it's only supported with parallel and GPIB.   I tried it anyway with the serial interface and it doesn't appear to work.  No surprise.   

Binary does improve things a bit.   The meter sends out 6 rather than 14 bytes.   About an 8ms difference.  Looks like it takes about 32ms per reading vs 54ms using ASCII.   One thing I notice is if I use asynchronous trigger, the unit suppresses the carriage return.   So there would be some gains there if I were able to sort out a way to synchronize with the data.
The other thing I noticed is when I use binary, regardless of the trigger setting, the display is off.     
   
The schematic shows a AY-5-1012 UART but the BOM shows a 13.  Looking at the clock generator, it looks like little effort to run it at 19.2kbps.     
http://sintran.com/sintran/library/libother/extern/F4702.pdf

Would replacing the 2.4576MHz crystal with a 4.9152MHz part do it? Almost seems too easy... May need to check the level shifters to see if they can do 19.2k baud. Otherwise it seems like a low cost upgrade--literally less than a dollar.

I'm still confused why your meter reads so slowly. While the numbers I ran are upper bounds, since they don't take into account processing delays and the transit time for data to move from the PC to the DMM and back, they still should be within 20% of actual throughput.

Have you tried using command J to suppress the line feed termination? Using two termination characters is pretty wasteful.
 

Online joeqsmith

  • Super Contributor
  • ***
  • Posts: 12277
  • Country: us
Re: Some old school instruments showing how it's done (HP 3325A and Fluke 8506a)
« Reply #159 on: February 06, 2021, 08:05:23 pm »
I have been using the J command to get the 14 byte payload when using ASCII.   I have not tried to enable it after changing to binary format to see if it actually will still add it.       

Adding the jumper from data sheets I linked previously, oddly running at 19.2k I see no further gains.  It seems to be capped out around 30ms per transfer.    Again, 8N1 or 10bits per byte or 1.92kBps, with a payload of  6 bytes it should be in the 3ms range.     

Looking at the serial data, we can see the meter sends out a packet pretty much every 30ms.    Again, the PC is not sending any data to the meter.  I just have the meter send it as fast as it can.   

***
I wonder if they cap it in their firmware based on the interface.   They know the card only supports 9600, so they only service it at that expected rate.  Odd choice if that's the case.

 
« Last Edit: February 06, 2021, 08:07:50 pm by joeqsmith »
 
The following users thanked this post: garrettm

Offline garrettm

  • Frequent Contributor
  • **
  • Posts: 319
  • Country: us
Re: Some old school instruments showing how it's done (HP 3325A and Fluke 8506a)
« Reply #160 on: February 06, 2021, 08:22:54 pm »
Doh! I didn't notice that note on page 6 about 19200 baud operation. Even better than upgrading the crystal, it can already do it!

I have firmware 6.07 that I can upload if you want to try flashing it. Maybe Fluke fixed the processing delay, whether artificial or accidental.
 

Offline garrettm

  • Frequent Contributor
  • **
  • Posts: 319
  • Country: us
Re: Some old school instruments showing how it's done (HP 3325A and Fluke 8506a)
« Reply #161 on: February 06, 2021, 08:38:39 pm »
Letting the meter do the averaging is probably the best - provided we can trust the numbers!

I would like to try emulating my DMM4050's trend plot, stats and histogram functions so I can compare the two for fun. Which necessitates getting as fast of readings from the DMM as possible. And I suppose I am curious if Fluke is full of crap with regards to how fast readings can be pulled off of these meters. After Joe's slow readback rate, I'm curious if it's an artificial cap or a firmware bug that’s holding back his meter.

One of the main selling points of the 8505/6A's was its fast sampling and readback capabilities. Just compare specs with its rival the HP 3456A: 25 samples/s at 1PLC with AZ on and 48 samples/s with AZ off for 6.5 digits. Any faster than that and it loses resolution. The 8505/6A can do 5 times that while maintaining 6.5 digits! And being designed without an auto zero function, it is more stable than the HP 3456A under its best high speed sampling mode.
 

Online joeqsmith

  • Super Contributor
  • ***
  • Posts: 12277
  • Country: us
Re: Some old school instruments showing how it's done (HP 3325A and Fluke 8506a)
« Reply #162 on: February 06, 2021, 09:41:08 pm »
This meter has version 603 installed.   Looks like its just a couple of 2764s.   If you have the images already archived, yes please, upload them and we can at least get on the same firmware. 

If I change to use the internal asynchronous trigger, you can see the packet is now just five bytes rather than the six.  There is no CR.   Also notice that the meter sends the data slightly faster but again, no where near what I would expect.     

Maybe SilverSolder's meter has different firmware as well which may explain why their meter is faster.    It's also VERY possible I am still not doing something properly which is throttling the system.   

Online joeqsmith

  • Super Contributor
  • ***
  • Posts: 12277
  • Country: us
Re: Some old school instruments showing how it's done (HP 3325A and Fluke 8506a)
« Reply #163 on: February 06, 2021, 11:38:59 pm »
Looking at the sync signal, it shows up in the center of the serial packet.  One per packet sent.  I assume then this means the meter is not over sampling and is actually collecting the data this slow.   

I reset the meter and just looked at the sync, with no serial communications.   Turning off the filter and setting the samples to 0, it's sampling at 21Hz.   I'm thinking that I'm really missing something basic as there's nothing that should be throttling it.    At least it doesn't seem at all related to the communications with the PC. 

Offline SilverSolderTopic starter

  • Super Contributor
  • ***
  • Posts: 6126
  • Country: 00
Re: Some old school instruments showing how it's done (HP 3325A and Fluke 8506a)
« Reply #164 on: February 07, 2021, 12:00:13 am »
This meter has version 603 installed.   Looks like its just a couple of 2764s.   If you have the images already archived, yes please, upload them and we can at least get on the same firmware. 

If I change to use the internal asynchronous trigger, you can see the packet is now just five bytes rather than the six.  There is no CR.   Also notice that the meter sends the data slightly faster but again, no where near what I would expect.     

Maybe SilverSolder's meter has different firmware as well which may explain why their meter is faster.    It's also VERY possible I am still not doing something properly which is throttling the system.

Snowstorm tomorrow, perfect time to get GPIB working! :D

I may be misremembering the speed of the Fluke:  it was quite a while ago, it may have been an old HP 59313 A/D converter that I got running that fast...  Time to get some accurate numbers. 

I will check what firmware revisions I have as well, it would be cool if we could upgrade all of them to the latest version!  (Assuming the hardware is compatible throughout...)

« Last Edit: February 07, 2021, 12:05:22 am by SilverSolder »
 

Online joeqsmith

  • Super Contributor
  • ***
  • Posts: 12277
  • Country: us
Re: Some old school instruments showing how it's done (HP 3325A and Fluke 8506a)
« Reply #165 on: February 07, 2021, 12:35:46 am »
If I change over to use the external trigger while monitoring the sync, again it seems to alias long before it should.   

Here you can see the serial port being used with the external trigger.  It will keep up at 22Hz but at 23Hz it will start to miss. 

Snowstorm tomorrow, perfect time to get GPIB working! :D

I may be misremembering the speed of the Fluke:  it was quite a while ago, it may have been an old HP 59313 A/D converter that I got running that fast...  Time to get some accurate numbers. 

I will check what firmware revisions I have as well, it would be cool if we could upgrade all of them to the latest version!  (Assuming the hardware is compatible throughout...)

That would be great as I am really at a loss.  Maybe I just don't understand the manual.   S0 should be 1 sample/reading and they claim a digitizing time of 4ms.  2ms when using line asynchronous.  If I set the number of samples higher to allow the meter to collect at a faster rate, the sync rate stays the same.  It's just looks like it's a much slower than they claim.   

Offline SilverSolderTopic starter

  • Super Contributor
  • ***
  • Posts: 6126
  • Country: 00
Re: Some old school instruments showing how it's done (HP 3325A and Fluke 8506a)
« Reply #166 on: February 07, 2021, 02:16:51 am »

My max versions are:
 
  8505A -  v5.0.5
  8506A -  v6.0.7

I have no idea what the actual latest revisions actually are.

There seems to be a big difference between v.6.0.6 and v6.0.7 for the 8506A, they behave quite differently in many subtle respects.

I have never tried burning eproms, but I do have a TL866CS here that might do the job?
 

Offline garrettm

  • Frequent Contributor
  • **
  • Posts: 319
  • Country: us
Re: Some old school instruments showing how it's done (HP 3325A and Fluke 8506a)
« Reply #167 on: February 07, 2021, 04:13:37 am »
This meter has version 603 installed.   Looks like its just a couple of 2764s.   If you have the images already archived, yes please, upload them and we can at least get on the same firmware. 

If I change to use the internal asynchronous trigger, you can see the packet is now just five bytes rather than the six.  There is no CR.   Also notice that the meter sends the data slightly faster but again, no where near what I would expect.     

Maybe SilverSolder's meter has different firmware as well which may explain why their meter is faster.    It's also VERY possible I am still not doing something properly which is throttling the system.

603, that’s positively ancient! Until now, I've never seen a firmware version below 605 out in the wild. It very well could be a software glitch holding your unit back. What year do you think you Controller module was made?

I haven't read my ROMs yet but I have a TL866II PLUS from XGecu that I can use to get them. I'm quite keen to see what differences you observe between revisions. It would be nice if we can put that enhanced baud rate on the Bit Serial Interface to good use!

I believe versions 1.0.1 for the CT variant and 607 for the standard 8506A are the last firmware revisions. The controllers with these versions had date codes of 1993 on the chips.

I've attached a picture of the elusive CT model and a couple of different Controller boards that had bad calibration memory. The CT Controller from 1993 looks basically identical to the others dating to 1983 and 1987 which both have version 606.

Here's a thread I made about that repair.

https://www.eevblog.com/forum/repair/fluke-8506a-repair/msg1002513/#msg1002513

I'll upload the newer 607 firmware here in a bit.
« Last Edit: February 07, 2021, 03:54:41 pm by garrettm »
 

Offline SilverSolderTopic starter

  • Super Contributor
  • ***
  • Posts: 6126
  • Country: 00
Re: Some old school instruments showing how it's done (HP 3325A and Fluke 8506a)
« Reply #168 on: February 07, 2021, 06:21:58 am »
Judging by the picture of the controller posted at Xdevs (reproduced below), it seems that the firmware in the EPROMS apply to both the 8505A and the 8506A - somehow, the code must figure out what it is when it boots.  The reason I think that is because firmware on 8505A always appears to be 5.x.x whereas it is always 6.x.x on the 8506A, based on the units I have seen.  Note the label on the EPROM in the picture lists two revision numbers...  one for each model!  So, the newest ROM image might be a good upgrade for both models!  (Note, this is just a wild guess and it could be completely wrong...)



I am not very experienced with EPROMS, so this next "conclusion jump" may be wrong:  I noticed that the crystal in the controller is nearly 16MHz, we are probably dealing with an 8MHz CPU - which was fast in 1982.  Does that mean the grade of EPROM has to be the faster 200ns or better kind, to avoid introducing wait states in the CPU?  I have noticed EPROM is available in several speed grades...  I haven't looked under the labels of any of mine yet to confirm or deny this theory so it may well be incorrect.

« Last Edit: February 07, 2021, 06:42:38 am by SilverSolder »
 

Offline garrettm

  • Frequent Contributor
  • **
  • Posts: 319
  • Country: us
Re: Some old school instruments showing how it's done (HP 3325A and Fluke 8506a)
« Reply #169 on: February 07, 2021, 10:04:34 am »
I got the V506/607 EPROMs read from my meter. And since I had a spare Controller board with V505/606 firmware I read the EPROMs from it too.

The zip file contains the U23 and U24 bins along with datasheets for the different UV EPROMS used on each controller, photos of the actual chips and some notes. Should be pretty self contained.

I read the contents of each chip three times and compared the results to ensure I got good reads. I then compared the contents of each version and found a string for "8505A   :8506A   :" in both U23 binaries which gave me confidence that I read them correctly.

*Corrected a minor typo in the 8505A_8506A_Firmware.zip, where I wrote V505_607 instead of V506_607.
« Last Edit: February 07, 2021, 01:34:18 pm by garrettm »
 
The following users thanked this post: SilverSolder, Roman oh

Offline garrettm

  • Frequent Contributor
  • **
  • Posts: 319
  • Country: us
Re: Some old school instruments showing how it's done (HP 3325A and Fluke 8506a)
« Reply #170 on: February 07, 2021, 10:32:21 am »
[...] it seems that the firmware in the EPROMS apply to both the 8505A and the 8506A - somehow, the code must figure out what it is when it boots.

Having replaced Controller modules between 8506A and 8505A units, I can confirm that the EPROMs contain firmware for both models. The only units not compatible are CT models which have special firmware due to hardware modifications (no rear input and special HV AC divider for 1kV range). The CT Controller can tell when not placed in a CT chassis, so somewhere on the mainboard or elsewhere is some sort of jumper or other feature that lets the Controller module know what model the unit is.
« Last Edit: February 07, 2021, 12:47:07 pm by garrettm »
 
The following users thanked this post: SilverSolder

Offline m k

  • Super Contributor
  • ***
  • Posts: 2648
  • Country: fi
Re: Some old school instruments showing how it's done (HP 3325A and Fluke 8506a)
« Reply #171 on: February 07, 2021, 12:34:20 pm »
From M2764A manual

200 -2F1, -20F1
250 -F1, -25F1, -F6
300 -3F1, -30F1
450 -4F1, -45F1, -4F6
Advance-Aneng-Appa-AVO-Beckman-Danbridge-Data Tech-Fluke-General Radio-H. W. Sullivan-Heathkit-HP-Kaise-Kyoritsu-Leeds & Northrup-Mastech-OR-X-REO-Simpson-Sinclair-Tektronix-Tokyo Rikosha-Topward-Triplett-Tritron-YFE
(plus lesser brands from the work shop of the world)
 
The following users thanked this post: SilverSolder

Offline SilverSolderTopic starter

  • Super Contributor
  • ***
  • Posts: 6126
  • Country: 00
Re: Some old school instruments showing how it's done (HP 3325A and Fluke 8506a)
« Reply #172 on: February 07, 2021, 02:29:37 pm »
From M2764A manual

200 -2F1, -20F1
250 -F1, -25F1, -F6
300 -3F1, -30F1
450 -4F1, -45F1, -4F6

Apparently the 8080A is only a "up to 4MHz" processor, so it is not picky about EPROM speed.

I wonder why Fluke chose a 15.36MHz crystal to run this board...  would that not run the CPU at 1.92MHz?


8080A     2.0MHz
8080A-1 3.125MHz
8080A-2 2.67MHz
8080B     4.0MHz


[edit: CPU speed]
« Last Edit: February 07, 2021, 02:40:49 pm by SilverSolder »
 

Offline garrettm

  • Frequent Contributor
  • **
  • Posts: 319
  • Country: us
Re: Some old school instruments showing how it's done (HP 3325A and Fluke 8506a)
« Reply #173 on: February 07, 2021, 04:38:03 pm »
My max versions are:
 
  8505A -  v5.0.5
  8506A -  v6.0.7

I have no idea what the actual latest revisions actually are.

There seems to be a big difference between v.6.0.6 and v6.0.7 for the 8506A, they behave quite differently in many subtle respects.

I have never tried burning eproms, but I do have a TL866CS here that might do the job?

The 8505A with 505 firmware can be updated to 506 if you are feeling up to it.

The TL866CS is capable of producing the 21V peak programming voltage required by some of the early 2764 EPROMs. But the chips need to be erased first using a UV light source (~254nm wavelength). That requires pulling the label back to illuminate the die through a quartz window. Depending on the strength of the lamp, it could take a while to completely erase the contents. After proper erasure, the chip should be full of 1s. So before writing, you will want to check that the chip reads all 1s (or Fs in hex). After programming each chip, I would read the new contents and compare with the bin file to make sure everything worked. As Ronald Reagan once said, trust but verify.

And on that note, it also wouldn't hurt to read your EPROMs first and save the contents. The bins should match my V505/606 bins. If not, you will want to use Tiny Hexer to compare binaries and look if you can find "8505A   :8506A   :" in the U23 dump as a sanity check.
« Last Edit: February 07, 2021, 04:42:20 pm by garrettm »
 

Offline SilverSolderTopic starter

  • Super Contributor
  • ***
  • Posts: 6126
  • Country: 00
Re: Some old school instruments showing how it's done (HP 3325A and Fluke 8506a)
« Reply #174 on: February 07, 2021, 05:55:32 pm »
My max versions are:
 
  8505A -  v5.0.5
  8506A -  v6.0.7

I have no idea what the actual latest revisions actually are.

There seems to be a big difference between v.6.0.6 and v6.0.7 for the 8506A, they behave quite differently in many subtle respects.

I have never tried burning eproms, but I do have a TL866CS here that might do the job?

The 8505A with 505 firmware can be updated to 506 if you are feeling up to it.

The TL866CS is capable of producing the 21V peak programming voltage required by some of the early 2764 EPROMs. But the chips need to be erased first using a UV light source (~254nm wavelength). That requires pulling the label back to illuminate the die through a quartz window. Depending on the strength of the lamp, it could take a while to completely erase the contents. After proper erasure, the chip should be full of 1s. So before writing, you will want to check that the chip reads all 1s (or Fs in hex). After programming each chip, I would read the new contents and compare with the bin file to make sure everything worked. As Ronald Reagan once said, trust but verify.

And on that note, it also wouldn't hurt to read your EPROMs first and save the contents. The bins should match my V505/606 bins. If not, you will want to use Tiny Hexer to compare binaries and look if you can find "8505A   :8506A   :" in the U23 dump as a sanity check.


My first UV EPROM eraser is on its way!  :D

For fun, I put the hex files through a crude 8080 disassembler - attached.  No guarantees that anything is right - I am utterly unfamiliar with 8080 assembly language.  Unfortunately, it doesn't include comments!  :D

 


Share me

Digg  Facebook  SlashDot  Delicious  Technorati  Twitter  Google  Yahoo
Smf