• Please review our updated Terms and Rules here

Cromemco Cyclops 88 CCC board set reproduction

Hugo Holden said:
Further to this post above, now I have time on my hands waiting for parts, I have been pondering the notion of how to protect IC's which in this case are running off two independent + and - DC supplies when it is possible that one supply rail comes up before the other. I think the logical conclusion is that there needs to be a high capacity filter capacitor, say at least 1000 uF connected between the +8V and - 8V voltage terminals, so that in the event that either the + or the - voltage comes up sooner than the other the charge is shared on the capacitor and the voltage comes up more symmetrically about zero, and no harm can come from it.
Click to expand...

The Cyclops camera circuitry is "unusual".
The 2-transistor video output driver (which takes its input from the RAM data output) is powered by +8V.
All other ICs including the LM311, the CMOS ICs, and the MK4008 image sensor on boards ACC-2 and ACC-1 are all powered by +16V. Vcc is established by the output of the +8V regulator, and ground is established by the output of the -8V regulator. The MK4008 DRAM is normally powered by a Vss of +5V and a Vdd of -12V (it requires no "ground" connection) but in the Cyclops camera it is simply powered by putting 16V across Vdd and Vss.
 
hmb said:
The Cyclops camera circuitry is "unusual".
The 2-transistor video output driver (which takes its input from the RAM data output) is powered by +8V.
All other ICs including the LM311, the CMOS ICs, and the MK4008 image sensor on boards ACC-2 and ACC-1 are all powered by +16V. Vcc is established by the output of the +8V regulator, and ground is established by the output of the -8V regulator. The MK4008 DRAM is normally powered by a Vss of +5V and a Vdd of -12V (it requires no "ground" connection) but in the Cyclops camera it is simply powered by putting 16V across Vdd and Vss.
Click to expand...
Yes, it is the way they did it.

I am stuck for a wonderfully plausible theory why the MC14572 IC failed with hot plugging. The input it receives from the regenerated clock signal is significantly current limited to the input of its first inverter with resistors, so even if a substrate diode in it attempted to conduct I doubt there would be enough energy to damage it. And when it failed it appeared to briefly draw a substantial current, enough to reset the whole computer & wipe the memory, That can only have been via its power supply pins not likely via any of its input or output terminals. The only thing I know of which can do this is an SCR like latchup effect inside the IC. Some IC's do this (I only know of a few, one type of OP amp and another a voltage converter) and once it happens it cannot be undone withour power cycling. Mostly though when I have seen it before, the IC just sits there heating up and recovers after depowering it. But this IC is not a particularly complex IC, so I'm very surprised (and a little annoyed) it did it. Mind you the two TO-220 regulators they used in the camera head can support a significant current but they should have gone into shut-down mode when overloaded, so there are some unexplained variables at work. At least I'm getting to know the system better and if it breaks down now can fix it in short order, notwitstanding parts availability.

Protection diodes on all its input would probably help preventing them from signifcantly exceeding the + or - supply pins, but most cmos parts had these in the substrate I think except the very early 4000 series and this chip was a genuine motorola 1988 vintage part.

Ha! Back in business camera running again (this time I have screwed on the D9 connector plug)

I got to thinking what would I do if I was Lost in Space trying to make something work without a part, I wrote an article about this some years ago fixing an IBM Async Card:


Looking at the circuit I realised just to make the camera run it only requires two cmos inverters of the MC14572 part. So what I did was plugged in a 14 pin hex cmos inverter, the CD4069 displaced in the socket so its pin 7 plugged into pin 8 of the 16 pin socket with all other pins except the 4069's pin 7, 8, 9, 10 &11 bent out and not plugged in. This restablished the two required inverters between 12 & 11 abd 9 & 10 of the 16 pin socket. Then a link wire to connect pin 14 of the IC to pin 16 of the socket to power the IC. Then on the back of the board I simply linked pin 1 to to pin 16 and pin 13 to to pin 9 of the MC14572 socket, and this sets the bias lights to on at the hardware level rather than letting software do it. So now I can get back to experimenting with the camera while the parts are in the post.
 
Last edited:
Hugo, if you're in the market for a new job - you might want to look in the Houston area. Haha amazing repair..

Thanks for the warning about hot plugging!
 
I have some more to report:

Firstly on the sensor: All of the chips I have tried , variants of the MK4008 all appear to work fine except one defective one I got. They are all very similar in performance, none have scrambled images. There are some slight differences, for example the MK4008-6 seems a little less light sensitive in that it takes the LED's to be run at full brightness to liff some pixels out of the black, compared to a white package MK4008P (no suffix number) dated 1972. Also some units have zones of pixels (sensor elements in the array) that in dark or low light conditions put out more of a patchy effect with some being more active than others, when lifted out of the black by the bias lights (even with a diffuser making the light from the LED's even). One of the IC's I tried this effect would be too problematic to use it.

None of the chips I have tried are the type that result in a scrambled image.

There is one source of concern, although I don't have the correct lens yet. The overall light sensitivity does seem poor in that it takes a fairly bright light on the image sensor to get a pixel to migrate to peak white, or a data value of Fh in the image file. With the current lens I have, to get an image of a face, in a standard well lit room or even a brightly lit one, the face would have to likely be illuminated with a powerful floodlight.

I investigated a few other things, that 560R pullup resistor on board 2 definitely needs to be there, or the logic high level only climbs up to about 1.7V and without it, it appears to cause a drop in the sensitivity a little more, making the apparent illumination issue a little worse. As an experiment, I modified the byte (bitmask) that @daver2 detected should have been 0F0H in Cromemco's software but was 0E0H. Changing it back to 0E0h made no practical difference I could detect, so its likely better left as 0F0h as @daver2 suggested.

Then there is the issue of the reversed foils on Cromemco's board for the two LSB's. What I did was to use a brignt white LED shone into the center of the camera lens to create a full white blotch in the middle of the image with the light levels fading around it to black. With Cromemco's foil error wiring in place, I captured the image by resetting the SOL and manually re-started the Dazzler with a few lines of code to inspect the image frozen in the Dazzler memory in the 32 x 32 mono mode. It was obvious that the lower 8 grey levels were disorderd, so I used the links I had added to the board to reverse this foil error, this fixed it, and the lower 8 grey levels are now perfectly ordered. I wonder how Cromemco and other users of this system would not have noticed that the lower grey levels were disordered. Maybe most of the people who used the Cyclops did not use it with the Dazzler at all, and used it with the oscilloscope interface instead, or maybe Cromemco did know about it and fixed it on later board revisions.Though I'm fairly sure it was the latest revision boards which had this foil mixup, presumably the earlier one did too. Anyway, what a thing to find all these years later after it was made.

The acquistion of Camera data is interesting. For example, the reset which occurs synchronously with each frame being written (completed) to the Dazzler's image file ( this occurs at a period of 1.5 seconds or 0.67Hz in dim illumination) it the time that the Camera image sensor appears for the duration of a reset, coordinated by U38, a 74193 counter on board 1, and that burst of camera image data out of the sensor IC is only there for about 30mS which is a very small period of time compared to the time taken to process and refresh the image. And interestingly when the sensor is flooded with light, that 30mS drops to a burst of data only lasting about 10 mS and the period between resets seems to slow a little to about 1.76 seconds.

At the moment it appears that the system is likely working as expected, but the overall light sensitivity I think may turn out to be a practical issue, I won't know until I get the new lens. Whether or not the software could be tweaked to help improve it, I am not sure, that would be a good question for @daver2. The fact that there is still a good amount of data coming out of the sensor in low brigtness levels suggests that there possibly could be a way to improve the processing of it, The higher the light levels the less data that appears out of the sensor. Also I noticed that the image sensor currently cannot be in the focal plane of my lens because I placed a plate with a 1mm pinhole in front of the lens and this improved the ability of the system to image/resolve two LED's that were about an inch apart a few feet from the camera and without that they were blended into one object.
 
Last edited:
I tried modifying the value 0Bh on the program sent to port B . Not much appears to be gained altering that lower nibble or the exact number of frames processed, but changing to 1Bh, 2Bh and 3Bh and controlling the number of 2mS intervals does have a significant effect. It lifts the background brighness of all pixels up. For example 1B requires less LED light to get the pixels to start illuminating above black. 3Bh is excessive and they are all too bright even with the camera in the dark. Probably 0B or 1B is a good value depending in the particular sensor chip. Whether this changes the ultimate light sensitivity or dynamic range of the sensor from dark to light, I'm not so sure but it shifts the global levels of the pixel brightness.
 
If you remember (with these two values) the Cromemco documentation was not definitive about whether these started from 0 or 1. Perhaps you could do some tests?

Dave
 
daver2 said:
If you remember (with these two values) the Cromemco documentation was not definitive about whether these started from 0 or 1. Perhaps you could do some tests?

Dave
Click to expand...
Yes, the document suggested that the upper nibble controlled the number of 2mS intervals, so clearly if that was zero the 0x 2mS = 0. But with it set to zero as in the value 0Bh sent to port B, that would not likely have worked, probably it needs a baseline of 2mS.

I think it starts with the upper nibble zero at 2mS, so the formula should be the upper nibble controls 2mS + the upper nibble value x 2mS.

So say if you set it for 1, you get 2 + 2 = 4mS or say setting it for two, you get 2 + 2 + 2 = 6mS etc.

Not 100% sure, but we know the Cromemco documentation had a number of errors both in the schematics and in the software, and it more or less took the two of us working on it to come close to what Sherlock Holmes might have concluded.
 
I think we can forget about the hot pugging of the camera being a worry. I found out why the original cmos chip got destroyed, because the patched in 4069 dropped dead too, randomly and not hot plugging. A piece of wire that I had used to space the sensor board got under the machine pin IC Socket where it was difficult to see, and cause some shorts.
 
Ouch! Well I guess that explanation is slightly better than hot plug issues or a design problem..
 
Don't get too excited , the picture attached is not from the Cyclops camera, it is from the Dazzler in 32 x 32 mono image mode. I created a 16 shades of grey(if you count black as one) and 32 x32 pixel image as a .ENT file to the SOL at the Dazzler address 1600h in memory and I manually activated the Dazzler with a few lines of hex code code to execute: 3E 8B D3 0E 3E 00 D3 0F C3 04 C0 /. It originated from a monochrome .bmp photo compressed to 32 x 32 had the 54 byte leader removed, the extra bytes stripped out of it processed and reformated to suit the Dazzler 32 x 32 mode.

What I was interested in here, was to get an idea, with a perfectly working camera, where its sensor responded well to a good range from low to bright light, what sort of image, at absolute best case scenario one could expect. I think the sensor has logarithmic properties so likely the Gamma won't be too crash hot. When the attached image is zoomed back to the size of a thumbnail it doesn't look too bad. On the 9" VDU the image is about 5.5"diagonal. Of course the image is stretched on the horizontal axis because it is square and being displayed on a 4:3 ratio VDU so each pixel is stretched that amount.

With the camera, and and lit by a Tungsten lamp about 10 feet away I have manged to get an image of my hand. The trouble is with the current lens I have its too wide an angle, I'm still waiting for my new lens to arrive.
 

Attachments

  • 32X32.jpg
    32X32.jpg
    48.2 KB · Views: 5
It should be possible to recreate the Cyclops 'camera frame image data' using the bitmap that you created in post #194.

Running the recreated 'camera frame image data' through the Cyclops to Dazzler display software should give you the same image on your Dazzler display...

It is not 100% definitive - because we may have got "two wrongs to make a right", but it would be a step further along the yellow brick road...

Dave
 
One thing I am beginning to wonder about is that history sometimes gets modified. One other example of this, after I replicated Sputnik 1's transmitters, I found that the many recordings of Sputnik 1's radio transmissions on the net misrepresented it. Since it was received on radios as burst of a carrier wave, to hear that as a tone, it required that the receiving radio had a BFO, and clearly listening to some of the historical recordings people are turning the BFO knobs on their radios altering the pitch at the time of the course of the recordings, and the whole experience of listening to the transmissions is completely altered by what an individual did. It was difficult to find an uncorrupted one.

Terry Walker mentioned that the image on the Poupular Electronics magazine cover (lower R corner), was Les Solomon, the editor, was taken with the Cyclops Camera. But clearly, if you examine it, it has been significantly "doctored" and not what I would expect to see on the face of an oscilloscope in X-Y mode. It has been reformated to appear as near equal illumination strips of light with black intervals between. Artistic licence if you like by the "Art Department", but it obscures history and the reality of what the camera would be expected to produce when used with an X-Y oscilloscope, it looks more like the result expected with a coarse raster scan in a two level black-white image scenario.
 

Attachments

  • POPEPERS2.jpg
    POPEPERS2.jpg
    94.6 KB · Views: 6
Last edited:
Hugo Holden said:
One thing I am beginning to wonder about is that history sometimes gets modified. One other example of this, after I replicated Sputnik 1's transmitters, I found that the many recordings of Sputnik 1's radio transmissions on the net misrepresented it. Since it was received on radios as burst of a carrier wave, to hear that as a tone, it required that the receiving radio had a BFO, and clearly listening to some of the historical recordings people are turning the BFO knobs on their radios altering the pitch at the time of the course of the recordings, and the whole experience of listening to the transmissions is completely altered by what an individual did. It was difficult to find an uncorrupted one.

Terry Walker mentioned that the image on the Poupular Electronics magazine cover (lower R corner), was Les Solomon, the editor, was taken with the Cyclops Camera. But clearly, if you examine it, it has been significantly "doctored" and not what I would expect to see on the face of an oscilloscope in X-Y mode. It has been reformated to appear as near equal illumination strips of light with black intervals between. Artistic licence if you like by the "Art Department", but it obscures history and the reality of what the camera would be expected to produce when used with an X-Y oscilloscope, it looks more like the result expected with a coarse raster scan in a two level black-white image scenario.
Click to expand...
There are few photos showing what the camera output "really" looked like aside from the one shown in the Popular Electronics article:
There are a couple showing the Dazzler output on Bill Sudbrink's web page:
...and a couple here showing the camera output displaced directly on a scope from the Hackaday web page:
hackaday.com

Building The First Digital Camera

While the official history of the digital camera begins with a Kodak engineer tinkering around with digital electronics in 1975, the first digital camera was actually built a few months prior. At t…
hackaday.com hackaday.com
 
hmb said:
There are few photos showing what the camera output "really" looked like aside from the one shown in the Popular Electronics article:
There are a couple showing the Dazzler output on Bill Sudbrink's web page:
...and a couple here showing the camera output displaced directly on a scope from the Hackaday web page:
hackaday.com

Building The First Digital Camera

While the official history of the digital camera begins with a Kodak engineer tinkering around with digital electronics in 1975, the first digital camera was actually built a few months prior. At t…
hackaday.com hackaday.com
Click to expand...

Yes, those images on Bill's page are exactly how my Camera is responding, to get an image of a hand and face.

Notice that to get the face image that Bill did, you require a high contract image of a face on a piece of paper hit with a very bright floodlight. To get that from an actual person's face (as Terry said was done with Les Solomon) would be extremely difficult, because; 1) the floodlight would be far to bright for them to put up with it and 2) the contrast ratio across the face not high enough so the details would be bleached out. It requires two things; that face is printed black and white on a paper sheet and lit with a very bright Tungsten Lamp. Probably this is how the image of Les Solomon's face was created for the Popular Electronics article, by printing out a high contrast picture of him on a white paper sheet, then floodlighting that, but that detail was left out of the story.

The scope version on Hackaday is about what I would expect.
 
Last edited:
Further research and testing on the Cyclops camera has revealed some interesting findings.

Bill's camera image attached is defective. And I have seen this exact effect on my camera with some of the image sensor IC's I have tried. It is not resolving discrete pixel values and giving a venetian blind like effect.

If you examine it, especially on the horizontal meridian, you will see that numbers of pixels all in a row have been rendered with the same shade of grey. This problem grossly degrades the possible resolution. It turns out that when the image sensor chip is working properly (as some variants I have do) this is not the case. I have examined now about 8 different IC's in the application (costing a small fortune). When the S4008-9 part is strobed by its address lines, the output of it does not correspond to discrete address and values pixels (Memory cell locations) but extends over long periods across a number of address values, it is almost as though after the adddress is updated the output cannot keep up or source adequate current. Certainly the MK4008-9 (according to the data sheet) appears to have a different output pin drive capability than the MK4006 and MK 4008. Of the MK4008-6 parts I have checked, this issue is not as bad as the S4008-9 part. So far the better parts I have tested are the plain suffix-less MK4008 parts from the early 70's. There are some other issues too, such as lack of uniformity of the cells. In any case when I have tested it fully and found the ideal part I will post it, I'm still waitng for more sensor chips in the mail.
 

Attachments

  • Billspic.jpg
    Billspic.jpg
    22.9 KB · Views: 5
Hugo Holden said:
Further research and testing on the Cyclops camera has revealed some interesting findings.

Bill's camera image attached is defective. And I have seen this exact effect on my camera with some of the image sensor IC's I have tried. It is not resolving discrete pixel values and giving a venetian blind like effect.

If you examine it, especially on the horizontal meridian, you will see that numbers of pixels all in a row have been rendered with the same shade of grey. This problem grossly degrades the possible resolution. It turns out that when the image sensor chip is working properly (as some variants I have do) this is not the case. I have examined now about 8 different IC's in the application (costing a small fortune). When the S4008-9 part is strobed by its address lines, the output of it does not correspond to discrete address and values pixels (Memory cell locations) but extends over long periods across a number of address values, it is almost as though after the adddress is updated the output cannot keep up or source adequate current. Certainly the MK4008-9 (according to the data sheet) appears to have a different output pin drive capability than the MK4006 and MK 4008. Of the MK4008-6 parts I have checked, this issue is not as bad as the S4008-9 part. So far the better parts I have tested are the plain suffix-less MK4008 parts from the early 70's. There are some other issues too, such as lack of uniformity of the cells. In any case when I have tested it fully and found the ideal part I will post it, I'm still waitng for more sensor chips in the mail.
Click to expand...

Wow these are unexpected findings but a great contribution for putting together an optimal system - really looking forward to seeing the results of all your hard work. You're going to be an expert IC de-lidder when this is done.
 
You must log in or register to reply here.
Back
Top