Cp950

[Dave Macaulay]

DBx connectors are quite robust. Yes, some cheapo ones are fragile but I've never found one of those on a decent product. Some solder connectors are crap, with the plastic melting and the pin/socket coming loose when soldered... but buying a good brand like AMP avoids that..
I have also used A DB9-M serial connectors on a PC for hundreds if not thousands of cycles with zero issues.
A typical cinema processor connector might get a few cycles but likely less than 10, often just one connection.
I don't care what pinout is used as long as I can get a cable or adapter to make the required connection.
The variety of pinouts has been a hassle occasionally... and I do not at all enjoy soldering multiple STP cables to a DB25. But I've done that more times than I can count..
If future cinema audio analog DB25 interconnects are all one standard pinout, bravo.

[Steve Guttag]

I crimp my Dsubs...goes fastzero issues. As for standards, we had one...THX...been with us for decades...introducing Tascam, that is where the mix will be. So, instead of having uniformity, we will, forever, have to be prepared for multiples (and for no benefit, which is where my objection comes in).

It is like JBL that decided, long ago to go with reverse polarity on their drivers (as compared to everyone else, and in particular, Altec). And then, in the '90s or so, got religion and decided to join the crowd...except they have legacy systems so any driver that can directly replace an older one (e.g. 2241 directly replaces the 2240), those keep the negative polarity. So, if you are JBL speaker person, a 4641 subwoofer has negative polarity because its driver has a legacy but the identical looking 4645C has positive polarity (2242 driver has no legacy attached to it) and I bet most techs/installers don't keep that sort of info straight.

In cinema we, foolishly, switched to cyan tracks for the last decade (or less) of film's mass production life. So now and forever, sites that deal with film and its archives have to contend with two soundtrack systems if they want them played back properly/optimally. All for a feel-good moment and perhaps Kodak's hope that it would seem slightly more environmental.

For the most part, this doesn't affect me (the Tascam/THX) because I make my own cables and can pin them anyway needed but I do find it to be poor engineering and very poor forethought. There is no technical benefit to the change so it really just introduces inconsistency and potentially causes damage (if input/outputs are joined in a feedback). I guess the CP950 doesn't have to worry about that...no DB25 input. It also defeats the stated claim of drop-in replacement for legacy Dolby processors.

[Scott Norwood]

Scott, have you ever had the serial port on a computer fail because the pins got bent?

Now that you mention it, I don't think so. But the male DB9 chassis connector is really just a PC-hardware thing. Better-designed computers have female chassis connectors. I think that there was some "standard" at one point that DTE devices were to have one type of connector and DCE devices were to have a different gender, but that hasn't be followed in practice. With the result that people now need every combination of DB9->DB25 adapter, gender changers, and straight-through->null adapter.

In any case, you've convinced me here that it makes no sense for audio outputs to be female. Male->female cables make more sense, since they only go in one way and multiple cables can easily be used to extend themselves.

And I also agree that we don't need more types of connectors. We already had the balanced vs. unbalanced issue with DB25s, and now I should probably get myself one of those Odyssey adapter things. The only advantage that I can see with the Tascam configuration is that pre-made XLR breakout cables are available for it, but that seems like a pretty minimal advantage. Isn't the Tascam thing really for recording studios? Is there any likelihood that Tascam devices will ever be connected to cinema equipment?

In any case, my "film festival audio adapter box" gets heavier every year.

[Steve Guttag]

Scott, You are correct about the DTE/DCE thing and the lack of adherence has lead to many techs not worrying about it until things are tested and pins 2-3 need to get swapped (and possibly 7-8). That said, I don't think I've EVER seen a computer serial port that wasn't a male serial port (though now the serial port is pretty much gone but look at the various USB->serial adapters...always male too). Null modem cables, that is a different story though (except for Sony SDDS...curse them!).

[Bruce Cloutier]

So the DTE/DCE thing has a long back story. Originally modems (Data Communications Equipment - DCE) were designed to connect serially directly to a Teletype (Data Terminal Equipment - DTE). This was like 110/300 baud serial. I preferred the KSR33 Teletype (as opposed to the ASR33) as it had the paper tape punch and feeder which were a lot of fun. The chads (punched out portions of the holes, term last heard in relation to an election) made great confetti. Also the punched hole patterns were great for creative art and text (ergo fancy leaders and trailers for tape stored data/programs). Anyway, for that DB25 standard one side was male and the other female.

Then along came the minicomputer (DEC PDP8 being a favorite of mine) to which you connected the Teletype and so the DCE format D-sub appears there on the chassis. And DCE got altered to Data Computing Equipment by some. As we got fancy we had wanted to connect the minicomputer to the modem and, well, the whole standard thing started to fall apart. It gets unbelievably worse when you start to want to implement the hardware handshaking (you know RTS, CTS, DTR, etc.). So then the PC comes along and we suddenly have the DB9. Those being less expensive and the DB25 taking the printer parallel port route. Even the serial connector screws have suffered for the lack of standard application. (standoffs or not, etc.)

Quick version and much now being clouded in my memory. At different points in time I've had many different and extremely useful serial break-out boxes, adapters and all of that. These were of high demand and by not keeping these tools locked up I could never find them when I needed them. Today we still search around for gender changer and null-modem adapters.

So along comes USB and the "solution" to the RS-232 debacle. I think the jury is still out on that. I think too there is a parallel story which leads from RCA/Phone jacks to HDMI. That's the timeline where I would look to you guys for a good rant. My personal assessment is that the technology is not necessarily an improvement. I much preferred the days when if there was no audio you quickly found the loose cable. I don't recall rebooting any amps, waiting 15 seconds for connection negotiation, or any of that 30+ years ago.

So I designed the JNIOR and we ended up with female (socket) DB9S. That was c2004 and I don't really remember how much discussion over serial standards was involved with that choice. It just wasn't the critical functionality we were most concerned about at the time. Also the AUX SERIAL port actually was initially a 5-position header like the others around the unit. That port was RS-232 but it was also targeted for RS-485 network applications. Kodak nudged us into the design change to employ the DB9 for that. We just matched the other RS-232 port gender and, well, there wasn't probably enough discussion over that. It just got done. So I am not sure if we are right or wrong or what? It just is what it is. Changing it for religious purposes would just cause all of us more grief.

Um, we have been debating USB. I may take the diagnostic port (lower one marked RS-232) to USB at some point. So you can use the right variation of USB cable that we all have laying around everywhere to make a direct connection with your PC without having to get a USB-to-Serial adapter (for $10). The command line console is available by default on that port.

So while we would like to think that a lot of design thought goes into some of these decisions, sometimes things just happen and then after the fact you kick yourself... repeatedly. At that point you have the legacy issue that has been mentioned. There is no real solution. You just have to be skilled at dealing with it. Most of you guys here can relate.

Um, sometimes companies refuse to follow the standards so they can use proprietary approaches to lock customers in and away from competitors. You all know that.

[Carsten Kurz]

Back in the DTE/DCE times, the role of a piece of equipment was usually well defined. Later, and due to the bidirektional aspect of RS232, roles could change. The same equipment could be used to control another box, or be controlled by another box (as is the case with a JNIOR). So, a strict male/female assignment derived from a clear DTE/DCE role does not always make sense.

- Carsten

[Harold Hallikainen]

Back when RS232 was on DB-25, I remembered "terminal talks on 2" to remember which pin was which. IBM reversed pins 2 and 3 when they moved to the DE-9. I've always thought that bidirectional cables like RS232 and Ethernet should be "reversing" cables. All equipment would have connectors wired the same way and all cables would switch transmit and receive pairs. Now, on Ethernet, terminal equipment is wired one way and switches are wired reversed (swapping transmit and receive pairs). Instead, we have null modem cables, crossover Ethernet cables, auto MDIX in laptops to handle Ethernet crossover, and "upstream" switches on Ethernet hubs or switches. It would be simpler if all cables just reversed transmit and receive. The original Tascam AES/EBU over DB-25 was bidirectional with transmit and receive pairs reversed ( https://tascam.com/content/downloads...-25_Pinout.pdf ).

Speaking of the PDP-8, assembly language programming for it was the first community college class I taught. We used a Teletype model 33 ASR to punch our source code tapes. We'd use the front panel toggle switches to key a simple loader into core, then read in another loader from punched tape. We'd then read in the editor from punched tape, punch out the edited source file, load in the assembler, pass the source tape through twice (two pass assembler!) and punch the object tape. Finally, the object tape was read in and the program debugged using the front panel lights (before LEDs!) and toggle switches.

The PDP-8 had a strange instruction set. It had no stack, so in a subroutine call, the return address was saved in the first address of the subroutine, and a return at the end of the return was an indirect jump back to the start of the subroutine. One instruction I still remember from the PDP-8 is CIA for Complement and Increment Accumulator (or negate it). I still have the book for that class buried in the garage...

I also taught PDP-11 assembly language and really liked the instruction set in it. An instruction consisted of an instruction field, a source register field, a source mode field, a destination register field, and a destination register field. Using these modes and registers, you could get immediate operands, stack operations through indirect auto increment and autodecrement, and all sorts of amazing things. The PDP-11 also introduced memory mapped I/O. There was the realization that memory and I/O are really two forms of the same thing. Output is just storing a value to an address. Input is reading a value from an address. We don't need all those special I/O instructions! Motorola went with memory mapped I/O in the MC6800 while Intel kept separate I/O instructions in the 4004, 8008, and subsequent processors.

Harold

[Steve Guttag]

Back in the day (a bit after Harold's day as the PDP-8 and PDP-11 were there in my youth but not in my college days)...I remember learning about the various CPUs of the day and you'd see this nice Motorola chip/instruction set and then the 8088/8086 stuff from Intel...segmented memory? Are you kidding? And then data and address signals sharing the same physical pins requiring an ALE signal (Address Latch Enable). Of course, that is the chipset we had to deal with! Before the web, a ".com" was an executable and lived in one segment. Fear not, one of my profs waxed prose on Univac and ensured we were taught a little about the company and its machine language.

[Harold Hallikainen]

Early computer days reminds me of the book by Tracy Kidder called "Soul of a New Machine." Great read! Also, the TV series "Halt and Catch Fire" gives an interesting dramatized look at the early PC clone industry up through the start of the world wide web.

Harold

[Bruce Cloutier]

Yeah, my high school received a PDP-8L with a KSR33 Teletype I think maybe as a donation. The machine had the high speed paper tape reader. That was in 1968 I believe and it was my freshman year of high school. Three of us were challenged with figuring it out. So we learned to toggle the bootstrap from memory. Now that was something really enlightening as it was an extremely optimized self-modifying piece of program code. From less than a dozen instructions it would get the machine to complete the boot from the high speed paper tape reader. Yeah so I was coding PDP-8 assembly as a freshman in high school c1968 (interrupt driven stuff too). We could run the assembler, FOCAL and BASIC. The high school didn't offer official programming until my sophomore year when they taught BASIC. Generally that meant that we helped students run the programs. Senior year we upgraded to a 4 user PDP-8e. So we... well basically the Chess Club ran the computer lab. Long live geeks!

Harold, I think we managed recursive routines with that subroutine structure somehow.

Off-topic are we?

[Scott Norwood]

Early computer days reminds me of the book by Tracy Kidder called "Soul of a New Machine." Great read!

I will second that recommendation.

[Mark Gulbrandsen]

I wouldn't even consider Dolby for cinema sound any more since there is a much better option these days. But I also understand the Dolby might fit right into someones directional sound system.

Mark

[Bruce Cloutier]

Back on topic... Are adapters and cabling an ongoing issue for many of you? Or is it more about documentation and knowing which cable is appropriate? I guess you have to have the right cable on-hand once you know which it is. Are the DB25s the biggest issue or does this same issue apply to other connectors?

It is not just about what connector and what pinout but then about the detailed signals. You assume some standards w.r.t. video and audio inputs and outputs but still run into challenges. PCM or analog? With serial communications there is the standard (RS-232, RS-422, RS-485 etc.), the direction (IN our OUT, RX or TX, and the naming is sometimes relative to the wrong device), the communications rates, and format. Beyond the signalling then there are protocols. Even digital I/O is challenging. Are those outputs relay contacts or voltages? How much can they drive? Are inputs isolated, TTL, pull-up or pull-down resistors?

With the JNIOR we've stuck to one type of digital input and output. Not because those are the perfect choices but to limit confusion. All of our outputs are dry contact relay closures. Yet, you still need to be concerned about inductive loads and contact damage. That sometimes requires an added external component. Our inputs are isolated and have been the same circuit since Day #1. I don't know who came up with that circuit but we haven't moved away from it so as to not create issues.

But i am acutely familiar with interconnection issues. It has been running away from us with things like USB and HDMI. I mean those interconnection issues are not easily solved by those of us on the implementation end. They are supposed to be solutions but...

Not all of us are handy with the soldering iron either.

I am just wondering how much of an issue all of this is?

[Steve Guttag]

Bruce, if adapters and cables were not an issue, Odyssey Products would have a substantially smaller business! Changing standards after establishing one decades ago just introduces an unnecessary change that only benefits the few instances of the unprepared and ensures any replacement to previous products will be incompatible and require a cable change or adapter boards. Likewise for changing gender of output connectors after many decades of established convention not only tries to fix an essentially non-existent problem, introduces a real potential problem.

[Marcel Birgelen]

Back in the day (a bit after Harold's day as the PDP-8 and PDP-11 were there in my youth but not in my college days)...I remember learning about the various CPUs of the day and you'd see this nice Motorola chip/instruction set and then the 8088/8086 stuff from Intel...segmented memory? Are you kidding? And then data and address signals sharing the same physical pins requiring an ALE signal (Address Latch Enable). Of course, that is the chipset we had to deal with! Before the web, a ".com" was an executable and lived in one segment. Fear not, one of my profs waxed prose on Univac and ensured we were taught a little about the company and its machine language.

We had a bunch of legacy PDP-11s back when I was still studying at the university, but I've seldomly encountered them in production. The architecture of those machines was pretty advanced, given the time. There was a ton of peripherals and custom-built gear that could interface with the Q-Bus. I remember some of them running a special OS called MONECS, which was built for educational use. It featured a built-in Pascal interpreter, which was all hipster back then.

What I did encounter all over the place is DECs MicroVAX in various forms, which is considered to be the successor of the PDP-11 line of machines. It also implemented the Q-Bus as a legacy option. I still remember those cringe-worthy CLI commands for VAX/VMS... VMS still must be one of the stranger OSes I've encountered along the line, but it's notable because it implemented a Virtual Memory system, all the way back in the late 1970s. VMS still lives until this very day in the form of OpenVMS.

It is interesting how over the years, the way inferior x86 instruction set survived until this day. Even back then, there were far better options available. Heck, Virtual Memory and even the concept of processor-backed Virtual Machines all existed back when the first "PC" was brought to market.

In the end, the reign of the "Intel CPU" comes down to being cheap and readily available. But it looks like Intel has a major competitor with ARM nowadays, being used as a cheap alternative for almost anything that's too complex for a simple MCU.