-
The PM3320 was a generation more advanced than the PM3315 so that's not surprising really. The 3315 had a considerably less powerful 8085 embedded system in it which couldn't do anything fancy other than reproduce the data it had captured. Also no readout which is why the front panel was slathered in displays and controls. The internal construction is about the same; the PM3315 was a large analogue board on the base with a whole rack of cards inside it.
There's a paper on the PM3315 design here: http://www.extra.research.philips.com/hera/people/aarts/_Philips%20Bound%20Archive/PTechReview/PTechReview-40-1982-055.pdf
I found some pictures of the guts of mine:
-
That kinda looks simple and easy to understand, compared to the Monster the PM3320A is.
They even made an upgraded Version: The PM3323, which had more sophisticated software, 500MS/s and 300MHz analog bandwidth.
While they used through hole with SMD-Chips on breakout-board like modules in the PM3320, the PM3323 used a mix of SMD and Through Hole on the main boards.
Unfortunately, I didn't have enough money today, otherwise this thread would have covered the PM3323 too (someone just sold one on ebay, which looked like it had terrible noise - almost always because the SMD-Caps have dried out).
Most of the same technology was also put to use in a 2GHz Scope: The PM3340.
That one is restricted to RF-Stuff though, as the inputs can only tolerate 5V maximum if I remember correctly.
Back to my unit: I've just finished the calibration-process as well as I could with what I have available here (Feeltech FY3224 Signal Gen, Rigol 1054Z). Really complex procedure to calibrate the P2CCD-Part, which slows down the fast signals arriving at the instrument.
What I find really interesting: Add, Inverting, MIN/MAX-Mode are done in the analog domain. This makes it stand out from the other scopes of thze time, but also adds massive amounts of potentiometers and components to the boards, wich are stacked in several layers on the bottom of the instrument.
The analog parts didn't drift that much btw. Only the CCD-Part required a rather comprehensive adjustment after which the rest was almost immediately in spec, so I didn't go through the whole process of adjusting the analog frontends. Partially because the signal generator leaves a lot to be desired.
So far, I'd call the work on the scope done for now. I've recapped the PSU when I got the unit and recapping the ADC-Board reduced the noise level significantly and about to the same level present in my Rigol.
Tomorrow I'll post some more pictures and I might even be tempted to make a video, explaining the calibration-process
Btw. If anyone here has a PM3323, I'd love to buy it. Or at least post some interesting pictures and give a short review - These Philips-Scopes are kind of underdogs here it seems and they feature really interesting technology.
Also, I'm kinda curious if it is possible to replace the processors with 68010 CPUs, which are pin-compatible but not 100% software-comptabile.
To this end, I'd like to examine the Firmware to see if the Firmware makes use of the instructions that don't work with the newer CPUs.
I haven't found a good script to combine the ROMS yet, however. And a good 68k Disassembler seems to be either very expensive, or unable to create "readable" Assembler-Code
One more addition, just FYI: The datecodes in the digital section range from 84 to 91 (not counting the GPIB-Board, as that looks like it hasn't been installed in the factory - board has kinda different color). -
I've attached some pictures of the ADC-Board and my solution to repairing the broken 1 Ohm Resistor, as well as the socket for the OQ0146, which can be found basically everywhere on the bottom side btw.
Also some high res (well, as high as my Nexus 5 can go ) photos of the bottom boards and the sample clock generator-board: 
Vertical amplifiers.
P2CCD Chip - The SMD-Soldering looks kinda strange on the picture, but doesn't look like that in reality.
I'd say the board was reflowed, btw. because there are no pads to suck solder away from a solder-wave.
The analog processing board. The potentiometers calibrate gain, offsets, MIN/MAX-Mode, etc.
Sample Clock generator. This board creates a 100 MHz and 125 MHz clock (the two oscillators with the crystals), which can be doubled or divided to get the desired sample-rate.
Unfortunately, the Scope doesn't show the sample-rate on screen.
-
That’s an absolutely beast! Thanks for posting the pictures.
I’ll let you know if I see any of these scopes floating around. -
I've installed a MC68010R10 processor on the processor-board now.
So far the scope-software seems to be stable, but the speed didn't really improve.
Only the Multiply and Divide function felt a bit faster. I've yet to analyze that on the video I made (which would be expected, as these operations work faster in the MC68010).
FFTs are maybe a tiny bit faster, but half or three quarters of a second faster doesn't really matter.
With aquisition running normally and updating the trace on the screen (with which the CPU has almost no involvement) it took about 15 seconds with the old CPU and 14 with the new one (varies by about half a second) to perform FFT on a full sweep (4k Samples).
With Aquisition stopped, FFT took about 10 seconds with the new CPU. I didn't took any measurements with the old CPU in this mode however.
Unfortunately overclocking is out of the question, as the Clockgenerator for the CPU also generates the base clock for the rest of the scope.
Locking that clock to an external reference would be cool though. Between the card-cage and the PSU is enough space for a PLL-Board and the back has enough holes for the BNC-Connectors
-
I've installed a MC68010R10 processor on the processor-board now.
Don't be so quick to discount overclocking on this beast.
...
Unfortunately overclocking is out of the question, as the Clockgenerator for the CPU also generates the base clock for the rest of the scope.
...
I've had a good look at this thing and the 68k architecture. Honestly, it should be easy to improve performance, maybe very substantially. The main reason it that the 68k uses an asynchronous bus. So instead of having a pre-determined number of wait states hard-coded into the firmware for things like ROM or RAM access timing, it uses a handshake. When reading or writing RAM/ROM or anything else on the CPU bus, it puts out the request, then waits for the acknowledge handshake to come back from the addressed device. This means that you are free to increase the speed of the CPU itself, without affecting the timing of any bus accesses. In other words, you won't be overclocking the RAM or ROM or I/O devices. You can find 68010 up to 25 MHz in PLCC68 packages. A simple PLCC68 socket can be plugged into the PGA socket to convert it. You should be able to tap into UPCK16 (16 MHz) in place of UPCK (8 MHz). Or you could hack up a simple frequency multiplier (e.g. ICS511) to increase the 8 MHz clock by 2x, 2.5x, 3x, 3.33x, etc.
But wait, there's more! If we increase the speed of the RAM, we can increase performance, especially with a faster CPU. While the program ROM for the 68K is on the A6 CPU board, its RAM is located on the A5 MRAM board. The RAM used is relatively slow 120 ns SRAM. we could swap it out for much faster ones, say 35 ns. That alone won't affect anything, but now we are free to tweak the timing of the bus handshake. Since this RAM should be much faster, we can assert the transfer acknowledge signal much sooner. In the description of the A5 board, the service manual states:
"The delay of the CKAB signals (R1802 and C1851) ensures stable data on the address bus and the data bus when they are clocked in.
The delay of DATRAKLT (R1839 and C1852) ensures enough data setup time for the RAM."
In other words, the two CKAB signals (CKAB--LT and CKAB--HT, active low and high respectively) control a delay between receiving a write request and activating the write on the RAM, to ensure stable address and data signals. The DATRAKLT is the bus transfer acknowledge sent back to the CPU for both reads and writes. In theory, with faster RAM, at least the DATRAKLT delay can be reduced (by reducing R1839). This speedup will help performance regardless of whether the CPU is overclocked or not. Access to data in RAM should be a bottleneck for operations such as FFT which are data heavy.
Similar gains may be possible with ROM as well, especially when using a faster CPU speed, since it will need to fetch instructions at a higher rate. The 68k has no cache and always needs to read from ROM every single instruction executed (though it only manages to execute roughly 1 instruction per 10 clock cycles). With the installed slow 200 ns ROMs, a faster CPU will likely frequently stall as a pre-fetch ends up waiting for the Ack to ROM accesses. Compatible EPROM or EEPROM with speeds better than 50 ns can be had. I haven't yet figured out how the timing delay on the EPROM access is done, it doesn't seem to be a simple RC delay as with the SRAM.
I'd be up for trying some of this stuff on my PM3320A as well. It seems like fun. I'll dig around to see what kind of SRAMs and EPROMs I have... -
I actually have a still-in-use PM3323. You do NOT want to know what it would cost to ship to Germany - it's a beast.
-
Don't be so quick to discount overclocking on this beast.
(...)
I'd be up for trying some of this stuff on my PM3320A as well. It seems like fun. I'll dig around to see what kind of SRAMs and EPROMs I have...
That sounds really interesting.
I've already found a MC68010FN25 CPU on ebay for quite reasonable 12€ including shipping from spain.
The PLCC-68 sockets I have here don't fit in the socket for the processor, however. Are there different types?
Going through the circuit descriptions, I don't see any parts that would be aversly affected by this modification. The DPU transfers data via its private bus to the Display Memory.
Because the DPU can continue to update trace-data, I guess the CPU copies the entire 4k of trace-memory to the A5 Processor-RAM and then starts the number-crunching, so no interference from the Display DAC and the DPU.
Additional Speedup might come from replacing Address- and Data-Buffers. Stock are 74LS245 with up to 40ns enable-time. 74ACT245 can reduce the enable-time to just 10ns and propagation delay from 8 to 4ns (typ.).
Do you have a logic analyzer, macboy? -
I've done some calculations and also measured the time between start and finish of a RAM-Access.
I've calculated that the RAM-Board requires about 270ns to have valid data on the bus.
The RC-Timer and other timing-stuff should give the RAM-Board about 300ns to complete the task.
As you can see on the attached screenshots from my Logic Analyzer, the time varies between 265ns and 498ns. I'm guessing it is the difference between read and write-operations. After looking at the timing diagrams in the Reference-Manual of the 68k (Link:https://www.nxp.com/docs/en/reference-manual/MC68000UM.pdf) it seems like the CPU spends quite a lot of time waiting for the RAM to finish working. Most likely 2 or even 3 full clock-cycles are wasted with wait states.
Simply upgrading the RAM and reduce the timing constants of the data acknowledge-signals should speed up things considerably.
I've also took the time to mark the signals that are required to select the RAMs and ROMs and where the acknowledge-signals are being created on the schematics.
-
Here's the schematic of the Processor-Board
-
Holy crap, that is really an improvement!
To see what happens when I speed up the Data Acknowledge, I replaced the 1k Resistors with 860 Ohm resistors.
The result: Single channel FFT (full 4k-Points) takes about 9.5 instead of 14 seconds and the FFT on one channel when 2 Channels are active (at 200µs/div) takes 5.5 instead of 7.5 seconds!
So there's really a lot of room for improvement!
Also the MRAM-Board runs noticably - How that is possible, I have no clue.
I had to replace the resistors on the MRAM-Board and the CPU-Board btw. Both have timers whose outputs are OR-Wired with open collectors and on the MRAM-Board there's also the Aquisition Control Logic, which does not have its own DataAck-Signal.
So far I've not identified any components on the data-bus and the address-bus that wouldn't be able to handle much faster times (almost all are 74-Latches or D-Type FlipFlops and the few special chips can handle at up to 8 or even 10MHz on the Data-Bus.
I'm going to order some RAMs from Digikey (45 or even 12ns ones) and solder them on adapters to be put into the scope. Is there a difference between 61 and 62-SRAM Chips? So far I've not been able to find one in the datasheets.
Btw. The DataAck-Signal for the ROM is generated by a simple delay via two NOR-Gates. Basically the ROM has the data ready faster than the CPU needs it.
Could be different at 10, 12 or even 16MHz CPU-Clock. -
I had noticed the PGA socket issue after posting too. Sockets are available of course, and if one looks hard enough, adapters exist too. They were available for 68k debugger/emulator systems.
I have only one of those saleae clone 8 bit ~25 MHz logic analyzers. A while ago I passed on a really nice HP logic analyzer with dozens of 100 MHz inputs, which I could have bought at roughly scrap cost. The cost wasn't an issue, but I lacked the space and approval from SWMBO.
I dug around and found some nice fast RAMs, some W24M257AK-15 which had been used as cache memory on a '486. They are 32Kx8 at 15 ns (not 150 ns which might also be the case for a -15 suffix), so 8 times as fast as the originals (and a decade newer). I also found some IDT7164S in really pretty side-brazed ceramic DIP package with gold plated everything, but they are only 8Kx8, so too small, and slower as well (35 ns). I might have a set of 120 ns EPROMs, not the exact type, larger capacity and still 32 pins. I'll need to check pinouts.
I've never been into my PM3320A, I've never had a need to open it. I just had a quick look at the thing. Photo below. I may be mistaken, but that looks like an unbroken factory seal! (Fluke owned Philips T&M when this one was made). Unlike much of my equipment, this one didn't have calibration stickers and seals on it when I got it, so I suppose can believe that it was never calibrated. Amazing that it is still relatively accurate.
SaabFAN, your service manual is definitely better than mine, I can hardly read signal and component names on mine. Your scans look much better. Also yours seems to show four SRAMs on the MRAM board, mine shows two plus two optional ROMs. Can you share? I'll give you a link to a folder on my Google drive where you can upload it.
-
Holy crap, that is really an improvement!
Very nice!
To see what happens when I speed up the Data Acknowledge, I replaced the 1k Resistors with 860 Ohm resistors.
The result: Single channel FFT (full 4k-Points) takes about 9.5 instead of 14 seconds and the FFT on one channel when 2 Channels are active (at 200µs/div) takes 5.5 instead of 7.5 seconds!
So there's really a lot of room for improvement!
Also the MRAM-Board runs noticably - How that is possible, I have no clue.
I had to replace the resistors on the MRAM-Board and the CPU-Board btw. Both have timers whose outputs are OR-Wired with open collectors and on the MRAM-Board there's also the Aquisition Control Logic, which does not have its own DataAck-Signal.
...
I am not surprised at the improvement, the slow SRAM was clearly a bottleneck. The amount of improvement is more than I expected, especially without actually installing faster SRAM.
The 200 ns EPROM might or might not become an issue with a faster CPU clock.
I had noticed the ACK generated on the CPU board for I/O devices. I wonder if it is or could be gated depending on the addressed device?
FWIW I've heard of people overclocking 68k CPUs to 50 MHz. I think Amiga forums might be the best source of info on that. -
I made a mistake when measuring the times after changing the resistors - I had Rectangle Window and Linear Scaling on, instead of Hamming and Logarithmic. With Hamming and Log scaling I've managed to shave off "just" about another second on a full FFT, which means they take now about 13 seconds instead of about 15 seconds in original configuration.
Unfortunately, I didn't take any measurements with Rectangle Windows and Log scaling before changing the CPU or reducing the timing of DataAck. But it feels quite a bit faster than before.
Also it seems like the difference between execution times with Rect. + Linear scaling and Hamm + Log. Scaling seems to be bigger with the improvements.
I'm guessing that Hamming Window and Log Scaling is more CPU heavy than Rect. Window with Linear Scaling (Log scaling adds one additional pass for every data-point to scale it, which takes A LOT of CPU-Cycles). So CPU-Overclocking will most likely have a bigger impact here than Memory-Upgrades.
I'm going to use these ROMs for the Upgrade:https://www.digikey.de/product-detail/de/microchip-technology/SST39SF010A-70-4C-PHE/SST39SF010A-70-4C-PHE-ND/2297826 and these RAMs: https://www.digikey.de/product-detail/de/issi-integrated-silicon-solution-inc/IS61C256AL-12JLI/706-1030-ND/1555403 They should fit on SOIC-28 Adapter-Boards available on Ebay for 50cents a piece.
I'm guessing that it should be possible to cut the timing constants for Data Acknowledge on the Processor-Board in half, if the RAMs on the MRAM and DISPLAY-RAM Board are replaced with faster ones (DISPLAY-RAM Board does not generate its own Acknowledge-Signal for the CPU).
Anything faster is going to require dedicated circuitry to disable the DataAck-Circuit on the processor-board during RAM-Access. -
Maybe try replacing the RAMs and EPROMs with fast units and ground the DTACK signal so everything runs at the max speed.
There used to be a 68000 enthusiast magazine called "DTACK Grounded". Parts of the magazine were printed on dark red paper that made photocopying difficult. -
I love the idea of the 68k magazine called DTACK Grounded.
I broke the seals and opened it up. Amazing how little dust is in there. Obviously very few hours of use, which also jives with the fact that it was never calibrated.
My ROMs are v4.2 for main board and v4.1 for GPIB board. I'll dump them then maybe update to v5.0 seen here. I have a UV eraser and TL866 so why not.
The RAMs I found and mentioned earlier are narrow body so I'll need to either make or buy adapters. I think I'll stick a pot across those timing resistors for easy tweakin'. -
The fast rams and roms are ordered and should arrive sometime next week.
I'm currently designing a small board that will allow adjusting the CPU-Frequency and is also going to contain a circuit that will replace the circuit on the CPU-Board that generates the Acknowledge-Signal when the Aquisition Control Logic on the A5-Module is accessed.
I'm also designing an adaptor from PLCC to PGA-68.
Schematics and PCB-Layouts will be posted later this day.
@macboy, can you upload your 4.2 ROMs? My scope has the 4.1 Software. Would be interesting so see what's different between both releases. -
The fast rams and roms are ordered and should arrive sometime next week.
I can upload the v4.2 ROMs. I'll try to find time later today.
I'm currently designing a small board that will allow adjusting the CPU-Frequency and is also going to contain a circuit that will replace the circuit on the CPU-Board that generates the Acknowledge-Signal when the Aquisition Control Logic on the A5-Module is accessed.
I'm also designing an adaptor from PLCC to PGA-68.
Schematics and PCB-Layouts will be posted later this day.
@macboy, can you upload your 4.2 ROMs? My scope has the 4.1 Software. Would be interesting so see what's different between both releases.
The ACK that is produced on the CPU board itself ... are you talking about DTARAKLT? I thought this is only for I/O space accesses. D1734 is a big NAND gate that only produces the postive output when one of the eight I/O select signals is active. Once of those is active when D1744 decodes an I/O space address. Since the CPU bus DTACK signal is driven as open-collector, the first device to assert the Ack will cause it to be recognized. -
Yes, you are right. There's no need to create DATRAKLT anywhere else than on the MRAM-Board. I confused Active HIGH and LOW (again)
So the only circuit needing speedup is the one on the MRAM-Board that generates DATRAKLT after a memory-access has occured, which can be done by replacing one resistor. -
I've sped up the DATRAKLT by an additional 50ns, so the Acknowledge happens now after 220ns instead of 330ns.
I didn't do any measurements on the speedup because I have also started modifying the CPU-Board.
As you can see on the attached pictures, there are a few modifications necessary to isolate the CPU-Clock from the main clock generator.
Driving the CPU with my signal gen, the maximum stable clock is 9.5MHz with the 68010 and the mentioned modification to the circuits that generate DATRAKLT.
To have the fine control necessary, I've scrapped the circuit that used a 4046 for the PLL and I'm now using an Si5351 PLL that is controlled by an Arduino Nano.
The required 5Vpp clock-signal is being generated by a 74S74 FlipFlop, which receives the clock from the PLL, divides it by 2 and then sends it out via an SMA-Connector through a coax-cable to the processor.
-
Firmware version 4.2 for PM3320A, PM3323, and PM3340.
The zip contains 4 x 128 kB ROMs, which are DIP 32, Intel 27C010, 200ns speed grade in my machine.
I have the FFT option as well as the GPIB/serial (PM8956A) option, which itself has v4.1 ROMs.
I plan to desolder the slow 120 ns SRAMs and replace them with the faster 35 ns SRAMs I mentioned in an earlier post. The new SRAMs are pin compatible but narrow DIP28 so I will need to create some adapters for them to fit the wide DIP28 footprints.
I'll also desolder the IC which drives the CPU clock, and place it into a custom made "interposer" socket, which will allow me to disconnect just the CPU clock signal for injection of another one. I'd rather do this than cut PCB traces. I think some of the 74LS series might be replaced with 74ALS for speed improvement (less propagation delay especially). I think 74F is too power hungry in general. 74ACT is another option to look at, they are very fast as well. I am thinking in particular about the bus transceivers, address decoders, etc. which can be bottlenecks for the RAM/ROM access times.
I like the idea of hacking a 68030 into this thing. The instruction and data caches could mean significant performance gains. Might even get to something like real-time FFT (~1 per second) which would make it so much more useful. I need to investigate whether the system actually uses the mc6800 (sic) style peripheral bus that the 68000 offers, but the 68030 (68020) does not. That would be a showstopper as I don't have the inclination to build the external logic necessary to implement that. Otherwise it might not be too hard, as Motorola did a great job of making each CPU in the series a "proper superset" of the previous ones. The ROMs also have plenty of empty space to implement a new boot vector with code to set up the 68030 (turn on caches, set up MMU for cacheable/non-cacheable areas) prior to jumping to the original boot vector.
-
I don't know if the software actually uses the MC6800 style Peripheral Access, but there's circuitry on the Processor-Board that creates signals on the VAP-Input Pin.
These signals end at one of the pins of the Bus Arbiter-Chip and seem to have something to do with the master/slave-timing.
The 68030 would be a nice addition to the scope. The fact that it has cache and a pipelined architecture suggests quite a bit of speed-improvement.
It is going to be tricky to get it in mechanically, though. There really isn't much space between the cards.
What's a bit annoying is the fact that it seems like there's no datasheet out there for the bus arbiter-chip on the board.
If anyone knows what a Signetics C2606N exactly is, please share. Judging by the lack of online documentation, I'm currently guessing that it is some kind of ASIC.
I think getting a 68030 in there will require a new board with all or most of the logic implemented inside an FPGA, or is at least easier than trying to get that processor inside the cramped space between the CPU-Board and the GPIB-Board.
In other news, I've installed the clock-generator. As mentioned earlier, it uses a Si5351 PLL to generated the clock for the system. I didn't had any switches readily available and wanted to see if it worked, so I just wrote a very simple Arduino-Sketch to set the PLL to 19MHz, which is divided by 2, set to 50% Duty and scaled to about 4Vpp by the 74S74-Chip, sending 9.5 Mhz to the CPU and the shift-register that is responsible to create the Acknowledge-Signal when a write-operation takes place.
The display does nothing btw. I thought I could use it to display the current frequency, but it somehow didn't work and can't be seen inside the scope anyway, so pretend it isn't there
-
It definitely was the ROMs holding the CPU back.
With the new 70ns FLASH-ROMs installed, I was able to clock the CPU up to 10.5 MHz. Anything above that and it instantly crashes. I'm guessing this time the 10 MHz rated 68010 CPU is the limiting factor.
I'll have to see how much further this can go with faster RAMs (I'll desolder the old ones this weekend). At 10.5MHz, a wait-time for !DTACK of about 220 to 270ns should result in 2 or 3 wait states each time RAM is accessed.
Reducing that wait-time to just 100ns should reduce the wait states to one or perhaps even no wait states at all.
The 4.2 Software holds some interesting features by the way.
New is the possibility to delay a channel by a specific amounts of data-points.
Also the Results-Page doesn't include the time anymore just the date. If you want the time on screen, you have to enable the clock in the Option, which now will stay on screen instead of vanising after returning from the Options-Menu.
I haven't checked any further, but updating to 4.2 is definitely worth it.
The fact that the software is the same for all PM33XX-Scopes also gives further indication that the Key or Configuration-ROM for the options and the scope-type is hidden somewhere inside one of the programmable logic sequencers (precursor to FPGAs). Unfortunately reading and burning those chips requires equiptment more expensive than a good used Tektronix or Philips-Scope with FFT.
On a side-note I've found out why the RAMs run cooler now: They require about 120mA as long as their !CS-Line is pulled low. The shorter that line is pulled low, meaning the quicker the RAM-Access, the lesser is the current draw of the chips.
All in all I'm amazed how much more performance I was able to get from the scope without changing anything but the CPU, which was readily available back in 1987 when this scope-series was released.
Either Philips was trying to save money on components, or the engineers decided to play it extra safe and added massive safety-margins.
PS: According to the internal clock, FFT is down to 9 Seconds with Hamming Window and Logarithmic Scaling turned on / 5 seconds with Rectangle Window and Linear Scaling @ 10.5 MHz and 220ns Wait-Time for !DTACK during RAM-Access. -
Hi SAABfan, interesting upgrade job. My unit came with V5.1 and is appears also to be universal 3320A/23/40
Will try some of your tricks soon
Eric
-
Well, the new RAM-Chips don't work. Individually, they test as OK in my programmer, but inside the scope they don't work.
I suspect they don't have the driving-capability for all the TTL-Inputs on the bus, or the pins of the adapters don't make good contact (when buzzing them out, I saw no problems).
The chips I used were these: IS61C256AL-12JLI
I'll try it next with some other, older chips, but I've got to get them first