• Please review our updated Terms and Rules here

Cromemco Cyclops 88 CCC board set reproduction

I have been removing tops from some IC's took some practice, and cutting down some microscope cover slides.

I got a few chips to try to hedge my bets in the hope of getting at least 1 that will work properly. One version as shown in the attached photo was found to have what appears to be a split in the die area or a grey line where the memory array is, I suspect that this one will not be a suitable part, I will find out.

One thing about the cover slides, ideally they would be perfectly clean and sterile of any biological life or they could get a Biofilm growing on their inner surface. I cleaned them with Windex, because apparently, according to an Optical Engineer I met at Zeiss, the small amount of copper sulphate in that inhibits Fungal growth and they use it at their optical factory in lens assemblies for that reason. The coverslides were tricky to cut. After doing it I smoothed the cut surface with 600, 1000, 2000, and 3000 grade paper to help prevent any microscopic cracks propagating through this clear window later.
 

Attachments

  • Mostek2.jpg
    Mostek2.jpg
    382.6 KB · Views: 7
Hugo Holden said:
I have been removing tops from some IC's took some practice, and cutting down some microscope cover slides.

I got a few chips to try to hedge my bets in the hope of getting at least 1 that will work properly. One version as shown in the attached photo was found to have what appears to be a split in the die area or a grey line where the memory array is, I suspect that this one will not be a suitable part, I will find out.

One thing about the cover slides, ideally they would be perfectly clean and sterile of any biological life or they could get a Biofilm growing on their inner surface. I cleaned them with Windex, because apparently, according to an Optical Engineer I met at Zeiss, the small amount of copper sulphate in that inhibits Fungal growth and they use it at their optical factory in lens assemblies for that reason. The coverslides were tricky to cut. After doing it I smoothed the cut surface with 600, 1000, 2000, and 3000 grade paper to help prevent any microscopic cracks propagating through this clear window later.
Click to expand...
Based on your experience, could you provide advice on how to remove the lid from these ICs?
How did you cut the microscope cover slides down to size?
 
I have attempted running the system. Unfortunately there are more problems with the replica 88-CCC pcbs.

As one example, on board 1 there is missing copper trackwork pin 4 of the 74193 (U38) and pin 4&5 of the U27, the 7420. and as a result of that, no clock pulses were appearing at the camera. However once that was fixed the cards now crash the computer, so I think there will be more issues related to the bus control, possibly more missing or incorrect pcb links.

This is the inevitable result of trying to replicate a complex vintage board without using the exact original track pattern. This is because there can be mistakes/omssions in the original manufacturer schematic as we have seen already. But accounting for every track and and connection finds those errors and this also finds the reverse case, where there is a link, on the schematic and on the original foil pattern, but no physical track on the auto routed board, because a schematic ommision introduced by re-drawing the original schematic into a pcb program with a missing link, cannot get detected. The auto-router only does what its told. It is possible that there are only one or two problems left, it is just hard to know. If anyone finds any other issues please report them here asap.

I will keep working on it, but it could take a very long time to find and fix it. Of course starting with a fresh system with many NOS IC's there are added variables, always is the possibility of a dud part too. Compounded problems are very difficult and time consuming to fix. If I fail to remedy it, I might have to redo the pcb's to match the original track pattern and verify every connection with the schematic, like I did for the Dazzler.

I noticed on that Github link there were foil pattern images in the photos, and also there were two unpopulated boards. I wonder who owns those ? it would be great to put those in a scanner to get clear images of the foils or get copies of the ones from the paperwork there. However there is enough visible to do it other ways.
 
Last edited:
hmb said:
Based on your experience, could you provide advice on how to remove the lid from these ICs?
How did you cut the microscope cover slides down to size?
Click to expand...
To remove the tops I put the IC in a socket in a small section of pcb and pot that in a small Vise and also supported the body of the IC to one of the jaws with a small spacer block Then using a new sharp wood chisel, started at one corner with a tap from a small hammer. Once the corner lifted a little then with levering the cover would flick off the top towards my face (use protective eyewear)

The coverslides requird a scratch in the surface. The only tool I had on hand to do that was a small round Diamond file (it really needs a mini-glasscutter) Then I broke the slide across a sharp metal edge. I would say that for every clean break I got there were at least 5 or 6 attempts that failed to work and randomly fractured into pieces.

Once the top is off it pays to use a hand held air puffer to make sure there is no particulate matter from the fractured lid seal (that could cast a shadow) on the die. I would not suggest high velocity compressed air though, I'm sure the wire links to the die are quite fragile.
 
Just out of interest, was the schematic entered into KiCAD before routing? If so, the DRC (Design Rules Checker) should have found any pins that were not connected correctly before the routing was started.

Dave
 
daver2 said:
Just out of interest, was the schematic entered into KiCAD before routing? If so, the DRC (Design Rules Checker) should have found any pins that were not connected correctly before the routing was started.

Dave
Click to expand...
That only works if the schematic is entered correctly, because if you look at the circuit you will find multiple connections from outputs to a number of inputs in logic circuits. If some inputs, say a pair of them on the one or more IC's are connected together, that were supposed to be connected elsewhere on the schematic to some output, if there is a missing link, on the entered schematic connecting them, the DRC cannot detect this as an error, because all connections appear accounted for and the DRC just assumes all connections are correct as the designer intended. The DRC, while it it can make sure that the PCB foils exactly match the schematic you enter without errors, it cannot detect all types of defects or omission in the actual schematic entered by the operator, nor can it detect a defective manufacturer schematic, with missing links, as we have also seen before. In some kind of strange analogous way, relying on the DRC to make sure that all is ok, is a work shortcut to performing the required work yourself and say relying on an AI to do a task for you. It leaves the opportunity open for many mistakes in the wind, and as Mr. Dylan aptly put it: "molotov coctails & rocks behind every curtain"
 
Of course, the DRC can only detect the 'obvious' errors like unconnected inputs and outputs and outputs connected together.

But it is better than nothing!

I have seen too many projects where the DRCs were disabled and a simple input to a CD4001 was left unconnected. This project passed all the checks, until it was installed on plant, and then it started doing weird sh*t!

When I was managing a hardware project, I ensured that the PCB designer had the DRCs switched on...

But I had access to a real board, so I could perform automated flying probe tests using the PCB netlist and the real board. That highlighted a whole load of differences!

Dave
 
Last edited:
daver2 said:
Of course, the DRC can only detect the 'obvious' errors like unconnected inputs and outputs and outputs connected together.

But it is better than nothing!

I have seen too many projects where the DRCs were disabled and a simple input to a CD4001 was left unconnected. This project passed all the checks, until it was installed on plant, and then it started doing weird sh*t!

When I was managing a hardware project, I ensured that the PCB designer had the DRCs switched on...

But I had access to a real board, so I could perform automated flying probe tests using the PCB netlist and the real board. That highlighted a whole load of differences!

Dave
Click to expand...
One of the more insane problems related to 4000 series cmos was that the circuit would still actualy work, if the power pin to the chip was accidentally left disconnected, because if any of the other termials were high, it powered the rest of the chip by the substrate diodes. But, if a logic condition cropped up where all was low, at the same time, then the chip malfunctioned. Life really is stranger than fiction.

If a cmos gate is left open as you know all sorts od weird stuff happens because of varying amounts of charge on the gate. Interestingly though, the 4000 series cmos parts had a common failure mode where the output of a gate would go completely O/C, that left the inputs it was connected to floating, and that is when that weird and erratic behaviour can happen too, I could tell many stories about this that bamboozled a stack of engineers trying to fix video machines back in the 1980's.
 
Last edited:
The 'flying probe' test was something that the PCB design company had not even thought of.

We used the netlist to identify what component pins formed a single network.

An unconnected pin formed a single node network.

We then programmed the flying probe machine to:

1. Check that all of the component pins that were supposed to be connected together (from the design) were (on the reference board).
2. Check one pin of each network against one pin of all of the other networks to make sure that tracks had not been missed.

Things like switches and links caused false errors (that we had to manually resolve).

Interestingly, No Connect (NC) pins of some of the ICs (that were truly not connected on the reference board and the reverse-engineered design) ended up as being connected to an internal pin. So we also had the odd false error from this. A quick check of the IC part concerned proved that the internal interconnection was really present.

This process identified quite a number of deviations between the reverse-engineered design and the reference board.

The boards we reverse engineered were MULTIBUS-1 form-factor, 6 layer PCBs and packed full of ICs.

We had a sacrificial card that we removed the components from, stripped the solder resist from (so we could take photographs of the two (2) outer layers) and then sanded down the outer layers to reveal two of the inner signal layers. 2D and 3D X-ray machines then identified the two inner power layers.

Once we had identified the differences (using the flying probe machine) you could see where tiny PCB tracks had been missed off the reverse engineered design where tracks went between IC pins - but were also connected to one of the pins where they went between.

That was a cool job - and enabled us to get a 100% correct, 6-layer PCB out in one spin of the PCB.

Dave
 
I had a similar sort of dilemma, not as hard, reverse engineering the RM65 video card for the AIM 65, some X-Rays helped. It had a data bus in one of its middle layers, not just power & ground planes, it was tough, but it all worked out.
 
Earlier in the discussion it was mentioned there are errors in the software listing provided in the CCC manual, and I cannot recall whether these were all identified and fixed. I did run across some discussion regarding errors in the code in the context of using it for the z80pack simulator for the Cyclops camera controller, and how it had been fixed up:
github.com

Implement the Cromemco 88-CCC Cyclops Camera Controller · Issue #59 · udo-munk/z80pack

Reproductions of the worlds first digital camera, the Cromemco Cyclops 88-ACC have been shown at recent VCF events in the US. The Wikipedia page for the Cyclops has links to the manuals for both th...
github.com github.com
I could not figure out where to find that fixed up code - perhaps someone else may have better luck.
 
One of the issues that we found is potentially an 'off by one' where two descriptions are given for a register setting - but both of them cannot be concurrently true...

This is why we need a working set of hardware to identify where the bugs are. Are they in the description, the software or both?

One is the delay between frames and the other is the number of frames that are captured. Everything else looks fine to me.

Dave
 
I think the software is ok. It appeared only to have those two defects (one faulty jump and a bitmask both that @daver2 fixed), though I cannot run it fully currently with the hardware not working. With the missing clock pulse, before the 88-CCC cards locked up the computer, the software also did as it should, initialising the Dazzler into the correct mode at the correct starting address. Of course it just displayed random grey scale pixels not being updated. I also tested that manually writing to the Dazzler memory address and that produced the correct result with the pixels, so I know the Dazzler is working fine. I knew that the communication with the camera was not working right away because I had altered the software to bring up the Bias lights and they did not come on. A quick check at the camera end showed that was because there were no clock pulses and that I could toggle the bias lights with a slight disturbance at the input to the LM311 comparator. I think the camera itself is likely just fine. It could just be that one or two faults remain on board 1 or 2, but I have not found them yet.

It could well be that there was another omission on Cromemco's schematic. To rule that out I will start to manually verify the tracks on the original board with their schematic.
 
hmb said:
I could not figure out where to find that fixed up code - perhaps someone else may have better luck.
Click to expand...
I'll attach a copy of the corrected program, as soon as its checked to avoid having any defective copies floating around.
 
Last edited:
@Hugo Holden,

Can you check the state of CYCLOPS board number 2 U38 pins 8 and 9 when your machine is powered up and everything doesn't work?

I suspect pin 8 will be LOW and pin 9 will be HIGH. If this is the case, this is the wrong way round, and we can investigate why.

I am just looking at how the board powers up and is reset to start with. If we can solve this issue, we should be able to get the main CPU up and running and then investigate the board logic further.

I am currently following the S-100 pin 75 (/PRESET) signal. On board 1 this should set U23/10 and on board 2 this should set U26/10. We now need to follow the logic around (cascading logic with the various clocks) to see what the initial power up stable state becomes. Even though /PRESET initialises the flip-flops correctly when /RESET goes LOW; something may erroneously change their state again.

We are trying to see if the logic powers up to a stable state and accidentally enables the output buffers onto the S-100 bus (thus bringing everything to a grinding halt).

Dave
 
Last edited:
@daver2 @Hugo Holden Yes I did enter the schematic to the best of my ability and run the DRC ensuring there were no obvious issues caught - but as Hugo points out unfortunately (and as I believe we found early on) there are errors (& potentially omissions) in the published schematics. Hugo, I sincerely appreciate your efforts to debug the boards and get something operational. Since I don't have an original to reference & and I'd love to see a reproduction happen, I figured I'd do the best I could and hope you wizards could fill in the gaps :)

@daver2 not sure if you have any interest in building up any of these? but let me know, I'd be happy to post a set..
 
nullvalue said:
@daver2 @Hugo Holden Yes I did enter the schematic to the best of my ability and run the DRC ensuring there were no obvious issues caught - but as Hugo points out unfortunately (and as I believe we found early on) there are errors (& potentially omissions) in the published schematics. Hugo, I sincerely appreciate your efforts to debug the boards and get something operational. Since I don't have an original to reference & and I'd love to see a reproduction happen, I figured I'd do the best I could and hope you wizards could fill in the gaps :)

@daver2 not sure if you have any interest in building up any of these? but let me know, I'd be happy to post a set..
Click to expand...
I'll post what I find, it may be a while, At the moment I'm hand generating a set of boards in KiCad from the photographic images, and cross referencing each track to the schematic. If there is another error in that Cromemco schematic, I should likely be able to find it, but it is a long process. This would likely enable a quick fix of your board, provided there were no other issues with the KiCad entered schematic vs Cromemco. Can you go over your schematic which generated your boards with a fine tooth comb and search for any other connection issues or missing links where your schematic does not exactly match the Cromemco one ?

Do you know who owns the two unpopulated pcb's seen in one of the Github photos and if they might be able to provide clear photos of both sides of those ?
 
Hugo Holden said:
Do you know who owns the two unpopulated pcb's seen in one of the Github photos and if they might be able to provide clear photos of both sides of those ?
Click to expand...

Unfortunately, no - these photos were scraped together from various sources and were all the photos I could find, I did this with the thought that what you're attempting might be necessary, but with the hope the schematic was accurate. Would make things a lot easier if those turned up! Bill S. does have an original set though and I've already asked him some questions (asked him to route some traces for me to confirm a couple things from the schematic) - and he's been quite helpful. So worst case we can pester him some more :)
 
Excellent news that you entered the schematics into KiCAD and ran the DRCs.

That probably means that the errors are with the original schematics. I have just printed out the original schematics and will give them a check.

I will post a few measurements that I would like someone to make as I go.

The first thing is to test - with a multimeter - that we have GND/0V and +5V on every IC (by checking the datasheet for the specific IC part numbers).

Dave
 
You must log in or register to reply here.
Back
Top