Kodak Ektapro 1000 TR high-speed video system
Ektapro 1000 system history and resources page
Shortly after having fun playing with a high-speed video camera system I was lucky enough to get access to, I found a similar system on ebay. It had previously failed to sell, so I was quietly confident, and was the only bidder, winning it for the opening price of $375... Plus $600 to ship it to the UK...!!! Still a bargain I thought, for something that I believe sold for something like $70,000+ when it was new!
This system was the predecessor of the 1012EM system I used before, and records images on tape instead of DRAM. It came with the intensifed version of the imager - the smaller box on top is the controller for the intensifier. As well as allowing adjustment of the gain, the intensifier also allows the exposure time to be gated down to as little as 10 microseconds, although I suspect this would require some insanely bright lighting to be useful..!
However on receiving it, I found a major snag - the control keypad was missing. This was a major problem, as although I could get a live image up on a monitor, confirming the image sensor was OK, I couldn't do anything else.
As soon as I saw the size of the tape controller (12x18x24"), and the dubious state of the 2 tapes I got with it, I decided that the eventual aim would have to be to replace it with a more modern DRAM based controller, however I wanted to get the system working at least to the extent of being able to set up the various camera modes & frame rates etc. to help reverse-engineer the imager interface.
After
some hunting, I eventually found a picture of the keypad on the site of a used
test-equipment dealer, and I spent a day or so emailing the addersses of anyone I could
think of who may have had some contact with this system in the past - college labs,
research facilities, high-speed video system distributors etc. to see if I could find
either a keypad or info on the serial protocol it used. A significant problem is that the
Kodak Spin Physics division that originally made this unit had been sold some time ago,
and as I wasn't a 'paying customer', tracking down anyone useful was not going to be easy.
I did get a response from a guy at Redlake (the company who it turns out bought the Kodak
division), and he thought he might have a keypad somewhere but this didn't pan out.
OK, so now to 'Plan B' - reverse engineering time...!
The system is controlled by a 68000 CPU, and as all the electronics are late 1980s-era TTL
and seperate peripheral chips, it wasn't too hard to trace the keypad connection to a 6850
UART chip. I managed to figure out the baudrate and format by observing the baud clock
frequency and how the chip got configured on startup, and started throwing an assortment
of serial bytes at it, to no avail... this was going to get complicated. I also
established that the rear-panel RS232 port (controlled by a second 6840) did not seem to
be active as sending characters to it did not produce any signs of activity on the UARTS's
interrupt pin.
I took copies of the system ROMs and ran them through a 68000 disassembler, producing a
listing of about 60,000 lines of code. I was going to have to figure out the serial
protocol by hunting through this code, starting at the lowest-level code that serviced the
UART interrupt, and working back through the structure of the code to get an idea of what
it was looking for.
Although this may sound like an impossible task, I knew otherwise as I had considerable
experience of doing this from a past life when I spent a lot of time reverse-engineering
comms protocols from code in applications that are probably best not gone into here...!
I dug out and blew the not-inconsiderable amount of dust
off my old HP 1650 logic analyser. I've probably not used it for 12 years as it's that
long since I had any dealings with a processor whose address & data buses were
accessible, but knew it would come in useful one day. (Image right - Analyser probes
attatched to the bottom of the 68000 processor PCB)
Logic analysers, and in particular state analysers, are an indispensible
tool for jobs like this, as they take a lot of drudgery and guesswork away from tracing
though disassembly listings. When set up correctly, you can get a snapshot of the
processor's execution, showing all program memory fetches, as well as RAM and data I/O
operations, complete with addresses and contents, and bus states decoded to meangful
symbols (e.g. "byte read", "word write" etc.).
For example to find the UART interrupt service routine, Just set a trigger on the UART's
chip-select pin, send it a serial byte, and the HP analyser's sate listing shows the
sequence of instructions that executed as a result. Cross-referencing this to the
disassembly listing immediately gives a place to start looking at how the received byte is
handled, where it's stored, what values are checked for etc. State analysers are useful
for many aspects of code tracing in general, often allowing you to not look too hard at
the fine detail of what code is doing- e.g. instead of trying to figure out if a branch is
taken by looking at all the code leading up to it, you just set a trigger at its address,
and look at the code execution to watch which way it goes. Another example is where the
code is looking at the contents of an important-looking RAM location, just trigger on its
address to find out not only what the contents are, but other triggers can be defined to
see where else it gets accessed, what values get written in what circumstances etc.
< Logic analyser trace display. This
corresponds to the disassembly listing below. Even if you're not too familiar with 68000
code (I'd never seen any before...!) you can see how much more information the analyser
trace provides, revealing for example that D0 has a value of 0057 when written to 837C0
(line +0007), the branch at 42B5C is taken (the read from 42B5E is due to the CPU
prefetch), and the value 0052 is read from 837C0 (line +0017).
00042B50 33c0 0008 37c0 MOVE.W
D0,A_000837c0
00042B56 4a39 0008 65e0 TST.B A_000865e0
00042B5C 670e BEQ B_42b6c
00042B5E 0c40 0056 CMP.W #0x56,D0
00042B62 6708 BEQ B_42b6c
00042B64 0c40 0070 CMP.W #0x70,D0
00042B68 6402 BCC B_42b6c
00042B6A 60c6 BRA B_42b32
00042B6C 3039 0008 37c0 MOVE.W A_000837c0,D0
00042B72 0c40 0072 CMP.W #0x72,D0
The serial protocol turned out to be pretty involved, with mechanisms for acnkowledges,
retries and rejecting duplicate keypress messages, but after about a week or so of
disassembling and logic-analyser-ing whilst prodding it with various serial data, I'd
figured out the basics, and could make it do things like switch between live & stopped
modes, eject a tape and a few other oddments. but I was starting to hit a brick-wall
trying to figure out how the menus on the keypad screen worked.
It's hard enough to figure out a comms protocol to a user interface keypad like this, but
it really doesn't help if you've never seen one for real, and have little idea how the
user interface should look to the user. I didn't even know how all the buttons were
labelled as the picture I had was too low-res to tell anything but how many there were.
The code was also starting to get very hard to follow, as it appeared to have been
generated by a compiler that was a very enthusiastic user of pointers to lists of pointers
to menu things that point to other things indexed by the phase of the moon, or
something similarly tenuous. It also seemed to like copying all the easily readable things
like menu text from ROM into arbitary places in RAM and accessing them via at least two
levels of indirection - a real brain-fryer to try keepin track of.
In desperation I fired off a few more emails to various people in the hope
of finding someone who knew anything at all about this system - even the button labels
would have helped at this stage. I then got back to doing some some real work for a
while.... Fortunately one of these mails found its way to someone who used to have one of
these systems many years ago, and although they had long-since traded up to the RAM based
EM1012 version of the system, still had the old manual, and was kind enough to photocopy
it for me.
This showed all the menus, keys etc, and by relating this to what I had already figured
out, I had it all worked out in about half an hour - yipee!!!!
I could now try to do things with the tapes, but my initial doubts over the state of the tapes and drive were confirmed by some nasty graunching noises and mangled tape. the rubber rollers were worn and starting to decompose, being slightly sticky. Trying to run tape at over 20 feet per second over sticky rollers is never likely to be pretty....
However I
could now set the various different camera frame-rates and frame-split modes (the system
can do partial frames at up to 6000 frames/sec) and look at how these affected the
data going through the imager's huge 79-pin military-style connector (right).
Fortunately the image interface appears fairly straightforward.
The video data is transmitted as 16 simultaneous differential analogue signals,
representing 16 adjacent lines. This is how it achieves the fast readout rate without
needing ridiculously high clock rates. Pixel clock is a fairly civilised 3MHz (although in
the late 80's when this system was designed, this was probably pretty cutting-edge
performance!). The system was designed to run with cables up to 50 feet long (a lot of
high-speed photography involves things like crashes and explostions that you really don't
want to be too near ...!).
The digital side of the interface appears to be about as simple as it could be - a 3.072MHz pixel clock, a 'start of frame' pulse, and 3 static lines that control how the image is 'sliced up' in partial-frame modes. The only minor complication is that the pixel clock changes at different frame rates but in retrospect this isn't really surprising - I'd just not given much thought to how lower rates would work.
See next section below for progress on replacing this humongous tape system with something more sensible...
]Meanwhile hare are some pics of the insides of this beast...
The tape mechanism. This uses special tape cartridges, running at up to 250
inches per second! The battery shows the scale of the motors. Dark mark on right-hand
yellow roller is oxide ripped off the tape by sticky deteriorating rubber...
Note considerable size of motors (9v battery for scale)
The VHS from Hell....!
Each hub of the custom-made cassette has a ball-race bearing, and construction in general is somewhat industrial.
I wonder how much these tapes cost originally....
Main card-cage (left) and contents (right)
This lot puts out a serious amount of heat!
The whole unit is absolutely stuffed with electronics, and not a surface-mount component in sight!
(left of picture) PSU regulator board. There is also a huge
switchmode PSU in the base, plus a big ni-cad battery pack whose sole purpose in life
seems to be to stop it tearing apart the expensive tape if the power fails while
running.
(right of picture) Tape drive controller board
More disassembly.... Stripping down the unit revealed even more boards tucked away in
various hiding places...
Write driver board and eject mechanism controller
Spindle motor driver - big power transistors are on heatsink on rear.
The multi-track head assembly
The read amplifier
hybrid with the lid popped off
Another imager..
I was pleased to get the intensified imager with the system, as it would make it much
easier to use at sensible light levels, but the penalty is significantly poorer image
quality - at the highest gains the image is very noisy, and even at the lower settings the
image has a rather grainy appearance.
I spotted another intensified imager on Ebay not long ago, and bought it mainly so I had a
spare - designing and building a new controller would be a huge amount of work, and a
small 'accident' with a power supply or whatever could render it all useless - as well as
the precious high-speed image sensor, the imager contains a large number of specialist or
custom ICs (Many Plessey ICs with numbers starting MOH - as I couldn't find any data on
any of them I think they may have been custom or at least somewhat specialised) that would
be impossible to replace. When I received it, I found that although the imager appeared to
be OK, the intensifier looked like it was dead - as I wanted a non-intensified imager
anyway for better image quality, I didn't spend too much time investigating & stripped
out the intensifier with the intention of converting to to a non-intensified imager. After
pulling the intensifier apart apart, I'm 90% sure the tube was dead anyway.
Inside the imager, "Proxigate" intensifier assembly is on
the right (Made by Proxitronic in Germany).
Testing the newly 'untensified' imager with a makeshift set-up involving
much Blu-Tak..
I needed to check that the optical interface of the sensor would work OK on its own - it had been encapsulated & polished, and was fitted in direct contact with the fibre-optic face of the output end of the intensifier, with some sort of grease inbetween, presumably to avoid an air gap and get a consistent refractive index.
Fortunately I was greeted with a nice crisp image, so at some point I will do the
requisite metal-bashing to fix it all together properly. And then look for some bright
lights...!
The face of the sensor after seperating from the intensifier.
Apparently it's an NMOS sensor, not a CCD.
This chip is by far the most unique and valuable part of the system and would probably
have originally cost many thousands of dollars..!
Another recent acquisition from a radio rally (Hamfest) - a wide-aperture TV
Zoom lens, to help squeeze as much light as possible in, and the zoom should allow
recording of things that you don't want to get close to.
At least as important though, the combination of the already quite big imager, and this monster lens looks really impressive!
Building a new controller
Work In Progress.....
I've been wanting to get into using FPGAs for a while, and now I have a meaty project to get stuck into - I find the best way to learn about something new is to have a 'real' project rather than just tinkering around, as you have to work through any problems rather than just flitting on to something else when you get stuck.
I bought a Xilinx S3 starter kit to use as the basis for the processor. This contains a 200K gate FPGA and plenty of connectors for hanging external circuitry on to.
Current plan is to use eight TI THS10064 simultaneous-sampling ADCs doing 2 channels each, producing a 64 bit wide datastream into a 512Mbyte SDRAM DIMM. For readout, the 64 bit bus will be multiplexed down to 8 bits to reduce the number of FPGA pins required - there is no benefit in using a wider bus, as the data needs reading out a line at a time for display, and adjacent bytes will correspond to vertically adjacent lines.
SDRAM was chosen as available capacity on one DIMM is sufficient, and DDR is substantially more complicated to drive, and I don't need the extra speed. 512MBytes will give about 10 seconds' recording at 1000 frames/sec.
I spent a while looking at possible ADCs - there seems to be a gap in most
manufacturers' product range between the slow stuff up to a few hundred Ksamples/sec, and
the stupidly fast stuff at 20-30Ms/sec upwards. The THS10064 seems like a good fit, as it
will sample 2 channels simultaneously at 3Msamples/sec, and also has a fifo. The latter is
very useful when used in conjunction with SDRAM, as to get the best throughput from SDRAM,
you need to use burst accesses. The ADC FIFO allows 8 words to be read in a short burst,
leaving time to do a SDRAM burst-read and refresh cycle inbetween, to provide apparently
'simultaneous' write and read operations, so a live image can be displayed whilst
recording.
The ADCs and SDRAM DIMM will be on a 4-layer PCB that will plug onto the A1/A2 connectors
on the S3 board, and the other connector will talk to a PIC to do the high-level control
& user interface.
Output will be to a built-in TFT LCD, probably 800x600, producing a greyscale display for
images and status (and maybe some pretty colours for something or other..),. plus a CCIR
(PAL) video signal for feeding to a DVD recorder, external monitor etc.
I'm hoping to be able to generate the VGA and CCIR outputs simultaneously. Display image data will be read from the SDRAM into two alternating line buffers for display. The line buffers will compensate for the different timebases for reading and writing, as well as allowing for easier line doubling/trebling to display the 192 pixel high image as 384 or 576 pixel high on VGA or SVGA TFT panels respectively. The Spartan-3 FPGA has several 2kbyte dual-port RAM arrays which are ideal for this. Another of these arrays can function as a pixel lookup table to allow for greyscale adjustments like gamma correction of required.
At some point it will probably also get a USB2 interface to dump the data
quickly to a PC, but I think I have plenty to be getting on with for now....!
Progress......
A couple of days' tinkering with the FPGA board & a
surplus 12" 800x600 TFT panel..... Display is arranged as 240x192 main display
(pixels triplicated to 720x576 to fill screen), a status line along the bottom and an area
to the right for displaying menus etc. Until I get some real data, the display shows a few
test patterns selected by the switches. FPGA VHDL code here -
excuse any un-prettiness - it's the first thing I've ever done in VHDL...!
Data on TFT panels is pretty scarce, but panels of the same type seem to be pretty similar interface-wise. You need to make sure it has a TTL type interface (3V logic levels), not a high-speed LVDS one - VGA TFT panels tend to be TTL, SVGA can be either, anything bigger will usually be LVDS. TTL panels typically have a 41-pin connector (6 each red,green,blue data, HS,VS,Data En and clock).
LVDS ones will have far fewer lines on the cable, usually twisted-pairs. I
would guess that later panels have integrated LVDS decoders, but I just looked at a common
800x600 panel (Samsung LT121S1-101), and it uses a Nat.Semi DS90CF562
receiver - this seems to provide a 'transparent' interface between the LVDS and TTL
interface, so to get one of these panels working, you could either use a DS90CF561 encoder
to drive it (scrap laptop PCBs would be a good source, but they are also available from
Digikey), or remove the LVDS receiver chip and connect to the TTL interface. pads. It
might be possible to drive the LVDS interface directly from the FPGA but I suspect the
timing would get a bit hairy due to the high clock rates involved...!
There are some TFT pinouts here
and here.
Here are some full
data sheets, which will usually roughly correspond to other panels of similar type.
Update 8-Aug-05
Not had much time to do much recently, but now we have some nice
anti-aliased text for menus etc...!
10 Aug 05 : It grows.. Another prototyping board added to test ADC
performance.
Screen shows output from sinewave input.
21 Sep 05 - first thing vaguely resembling an image....
Imager timing is being driven by my board - the old system chassis is only being used for power. This is a lash-up to prototype the imager-to-ADC interface.
As there are 16 input channels, and there is a lot of high-frequency crud floating around, I want to put everything from the imager input to the RAM on a single 4-layer PCB, so I need to be fairly sure the input amp worked reasonably well - track-hacking each of 16 channels on a dense surface-mount PCB later would not be fun!
One of the 16 channels is being digitised and displayed as compressed 'slices' on the LCD.
The ADCs seem a little fragile - I've melted 2 of them so far....!
 |
As the original system was now only being used for power, I thought it would be a good time to build a power supply for the imager so I could clear a few square feet of bench-space taken up by the old system.. To keep things simple I decided to use a seperate PSU for the imager &
worry about the supply for my new bits later. The PSU was built entirely out of stuff I
had lying around - a 24V switchmode supply from the spare intensified imager controller,
some LM2575 switchmode regulators, a couple of LM317's and a DC-DC module to generate the
negative rail. The imager needs rails of -6.5V, +6.5V, +5V, +22.5V and +18V |
-6.5V | Imager |
| -5V | Video input amplifiers | ||
| +1.5V | FPGA | ||
| +2.5V | FPGA | ||
| +3.3V | FPGA, SDRAM, ADC Digital, TFT Panel | ||
| +5V | Imager, PIC, ADC Analogue | ||
| +6.6V | Imager | ||
| +8V | Video Input Amplifiers | ||
| +12V | LCD Backlight inverter | ||
| +18V | Imager | ||
| +22.5V | Imager |
25 Sep 05- a major milestone - the imager is now
operating completely independently of the original system, and displaying a recognisable
image. The only remaining part of the original system is the connector board that breaks
out the connections from the big round military-style connector (left) to more sensible
IDC connectors - this will be incorporated into my controller.
As only one of the 16 analogue video channels is being digitised, the
image is a series of slices, like looking through a set of shutter blinds. However this is
good enough to evaluate image quality, noise and bandwidth of the video amplifier so I can
finalise the layout of the ADC/memory PCB.
Layout of the ADC/Memory board is now done. This
four-layer Eurocard-sized PCB contains 16 differential video input amplifiers, 8
2-channel ADCs, a 512MByte SDRAM SIMM, some bus multiplexing to funnel the 64 bit SDRAM
bus down to 8 bits, a DAC to set the black/white levels for the ADCs, and an interface to
a USB2.0 module (from http://www.quickusb.com)
Fortunately I took some time to check it carefully, and found a problem
with the bus-steering logic that required a minor redesign of the decoder - instead of the
original 74AC138, a small GAL would be needed. Unfortunately, '138 was in an SSOP package
buried right in the middle of the PCB, and as they don't make 20 pin SSOP packaged GALs,
and a PLCC20 wouldn't fit, there was no space for it. Instead of doing a major rip-up I
decided to just put the GAL on a little vertically-mounted sub-board. Anyway, it
would be sitting next to the SDRAM DIMM so shouldn't look too out of place..!
5-Oct-2005 received memory PCB - mostly built now, just waiting on a
few bits from Mouser in the US to complete.
All the controller hardware built & plugged together...
Board on right contains the PIC that will control it all, plus assorted interfacing and
power oddments.
Underside view. The Spartan-3 board has only one ground pin on each of the two
connectors, which is not really sufficient for reliable operation at high speeds due to
inductance. Fortunately the inner ground plane on the board is the one nearest the bottom,
making it possible to grind down the PCB to expose the plane and solder some extra links
to connect to the groundplane on the memory PCB.
Most of the components on the underside are decoupling capacitors and noise filtering inductors for the ADCs.
Miraculously there was only one error on the memory board, hence the white wire...
9-Jan 2006
More progress - implemented the SDRAM controller.
First thing that looks like an image, but only just. Something clearly not right with the SDRAM addressing, and the data seems to be going negative at some point...
The addressing is somewhat involved, as the data comes in 16 parallel channels from the imager, and is then rearranged into 8 interleaved channels by the ADCs, and then for readout the 64 bit SDRAM bus gets funnelled down to 8 bits before being written to a 2-line de-interleaving fifo memory for the LCD display.
A heart-stopping moment..... moving the imager around
to try to figure out the addressing problems, and suddenly BANG..
The imager connector shell found its way to an exposed mains-live lead on the PCB of one of the power supplies. Fortunately it was well earthed, and the only damage was a fuse in the PSU.. Phew!
Nearly there... after figuring out the address problem,
still some odd negative things happenning.
Then I remembered the ADC had a mode bit to select offset or 2's complement output formats.....
Bingo!. Proper pictures at long last.
Fortunately I'd already written most of the PIC code to to the record/playback control, so as soon as I had a proper picture I could do some recordings. Unfortunately it's now late in the evening, and the workshop lighting isn't really up to doing anything exciting, even with the image intensifier - will have to wait til tomorrow to play...
The only thing left now is to get the USB link working so I can get the images out of the box.
Slight hold-up waiting for a new firmware version for the USB2 module, so
decided to tidy things up.
The new controller in its box, which originally housed the cassette
conditioner (this was a unit that as fas as I can tell wound and rewound the cassettes to
make them work better at the extreme speeds the old tape controller used).
The box underneath is the controller for the intensified imager.
I also decided that it would be useful to have an external video output for projectors or an external monitor, as I'm expecting to use the system for demos/presentations. The original plan was to have a composite video output, like the original system, but this would have been problematic due to the amount of SDRAM bandwidth available and availability of RAM resources in the FPGA for a line buffer.
I then realised that it would be really easy to provide a VGA output, as
the timing was the same as for the TFT panel - All that was needed was to add a DAC onto
the existing TFT data bus, and generate a couple of slightly re-timed sync outputs.
The LCD hinges out for access to the
innards.
Not looking forward to cutting out a hole in the steel panel for the LCD....
Update 10-Mar-2006. First images!!
I've been too insanely busy with Real Work to do anything on this project
for a while, but I'm going to a tesla coiling event tomorrow, so did a mad last-minute
scrabble to bodge together enough software to get images out to the PC.
I got something just about working in time, although it's somewhat flaky, it just about
does the job. Mostly. First image sequences can be seen here
1 Apr 2006.
After using the system at a couple of events, I found that having my
controller and the intensified imager controller in seperate boxes made it somewhat
cumbersome to set up and move the camera around, so as there was some space left, I
decided to build the intensifier controller into the main controller casing.
..and finally got round to hacking out a hole for the TFT
panel in the front case lid.
"Second
floor.. power supplies...."
The 24V switcher on the left now supplies the imager regulator PCB (centre) and the intensifier controller.
Things are getting a little more cramped, so an 80mm fan was added to help the air get around better.
Intensifier controller PCB, mounted on top of PSUs.
