Cromemco Cyclops 88 CCC board set reproduction

[daver2]

Looking at the datasheet for the MK4008 and the ACC-1 schematic, a '0' is written into the cells of the DRAM to 'precharge' the array. Din (pin 11) is wired to 0V/GND.

I assume somewhere within the circuitry between Dout of the DRAM and the DMA buffer, some sort of logical inversion takes place - because the Cromemco software assumes a '1' is an illuminated pixel.

I see that a couple of X addresses are swapped over (pins 14 and 15) and inverted as they flow from the CD4040 counter. This (I assume) sorts out the 'strange' logic with the DRAM to present a coherent 32x32 output matrix.

The data output pin is NOT TTL compliant (according to the data sheet I was reading). The data sheet suggested using a TI 75107 to convert the 4008 output into a TTL level. Possibly better than the transistors used on the original?

Dave

 

[hmb]

Looking at the datasheet for the MK4008 and the ACC-1 schematic, a '0' is written into the cells of the DRAM to 'precharge' the array. Din (pin 11) is wired to 0V/GND.

I assume somewhere within the circuitry between Dout of the DRAM and the DMA buffer, some sort of logical inversion takes place - because the Cromemco software assumes a '1' is an illuminated pixel.

I see that a couple of X addresses are swapped over (pins 14 and 15) and inverted as they flow from the CD4040 counter. This (I assume) sorts out the 'strange' logic with the DRAM to present a coherent 32x32 output matrix.

The data output pin is NOT TTL compliant (according to the data sheet I was reading). The data sheet suggested using a TI 75107 to convert the 4008 output into a TTL level. Possibly better than the transistors used on the original?

Dave

The rationale for the flipped address lines was explained by Terry Walker (who designed the Cyclops) as follows:
"Now, an interesting thing happened. When they went to actually mass produce these sensors, they ordered a thousand of them from AMI and put them in the camera. They didn’t work. The picture was all scrambled. And the reason was that when AMI (error: Mostek) copied the memory chip, they had changed the way a couple of the address lines worked. So, it scrambled the picture contents. And so, we put a couple of little jumper wires on that circuit board for the camera kit before it actually went out, so you could use either type A or type B sensors. So, the new kind that Mostek had made, which AMI was now selling, was type B. The original one that was in the original prototype was a type A. There aren’t very many of those around because AMI had found that the Mostek chips gave better production yield. So, they (AMI) were using the Mostek design instead of their own."

The "jumper wires" he referred to were present in the original design printed in Popular Electronics, but not the later version shipped by Cromemco.

You can read about that and other interesting tidbits, including a great explanation of how the Cyclops managed to produce grey scale images, in this transcript of an interview with Terry Walker:

https://archive.computerhistory.org/resources/access/text/2019/12/102740213-05-01-acc.pdf

 

[daver2]

Yes, I saw the jumpers in the PE article.

That's a good article! Some reading homework for tonight...

Dave

 

[Hugo Holden]

The rationale for the flipped address lines was explained by Terry Walker (who designed the Cyclops) as follows:
"Now, an interesting thing happened. When they went to actually mass produce these sensors, they ordered a thousand of them from AMI and put them in the camera. They didn’t work. The picture was all scrambled. And the reason was that when AMI (error: Mostek) copied the memory chip, they had changed the way a couple of the address lines worked. So, it scrambled the picture contents. And so, we put a couple of little jumper wires on that circuit board for the camera kit before it actually went out, so you could use either type A or type B sensors. So, the new kind that Mostek had made, which AMI was now selling, was type B. The original one that was in the original prototype was a type A. There aren’t very many of those around because AMI had found that the Mostek chips gave better production yield. So, they (AMI) were using the Mostek design instead of their own."

The "jumper wires" he referred to were present in the original design printed in Popular Electronics, but not the later version shipped by Cromemco.

You can read about that and other interesting tidbits, including a great explanation of how the Cyclops managed to produce grey scale images, in this transcript of an interview with Terry Walker:

https://archive.computerhistory.org/resources/access/text/2019/12/102740213-05-01-acc.pdf

Thanks for that link.

I notice also on the Cromeco 88 ACC document they specify the sensor as a C-1024B and "type B sensor" as discussed by Terry Walker. Do we know for sure if the MK4008P-6 MOSTEK 500NS 1024X1 DRAM IC part sold by little-diode (I think its Langrex which explains why its genuine old stock) in the UK is directly compatible with that for this application? This part is also available in the USA, but they are dated 1973, so I guess its possible they could be equivalent of an earlier version:

https://www.ebay.com/itm/365892028439

 

[hmb]

Thanks for that link.

I notice also on the Cromeco 88 ACC document they specify the sensor as a C-1024B and "type B sensor" as discussed by Terry Walker. Do we know for sure if the MKM MOSTEK 500NS 1024X1 DRAM IC part sold by little-diode (I think its Langrex which explains why its genuine old stock) in the UK is directly compatible with that for this application? This part is also available in the USA, but they are dated 1973, so I guess its possible they could be equivalent of an earlier version:

https://www.ebay.com/itm/365892028439

The MK4008P-6 sold by Little Diode (and several eBay sellers) has an access time 500ns and refresh cycle time of 2ms. In view of the longer refresh cycle time compared to the specified -9 version, it may not perform the same way when used in the Cyclops.

On the other hand, the MK4008P-9 specified for use with the Cyclops has an access time 800ns and refresh cycle time of 1ms. Little Diode sells the equivalent AMI part, which is the S4008-9 and those are the ones I purchased recently.

As to where the MK4008P with no speed rating and an early (1973 date code) shown in the eBay listing you referenced fits in - not sure. Possibly these were the versions used for the earlier "type A" sensors, ie the earliest versions manufactured by Mostek before AMI started second sourcing them? I have not had any success finding a Mostek data book that provides specs for the early MK4008P with no speed rating.

 

[Hugo Holden]

On the other hand, the MK4008P-9 specified for use with the Cyclops .......

Thanks.

Can you give me a link to the Cromemco document that specified the MK4008P-9, I can only find a reference to the C-1024B in my 88-ACC document I must be missing some other document/s.

 

[hmb]

Can you give me a link to the Cromemco document that specified the MK4008P-9, I can only find a reference to the C-1024B in my 88-ACC document I must be missing some other document/s.

Cromemco refers to the image sensor chip by its in-house part number CT-1024.

Bill Sudbrink's detailed documentation of his Cromemco Cyclops reproduction (which our current project is based) is where the MK4008P-9 and AMI S4008-9 are specified:

http://wsudbrink.dyndns.org:8080/cyclops/index.html

I believe he was told what the Mostek/AMI part numbers are by personal communication with the designer Terry Walker.

 

[Hugo Holden]

Cromemco refers to the image sensor chip by its in-house part number CT-1024.

Bill Sudbrink's detailed documentation of his Cromemco Cyclops reproduction (which our current project is based) is where the MK4008P-9 and AMI S4008-9 are specified:

http://wsudbrink.dyndns.org:8080/cyclops/index.html

I believe he was told what the Mostek/AMI part numbers are by personal communication with the designer Terry Walker.

So it looks lke Bill created the 3 camera boards in Kicad for his Cyclops reproduction where the track layouts didn't exactly match the original boards. They still work of course, but I would have done better myself, with the earthing arrangments and avoided the very thin traces in the common lines. Still that is just me. But it is actualy better to use wider tracks and bigger vias, to make the boards more robust, like the originals were.

 

[daver2]

Back to the software...

The memory for the camera occupies 128 [bytes/frame] * 12 [frames] = 1536 [bytes] = 600h [bytes].

The start of the camera buffer resides at 1000h. The camera buffer therefore occupies 1000h up to (and including) 15FFh.

The dazzler occupies 512 bytes of memory (200h) starting at 1600h and extending up to (and including) 17FFh.

In order to use the test program with the Dazzler (but without the camera itself) I would suggest modifying two (2) parts of the program:

1. Change the initialisation of the Dazzler from monochrome to colour. This will permit an easy determination of whether things are working or not by easily identifying the colour of pixels rather than looking at various shades of grey!

Change the source line from:

FOMAT EQU 000h ; 0000 0000 = 32 x 32 picture in 512 bytes monochrome.

To:

FOMAT EQU 010h ; 0001 0000 = 32 x 32 picture in 512 bytes colour.

2. Prevent the software from hanging whilst waiting for the camera to respond!

Change the source lines from:

AND 80h ;
JP NZ,POLLLP ; If MSB is zero, picture storing is complete.

To:

AND 00h ;
JP NZ,POLLLP ; If MSB is zero, picture storing is complete.

When the software is started (irrespective of the camera buffer contents) the dazzler should be initialised, the (none existent) camera should be initialised, but the software should continue irrespective of the state of the camera. The camera buffer data (1000h to 15FFh) should be processed and converted into a form for displaying on the dazzler.

The camera buffer will contain rubbish - so the dazzler display should display rubbish...

Depressing the 'Q' key should cause an exit back to CP/M. This demonstrates that the software is running in a loop and ignoring the camera, and my modification is correctly responding to the keypress.

If you use a debug monitor (before running the software) to set the camera buffer memory area from 1000h to 15FFh to 00h, the dazzler screen should display black when the software is executed.

If you use a debug monitor (before running the software) to set the camera buffer memory area from 1000h to 15FFh to FFh, the dazzler screen should display high intensity blue when the software is executed. 12 frames would result in each of the dazzler's pixel values being set to hexadecimal 'C' = high intensity blue.

By 'playing' with the camera frame buffer values you should be able to modify the colour of various pixels on the screen. For example, fill the camera buffer from 1000h to 15FF with a value of 00.

Set the least significant bit of the first byte of the first frame buffer (1000h) to 01.

This should result in a coloured pixel of 0001 = low brightness red.

Set the next frame buffer value (at 1080h) to 01.

This should result in a coloured pixel of 0010 = low brightness green.

Set the next frame buffer value (at 1100h) to 01.

This should result in a coloured pixel of 0011 = low brightness yellow.

You should observe a pattern here...

For each bit that is set in the same camera pixel location across the 12 frames, the pixel value of the dazzler buffer should be incremented by 1.

In the real camera, the bright pixels should start off as a '1' and decay to a '0' over time. A bright camera pixel would result in more '1' pixels resulting in a greater count number for the corresponding dazzler's picture. This is why it is easier to see the state of the Dazzler's buffer pixels if it is set for colour operation rather than monochrome.

The least significant bit of the first byte of each frame buffer should belong to the top left pixel of the Dazzler display (if I understand the code directly).

Ask away if this is not clear...

Dave

 

[Hugo Holden]

Back to the software...

The memory for the camera occupies 128 [bytes/frame] * 12 [frames] = 1536 [bytes] = 600h [bytes].

The start of the camera buffer resides at 1000h. The camera buffer therefore occupies 1000h up to (and including) 15FFh.

The dazzler occupies 512 bytes of memory (200h) starting at 1600h and extending up to (and including) 17FFh.

In order to use the test program with the Dazzler (but without the camera itself) I would suggest modifying two (2) parts of the program:

1. Change the initialisation of the Dazzler from monochrome to colour. This will permit an easy determination of whether things are working or not by easily identifying the colour of pixels rather than looking at various shades of grey!

Change the source line from:

FOMAT EQU 000h ; 0000 0000 = 32 x 32 picture in 512 bytes monochrome.

To:

FOMAT EQU 010h ; 0001 0000 = 32 x 32 picture in 512 bytes colour.

2. Prevent the software from hanging whilst waiting for the camera to respond!

Change the source lines from:

AND 80h ;
JP NZ,POLLLP ; If MSB is zero, picture storing is complete.

To:

AND 00h ;
JP NZ,POLLLP ; If MSB is zero, picture storing is complete.

When the software is started (irrespective of the camera buffer contents) the dazzler should be initialised, the (none existent) camera should be initialised, but the software should continue irrespective of the state of the camera. The camera buffer data (1000h to 15FFh) should be processed and converted into a form for displaying on the dazzler.

The camera buffer will contain rubbish - so the dazzler display should display rubbish...

Depressing the 'Q' key should cause an exit back to CP/M. This demonstrates that the software is running in a loop and ignoring the camera, and my modification is correctly responding to the keypress.

If you use a debug monitor (before running the software) to set the camera buffer memory area from 1000h to 15FFh to 00h, the dazzler screen should display black when the software is executed.

If you use a debug monitor (before running the software) to set the camera buffer memory area from 1000h to 15FFh to FFh, the dazzler screen should display high intensity blue when the software is executed. 12 frames would result in each of the dazzler's pixel values being set to hexadecimal 'C' = high intensity blue.

By 'playing' with the camera frame buffer values you should be able to modify the colour of various pixels on the screen. For example, fill the camera buffer from 1000h to 15FF with a value of 00.

Set the least significant bit of the first byte of the first frame buffer (1000h) to 01.

This should result in a coloured pixel of 0001 = low brightness red.

Set the next frame buffer value (at 1080h) to 01.

This should result in a coloured pixel of 0010 = low brightness green.

Set the next frame buffer value (at 1100h) to 01.

This should result in a coloured pixel of 0011 = low brightness yellow.

You should observe a pattern here...

For each bit that is set in the same camera pixel location across the 12 frames, the pixel value of the dazzler buffer should be incremented by 1.

In the real camera, the bright pixels should start off as a '1' and decay to a '0' over time. A bright camera pixel would result in more '1' pixels resulting in a greater count number for the corresponding dazzler's picture. This is why it is easier to see the state of the Dazzler's buffer pixels if it is set for colour operation rather than monochrome.

The least significant bit of the first byte of each frame buffer should belong to the top left pixel of the Dazzler display (if I understand the code directly).

Ask away if this is not clear...

Dave

Wow, thanks Dave

I have been pondering how , from my usual hardware (and software ignorant) perspective, how to be able to make a sort of test jig for the cyclops camera on its own, without having to rely on software to test it out. Obviously something like the Oscilloscope interface would do it. But I have been considering other ways, using the Dazzlers vertical an horizontal signals to generate sawtooth ramps to view the camera data in X-Y mode on the scope.

I was looking at the Popular electronics oscillocope interface, and the interesting thing I noticed was the way the image sensor was addressed, It may well be that the "image sensor" provided by Cromemco for the oscilloscope version, was the "A" version of the chip if you look at what happened with the address lines. I suspect for that Scope cyclops they were trying to sell off the "A" version of the sensor chips.

 

[daver2]

Yep, which is why I mentioned it way above.

Swapped over AND inverted.

Dave

 

[hmb]

I have been pondering how , from my usual hardware (and software ignorant) perspective, how to be able to make a sort of test jig for the cyclops camera on its own, without having to rely on software to test it out. Obviously something like the Oscilloscope interface would do it. But I have been considering other ways, using the Dazzlers vertical an horizontal signals to generate sawtooth ramps to view the camera data in X-Y mode on the scope.

I have been considering building the XYZ scope interface from the schematic printed at the end of the Cromemco Cyclops manual. It is a fairly simple design, would be great for testing and demonstrating the Cyclops without requiring complete system with Dazzler and CCC boards installed, but does require a scope capable of generating an XY display with a Z (intensity) input.
Does anyone have a high-res scan of the Cromemco Cyclops manual they could post? All the manual scans I have seen (including the one from the Cromemco Github repository) do not clearly show values of several resistors and capacitors in the schematic for the oscilloscope interface.

 

[Hugo Holden]

I have been considering building the XYZ scope interface from the schematic printed at the end of the Cromemco Cyclops manual. It is a fairly simple design, would be great for testing and demonstrating the Cyclops without requiring complete system with Dazzler and CCC boards installed, but does require a scope capable of generating an XY display with a Z (intensity) input.
Does anyone have a high-res scan of the Cromemco Cyclops manual they could post? All the manual scans I have seen (including the one from the Cromemco Github repository) do not clearly show values of several resistors and capacitors in the schematic for the oscilloscope interface.

I noticed this too and I have been looking around for a clear copy, no luck yet, I hope one turns up.

Since we are bulding a somewhat complex system relying on hardware and software to work, and the hardware might not work from scratch due to the smallest of reasons, it could save a lot of headaches if we could test the camera separately.

 

[Hugo Holden]

Here is an interesting finding. I bought three of these original 2N3646 transistors for the Camera. They have interesting specs in that they are designed for switching applications and have a very low storage times (recover from saturation very quickly) The parts I received (from an Australian seller) looked physically perfect, so its not their fault, it is just an "old stock thing", thay have never been used or even tested before I suspect, but here is the thing, one of them has a grossly abnormal base-emitter junction, and one other is leaky and only one of the three transistors tests as a normal part ! I have seen this before with on the shelf degradation of Fairchild resin top transistors. I think the 2N3904 will be fast enough so I'm going to put those in instead. So if you are using the 2N3646 check them before they are installed.

I finished the board with the regulators. It was mentioned in the manual not to let the regulator tabs short out, so I put a thick fibre washer between them and used a Nylon screw/nut. After washing off the flux residues in the usual way, the pcb cleaner affected the color of the red bands on the 1k resistors I had used, making them look pink. Normally the stripe colors are not affected on resistors from pcb cleaning solutions, but in this case on these particular ones, curiously they were.

 

[Hugo Holden]

I started on the Metalwork. I made a D9 connector template from some pcb material . First I drilled the holes and tapped them with a 4-40 UNC thread. It is an interesting business tapping threads in aluminium, It is better to do it a little incompletely with a Taper tap and then run a Roll Form Tap through it, it compresses the threads and they become much stronger.

The 1/4 inch 20 TPI mounting hole for a Tripod tapped directly into the base is not wonderful, because the metal wall, excluding the internal ridges is only about 3.3mm thick, so with about 0.8 turns/mm that only provides about 2.6 turns of thread. That could, after screwing the Cyclops to a few tripods start to wear out pretty quickly. I bought the taps for that including a Roll Form tap but I'm still considering it or modifying that arrangement.

Th thread for the lens is not too bad as it is finer. I'm awating for that Tap from China. One option I'm considering is using the D to C mount adapter, they will drop into a 25mm plain hole and the front flange thickness is only 0.5mm and they have a perectly cut D mount thread in material that is 4.6mm thick and they could be secured by a pair of screws, rather than the C thread.... still deciding on that one. I might Tap the thread for the lens and see how well that goes , I can always bore the holeout to 25mm and go to the C-D adapter to provide the thread if there is an issue.

Also, from what I can tell it looks like they glued metal strips onto each aluminium side panel of the case. I will have to prepare those and a label.

 

[Hugo Holden]

Hi @nullvalue:

I have been assembling more things on board 2 and was about to install the port jumpers according to the Cromemco manual. But I discovered on checking the jumper arrangements, on your board, they are completely diffierent to the Cromemco arrangement. I had to study that setup for a while to figure out how to set them.

Can you inspect the attached photo and see if you agree, that the jumpers are set for port A = 10h, port B = 11h and port C = 12h, just in case I have fouled it up.

 

[Hugo Holden]

I went to prepare a camera cable from the 9 pin connector on the camera, to the 16 pin connector on board 1 of the 88-CCC.

It seems as though the camera configuration with the "composite clock & differential video output signal was intended for the interfaceto a scope version, those 4 connections are not explicitly labelled on the 16 pin connector, the the video signal itself is not of a differential type, and there does not appear to be a "combined composite clock & reset" signal provided on the connector. What is going on with this ? It is also not clear to me why they put camera data CD0-CD4 on that 16 pin connector ? or what the 1k pullup and 560R pull down resistors were for.

Are we missing a document on how to connect the 9 pin camera connector to the 16 pin one on the board 1 pcb ? Obviously the gnd and +/- 17V connections are obvious. Maybe the 1.5k pullup is supposed to also connect to pin 6 on the D9 connector, but it might be for the collector either pin 7 or 3 of 1/2 the differential video signal that is not used and maybe the 560R pull down is for pin 6 on the D9, so that the clock gets injected into pin 2, or could the CAMCK on pin 7 ofthe 16 pin connector be intended to feed pin 9 on the D9 connector.

 

[daver2]

The CD0-CD4 signals are general purpose digital output bits. However, they could be 'press ganged' into selecting one of multiple cameras (according to the text I read).

Fave

 

[Hugo Holden]

The CD0-CD4 signals are general purpose digital output bits. However, they could be 'press ganged' into selecting one of multiple cameras (according to the text I read).

Fave

But aside from that, what I am trying to figure out is how to configure the cable link from the 9 pin connector on the Cyclops to the 16 pin connector on the 88-ccc board 1.

Does the attached diagram look correct ?

 

[daver2]

I was going to have a look at that for you after I have completed my (rather extensive) list of jobs my wife has given me!

I was away all of last week on a business trip - so my list has just been growing!

Dave