Timeline Analog 2. John BuckЧитать онлайн книгу.
While the CMX 600 unit was now more or less capable of recording and playing video and audio in sync for an editor to make edit decisions, its sibling system, the CMX 200 needed to be able to translate all of those decisions in order to control the high resolution videotape copies of the master material on analog VTRs and ATRs.
Dave Bargen adds:
The second product priority was the Assembler system to be called the CMX 200. It isn't talked about much, because it isn't as glitzy, but it was an integral part of the product plan from the outset. It would take the edit decision information from the 600, and control broadcast tape recorders to produce the finished program
Jim Adams began work on the 200 Assembler.
One of the features of the PDP-11 was the ability to use the input and output ready/busy signals as interrupts under software control. I therefore set up the frame-code ready signals as interrupts and was able to keep track of the location of each (playback and record) tapes.
I keyed off the Real Time Clock (RTC) to analyze the tape position while seeking the in-points for each insert edit and was able to cue the VTR by alternating between Fast Forward and Rewind commands depending on the distance the tape was from the pre-roll target point.
Once all tapes were parked, they were put into play and capstan plus or minus over-ride commands were issued to bring them into synchronization with the counting of the PDP-11 processor. Conceptually this worked very well, but a number of issues surfaced that impacted the operation of the system.
The first was the tape machines did not follow the commands from the processor. I brought this up to the lead digital engineer, W. King Anderson and he assured me that it was a software problem.
After stepping through my code and observing the reactions of the VTRs, I approached King once again and told him that the interface cards were not responding to multiple commands from the processor. King reiterated that even though there were no ready/busy signals from the interface cards, they were much quicker than the PDP-11.
He did ask me how quickly I might be issuing commands, and I told him they would be about 1.2 or 2.4 microseconds apart. This completely surprised him and he said the interface card would take 5 to 8 microseconds to process each command. I added software delays into my code until the cards could be modified with appropriate ready/busy signals.
With the tape machines responding, other problems were exposed: some edit points were occasionally off by a frame, other times the switcher did not respond to commands from the processor.
More insidiously, the PDP-11 would halt with a fault signal and had to be restarted. I reported the issue with the fault signal to both the CMX management and the DEC maintenance people and was assured that is was a software problem.
I began logging each time the fault occurred and it appeared to be very random. I again reported the problem and was told "Software Problem, fix it". After a couple of weeks of this, I set out to find the root cause.
Staying late one evening, I hooked oscilloscopes to the various interface cards and into the PDP-11 processor. After about six hours of testing, plus my logs from the previous weeks, I was confident that I had the root cause of the fault.
Most mini-computers had instruction sets that were all 16 bits (2 bytes) wide. The PDP-11 had different lengths (2, 3 and 4 bytes) for different instructions like most of the large computers. This is a very efficient use of program memory and allows for more complex instructions in the 4 byte instances.
I had obtained the home phone number of the product manager of the PDP-11 and I called him. I asked for him by name and identified myself and said him I had a hardware problem with the PDP-11. He asked if I knew what time it was, and I told him it was midnight in Sunnyvale, so it would be 3AM in Massachusetts.
To his credit, he asked me to describe my problem. I told him that I was using many fast interrupts to drive my software, and if I received an interrupt during the execution of a 4 byte instruction the PDP-11 would trap to a fault error. He thanked me, we hung up and I turned out the lights, locked the doors and went home.
When Adams arrived at work the next day, he was directed to Butler’s office. He walked in to see CMX management plus the regional manager and local sales and maintenance staff from DEC.
He was asked why he had "broken with reporting protocols" the previous evening.
I told them I had tried that twice and was told it was my problem and I should fix it. I never spoke to the DEC people again. I found out later that the Massachusetts engineers knew they had a problem, but I don't know if they knew the exact cause. Perhaps I helped them out with my phone call.
Adams spent the next two days removing all 4 byte commands from his program code and had no further hardware traps.
I did, however, still have bad insert edits and missing switcher commands. The insert edits were occasionally a frame late, and I attributed this to a mismatch between the frame counting of the PDP-11 and the record VTR. As I indicated earlier, the frame count scheme was not 30 fps but was slightly less. I had a frame counting routine in my software, so began to focus on that.
No matter how well I tracked my counter, I could not resolve this issue. After much time observing the video signals and my commands from the processor to the VTR and sleeping on this for many fitful nights, I had an 'A-HA' moment and deduced that the computer RTC had to be tied to the 59.94 Hz video synch and not to the 60 Hz power line.
I kludged (today called 'hacked') together a circuit to make the video synch pulse look enough like the 60 Hz signal that the RTC board in the PDP-11 would react to it. Voilà, all my timing problems were solved. It turned out that if the edit commands to the VTR were late in the frame, the VTR would delay the edit until the beginning of the next frame.
Also the switcher processor was performing internal tasks during the first five or so lines of the frame and would ignore any commands during that time.
I added enough software delay after each synch interrupt to adjust for this timing in the switcher. The VTR commands were now in lock step with the video synch, so were always at the onset of the frame.
Adams went to management with a request to design a new RTC board for the PDP-11 but was told that the clock problem should be solved in software, and there was no money to develop a new board.
Fortunately, I had a good buddy Bob Gilbert who laid out the interface card artwork for CMX. I convinced him to bootleg me a board, and worked out a design from the backend of the DEC RTC board and a synch stripper circuit from one of the video engineers. This board did work its way into the Bill of Materials so all 200's and follow ons had it.
Adams’ discovery, if it had been patented, could have given the company a major revenue stream when others entered the analog editing sphere.
CMX would have been in the driver’s seat for all future video edit systems. With these issues resolved, not in software but with hardware modifications, the 200 software development proceeded nicely and was soon ready.
CMX Systems was part of Memorex’s Information Group under manager John Del Favero. He briefly mentioned the progress of the forty CMX technical, marketing and administrative personnel.
“A prototype system was substantially completed at year-end 1970 and production and