On Apr 11, 2005 10:37 PM, Jay West <jwest at classiccmp.org> wrote: That reminds me of the HP line of protocol analyzers (HP 4951A/B 4952C...) I used to live with one of those, too, when I was doing SNA and Bisync for a living (prior to 1984). I don't know anything about this brand or what it would take to hook this one up to anything but a V.35 connecton (useful in itself), but if anyone is going to do any serious serial hacking, I cannot recommend these sorts of tools strongly enough. They would be perfect for, say, reverse-engineering a poorly documented serial protocol between two devices, or, as we used ours, for verifying that one end or the other is really adhering to the published protocol. The HP line also has a menu-driven programming language that is barely sophisticated to emulate an IBM Mainframe and communications controller (CPU + 37x5) initiating an SNA session through the bind and up to idle RR chatter (1Hz ACKs with sequence counts that fill a channel that isn't actively pumping data). _That_ was incredibly useful for debugging some SNA product issues we had, as we could tweak individual bits of our binds to see empirically what the effects were on our products (we purchased the core code rather than writing it all in-house, so we were often forced to poke it from strange angles to see how it wobbled). These could also be useful for debugging a low-speed connection (well under T1-speeds) between a router and an ISP. They also make good password sniffers ;-) presuming one can wedge in between the VT100 and the host (no, we never really did that at work, but we did show folks how easy it is to do). Lots of fun, but I suppose a modern PC could do just as well, presuming there's an app that's designed to capture and display whatever goes by the serial port. -ethan

On 4/12/05, Vintage Computer Festival <vcf at siconic.com> wrote: The physical cable used with HP line analysers is a simple Y-split - 25-position ribbon cable, two DB25F and one DB25M (or the other way round... can't quite remember). You can wedge the cable between two devices, then attach the free end to the HP pod (or just plug a DB25 cable right from one unit direct to the pod if you are using the HP to originate or consume bits) What I'm not sure of is if the HP pod has anything special in the way of drivers/receivers to keep from loading the line as it monitors things. I could open up a pod and see what's inside... -ethan

On 4/12/05, Vintage Computer Festival <vcf at siconic.com> wrote: The HP cable itself is quite ordinary... pin 1 to pin 1... pin 25 to pin 25, with each pin going to the pod as well as between the two devices. The magic in this case is going to be in the pod, not the cable. One can certainly build an integral pod/cable, but that's not what HP did. They kept the cable itself as simple as possible. I don't know for sure what's in the pods, but now that we are disussing it, I do seem to recall that I heard relays clicking when entering and exiting monitoring modes. There is plenty of room for passive and not-so-passive components in there as well. -ethan

On 4/13/05, Tony Duell <ard at p850ug1.demon.co.uk> wrote: That's what makes the dedicated devices like the HP 4xxx so handy... they can monitor or emit bytes with the same cable, depending on what you are asking it to do. The downside is, naturally, that lots of people have serial ports on PCs and not many people have dedicated line analyzers. For the majority of uses, I would expect people need to monitor, not generate traffic. -ethan

Don't wait. Ethernet and USB have been in _common_ use for some time now. in a couple of years all the golden age RS232 protocol analyzers will be thrown out. John A.

On Apr 12, 2005 9:47 AM, Jay West <jwest at classiccmp.org> wrote: The 4951A and 4951B use TU58-style data carts (down to the capstan turning to goo). Unlike a DEC TU58, the HPs format blank tapes. The 4951C uses a 3.5" floppy. Beyond that, there are different 'pods' for the physical layer. All of them attach to the analyzer in the back and provide some sort of traffic light functionality, plus a suitable physical connection (DB25, DC37...) for the physical standard in question. I have one RS-422 pod, and one RS-232 pod, and I forget what the 4951C pod is, but probably RS-232. Presuming one has a 495X with DB25 RS-232 pod, all of the models I have do sync and async just fine, ASCII and EBCDIC, have the internal programming language which can trigger captures on in-band data, etc. The 4951C has an optional terminal (VT100) app that is on a copy protected floppy, and I don't know if it's possible to buy it from HP anymore. Obviously, with capture media being the way it is, I'd recommend a floppy-based HP if you need to save sessions. If you don't care, and won't be doing extensive protocol programming, even the tape-based ones are great. All I can say is that my experiences with this line of protocol analyzer have been great, and if you are snooping non-exotic connections, probably any of them will work fine. If you have some bizarro need, you might want to google up particular models as you see them appear on eBay (item 7506826828 has a good picture of a 4952A, as an example.) Prices sure do seem to vary. Glad I already have a few working ones. The non-working ones go cheap, but I have never had to fix one, beyond the mandatory gooey capstan replacement. -ethan

On Apr 12, 2005 9:32 AM, John Allain <allain at panix.com> wrote: That's how I got my 4952C... nobody at work remembered the last time it got used, and it was n't useful for debugging our connectivity to the outside world, so out it went... -ethan

I haev a Tekky 835 which does most of what you describe. It only has a single-line display, but as you scroll through the captured text, a status LED shows whether the character came from the DTE or DCE. This device can also simulate a DCE or DTE, so you can use it for testing serial peripherals on their own. I also have a crazy decvice called a 'Ferret'. It's built into an ABS case, a bit like one of those attache' cases. It combines the functions of a breakout box, protocol analyser (but only for async data I think), RS232 - current loop converter (and you can have different baud rates on the 2 sides!), RS232 - centronics converter (I think it does dataproducts parallel too), perallel printer tester (in other words you can send messages to a Centronics printer), RS232 printer (there's a little built-in strip printer, like the one in an Epson HX20), EPROM programmer (!), you can even download and run programs on the built-in Z80 processor. There;'s even a cassstte interface to save the contents of user memory. I really must dig it out and get it going... -tony

Well, the lid of the case has a pocket that holds the user manual, cables, etc. There should be space for my trusty Leatherman too :-) -tony

----- Original Message ----- From: "Jim Beacon" <jim at g1jbg.co.uk> To: "General Discussion: On-Topic and Off-Topic Posts" <cctalk at classiccmp.org> Sent: Thursday, April 14, 2005 7:20 AM Subject: Re: Navtel 9460 Protocol Analyzer info? snip IIRC one of those 'polar relays' is not- it's actually the QBF message generating coder-a very clever little electromechanical device with a "disc" memory. And that spiral timebase was something else - very clever - more modern TDMS variants with linear displays were never the same..... DaveB, NZ -- No virus found in this outgoing message. Checked by AVG Anti-Virus. Version: 7.0.308 / Virus Database: 266.9.8 - Release Date: 13/04/2005

----- Original Message ----- From: "Dave Brown" <tractorb at ihug.co.nz> To: "General Discussion: On-Topic and Off-Topic Posts" <cctalk at classiccmp.org> Sent: Wednesday, April 13, 2005 10:27 PM Subject: Re: Navtel 9460 Protocol Analyzer info? You're quite right Dave, but as it's missing, I was saving on the typing :) Jim.

On Mon, 11 Apr 2005, Jay West wrote: I used a PC-based software scope that worked fairly well. And yes, it was a definite must-have for any serious serial-based development work. -- Sellam Ismail Vintage Computer Festival ------------------------------------------------------------------------------ International Man of Intrigue and Danger http://www.vintage.org [ Old computing resources for business || Buy/Sell/Trade Vintage Computers ] [ and academia at www.VintageTech.com || at http://marketplace.vintage.org ]

On Tue, 2005-04-12 at 20:46 -0500, Scott Stevens wrote: False :) USB to serial and PCMCIA to serial exist, and they're cheap, especially the USB job. Of course, the laptop would have to be relatively modern, say a Pentium I.

On 4/13/05, Scott Stevens <chenmel at earthlink.net> wrote: How about one Z8530? :-) [it's a DUART, for the Zilog-impaired] The "problem" with picking something like a SYM-1 is that it lacks a suitable output device. A few digits just isn't all that useful when picking through a stream of serial data. I would have to say with my HP experiences, that a Commodore SX-64 is about entry-level for that, just because it's portable, has an expansion port for the serial chip, and has a built-in 40-col screen. That having been said, a real HP isn't much more expensive than what the SX-64s go for, and it's 1/2 the size and weight, and is already set up to do the job. In principle, I don't see a problem with trying to roll your own line analyzer, but having written a lot of code that bangs on Z8530s and 8250/16550s, I'm really happy that I have a working, ready-to-use bench tool to watch the serial stream for me. For what an HP eBays for, I can be up and snooping a whole lot faster... a time/money tradeoff that _I_ would load the money side of the equation for. -ethan

I don't think so, not per se. No, that's right as far as it goes - most SPARCstations, at least. Well, _one_ of the lunchbox SPARCs. (The others are the IPC, the IPX, and the LX.) While this is true of the 8530 *as used in the SPARCstations*, this is largely because of the clock Sun chose to drive it with. Use a faster clock and your baud rate cap goes up correspondingly. (Presumably there is a limit on the clock rate, but I don't know what it is; I'm fairly sure it's well above what Sun uses, at least.) Now, depending on the associated electronics, there may be other limits. For example, the 8530 has discouragingly little buffering on-chip; to run at high baud rates you will need to either (a) add buffering in front of it, (b) handle a relatively high rate of interrupts, or (c) do some rather delicate bare-metal tapdancing. /~\ The ASCII der Mouse \ / Ribbon Campaign X Against HTML mouse at rodents.montreal.qc.ca / \ Email! 7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B

On 4/14/05, Scott Stevens <chenmel at earthlink.net> wrote: I should look at that code sometime, mostly out of curiosity. . If I'm not wrong (from my cursory glance over the My recollection of it with COMBOARDs is that the most important thing is not to feed the chip too fast from the bus side. The second most important thing is to understand what register you are accessing and calling it up properly. We were using the 4MHz parts with an 8MHz 68000. Our design was basic - a single PAL to handle address selection and R/W sorts of things, and a simple interrupt design. No DMA. We were only dealing with speeds up to 64kbps sync serial, so the lack of DMA didn't kill us. The 4MHz parts just about did. The code that thwacked on the serial chip took a while to refine to a simple set of elements that worked reliably. One trick I remember was that we *always* made sure to have some minimum number of cycles between picking and internal register, and accessing that register. The most ordinary technque was a fixed number of NOPs after writing to the initial register. I don't know anything about how the SPARCs or the Mac interfaced to the Z8530, but our design was particularly inexpensive, but it was fast enough to talk to the required interfaces. Even so, there _were_ tips and tricks we'd learned the hard way. As I said, I should have a look at the NetBSD code and compare tricks. It's still a nice chip, especially if one wants to talk sync or async multi-character internal buffer (Z85230?), but it's much less common than the original. -ethan

On 4/13/05, Scott Stevens <chenmel at earthlink.net> wrote: That's a SPARC design-dependent limitation... the same Z8530 is used in the Macs as an AppleTalk/LocalTalk controller. We used the Z8530 in our Qbus and VAXBI COMBOARDs up to 128kbps (and no faster because of external device compatibility, not any inherent speed limitations. Limitations aside, unless you want to scope out T1 or fractional-T1 serial links, the chip is plenty fast enough. In my experience, a lot of the links one wants to scope are between 110 bps and 56kbps, anyway. -ethan

On Thu, 14 Apr 2005 14:52:14 -0700 (PDT) "Eric Smith" <eric at brouhaha.com> wrote: It's probably a problem with Sun's hardware design. I was trying to get it up and running at high speed with NetBSD. I remember reading that there were some 'hacks' to get it running slightly faster than 57,600 baud but only at a few weird non-standard data rates.

On Tue, 12 Apr 2005, Jay West wrote: Mine was different. It was actually made by the company that wrote the C serial library I used in my telecom system. It was called something generic like "Serial Data Analyzer". I'm not sure if I ended up with the cable. At any rate, I ended up with a very nice datacomm analyzer made by GenRad(?) I think. I'll check when I get home. I had it out for sale at a local ham fest last month but then realized how cool it was and jacked up the price to some ridiculous level so that I'd either get an unnatural buttload of cash for it or would get to take it home. I'm glad I got to take it home :) -- Sellam Ismail Vintage Computer Festival ------------------------------------------------------------------------------ International Man of Intrigue and Danger http://www.vintage.org [ Old computing resources for business || Buy/Sell/Trade Vintage Computers ] [ and academia at www.VintageTech.com || at http://marketplace.vintage.org ]