Tour : click picture below for previous

Back to Mike's Electric Stuff

Click picture below for next

wpe58.jpg (429289 bytes)wpe7D.jpg (263982 bytes)

Kodak Ektapro 1000 TR high-speed video system

wpe149.jpg (163094 bytes)

New controller project here

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.

kodakpad.jpg (4345 bytes)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...!

wpe62.jpg (533868 bytes)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.

wpe14A.jpg (84554 bytes)  < 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....

wpe146.jpg (382738 bytes)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...

wpe78.jpg (398152 bytes)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)

wpe7B.jpg (375676 bytes)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....

wpe79.jpg (620822 bytes)wpe7C.jpg (803976 bytes)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!

wpe7A.jpg (531077 bytes)(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...

wpeA2.jpg (525858 bytes)Write driver board and eject mechanism controller

wpeA3.jpg (206866 bytes)Spindle motor driver - big power transistors are on heatsink on rear.

wpe95.jpg (386787 bytes)The multi-track head assembly

wpe9F.jpg (87791 bytes)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.    

wpe147.jpg (281914 bytes)

wpe77.jpg (471149 bytes)Inside the imager, "Proxigate" intensifier assembly is on the right (Made by Proxitronic in Germany).

wpe63.jpg (306384 bytes)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...!

wpe76.jpg (184510 bytes)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..!

wpe148.jpg (307111 bytes)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....!


wpe63.jpg (240169 bytes)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.

wpe79.jpg (32682 bytes)Update 8-Aug-05

Not had much time to do much recently, but now we have some nice anti-aliased text for menus etc...!

wpe79.jpg (268253 bytes)10 Aug 05 : It grows.. Another prototyping board added to test ADC performance.

Screen shows output from sinewave input.

wpe7B.jpg (285782 bytes)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....! 

wpe7E.jpg (27646 bytes)

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
I thought it might be fun to tally up the formidable list of supply voltagees that would be used in the final system - 11 different rails (right)

-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

wpe7F.jpg (499915 bytes)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. 

wpe81.jpg (148997 bytes)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

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..!

wpe7E.jpg (176504 bytes)5-Oct-2005 received memory PCB - mostly built now, just waiting on a few bits from Mouser in the US to complete.

wpe7E.jpg (317322 bytes)All the controller hardware built & plugged together...
Board on right contains the PIC that will control it all, plus assorted interfacing and power oddments.

wpe95.jpg (50717 bytes)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...


wpe8D.jpg (49893 bytes)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. 


wpe92.jpg (19954 bytes)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!

wpe93.jpg (41298 bytes)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.....

wpe94.jpg (37822 bytes)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.

wpe91.jpg (249586 bytes)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.  

wpe94.jpg (279199 bytes)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

wpe95.jpg (189974 bytes)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.

wpe96.jpg (208814 bytes)..and finally got round to hacking out a hole for the TFT panel in the front case lid.

wpe9F.jpg (250563 bytes)"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.

wpeA2.jpg (391732 bytes)Intensifier controller PCB, mounted on top of PSUs.


wpe58.jpg (429289 bytes)wpe7D.jpg (263982 bytes)


Click picture above for Previous

Back to Mike's Electric Stuff

Click picture above for next