Cromemco Cyclops 88 CCC board set reproduction

[daver2]

Your CCC-3 software is slowly giving up it's secrets!

I am working from the inner loop outwards - and it is starting to make sense...

Your "JNC OC211" should be "JNC OC221" (as my first guess)...

The bit in the carry flag indicates the state of the current bit being processed from the camera sensor within the current frame. if the bit is SET, then the 4-bit value in the current Dazzler's corresponding pixel needs to be incremented (a brighter grey-scale pixel). if the bit is CLEAR (NC) no Dazzler pixel update needs to be made.

EDIT1: Just worked out the outermost loop. What an evil program! The position of the cyclops camera buffer (at address 1000h) is significant! The upper three bits of H are used to indicate which data bit of the camera frame is being processed. This is still an assumption until I comment things in more detail - but not a bad assumption.

EDIT2: Above assumption turned out to be correct. Almost finished...

EDIT3: First pass comments attached. I will tidy them up later. It is always good to go back to comments and read them after a couple of days. If they don't make sense - they are clearly not good enough!

I think I have found another coding error. A bitmask is identified as 0E0h and I think it should be 0F0h.

Incidentally, the setting of camera port B to 0Bh = 11 (decimal) yields 12 frames as processed by the code (I think)...

Dave

 

[daver2]

Here is the maths:

The camera image contains 1024 pixel bits arranged as a 32 by 32 pixel array stored in memory with 8 pixel bits per byte of memory.

32 * 32 [pixels] / 8 [pixels/byte] = 128 [bytes] per camera image (one camera frame).

With 12 frames captured at each snapshot, the total camera buffer requires 128 * 12 = 1536 bytes.

The Dazzler display image is also 32 by 32 pixels stored in a 512 byte buffer.

This gives 32 * 32 / 512 = 2 pixels per byte.

Each pixel consists of 4 bits corresponding to 16 shades of grey from 0000 (black) to 1111 (white).

Bit 0 of the first byte of each of the 12 camera frames is sequentially processed in a loop to create the first dazzler pixel.

Each subsequent bit of the first byte of each of the 12 camera frames are also sequentially processed to create the subsequent pixels of the dazzler display.

Each of the 128 camera bytes per frame are then processed sequentially to form the subsequent pixels of the dazzler display.

With 12 camera frames, the dazzler pixel values should be able to take a value from 0000 (full black) to 1011.

Dave

 

[daver2]

Just in case you are wondering, you can assemble CCC3.z80 by hopping over to asm80.com and hitting compile to create a listing and hex file.

Dave

 

[Hugo Holden]

Just in case you are wondering, you can assemble CCC3.z80 by hopping over to asm80.com and hitting compile to create a listing and hex file.

Dave

Wow ! Thanks Dave. It will study this, it will take me a while to figure it out, but now I have a good chance of understanding it.

In Post #51 I mentioned in another example program, they used 0Fh to specify 15 frames, how do we bring that into line with 0Bh specifying 12 frames ?

Also I think it is amazing that the jump (JNC) error was there in Cromemco's document, since anybody who would have tried to use the program at the time would have found out it didn't work and one would have thought that Cromemco would have sent out a corrected document, maybe there was one, lost to the sands of time.

Could you suggest a few lines of 8080 program to use a keyboard Key on the Sol to switch the Bias lights on & off and to escape from the program back to CP/M ?

 

[daver2]

There are lies, damn lies, statistics, and old computer documentation! I can't marry up 0Fh with 15 frames and 0Bh with 12 frames. One has to be in error. It could still be the CCC-3 program yet that is missing one frame from the buffer...

I suspect that an errata sheet may have been issued but, as you say, lost in time...

There is another error in there I mentioned also (a bit mask seems to be incorrect).

I will have a look at your keyboard request. Under CP/M it should be relatively simple.

I will tweak the comments a bit more, put some more meaningful labels in place of the OCnnn, and remove the ORG 0Cnnn statements.

Any questions regarding the code and comments please ask.

That was an interesting distraction this afternoon whilst I should have been working! No problem, I had done all of my work this morning...

Dave

 

[daver2]

'N' key for back light oN, 'F' key for back light oFF, and 'Q' key for Quit?

These OK?

Dave

 

[Hugo Holden]

'N' key for back light oN, 'F' key for back light oFF, and 'Q' key for Quit?

These OK?

Dave

Yes that would be fine.

 

[daver2]

I have made all of the modifications.

The program should now load under CP/M.

The keys:

N Turns the bias light ON.
F Turns the bias light OFF.
Q Quits the program back to CP/M.

You can enter either upper case or lower case letters.

I have updated the 'key' labels to be more meaningful. I have left the OCnnn labels where they are just local labels. Obviously, the octal numbers associated with the labels do not now tally with the associated memory addresses!

I just need to check and tweak the comments now - but I have some jobs to do...

Ah, just found a potential problem...

CP/M function 1 echoes the character to the screen. This is not what we want to do if we are displaying a pretty picture on the screen...

CP/M function 6 does not echo the character to the screen. However, this function is only available (in this form) in CP/M version 2.0 or higher.

Which version of CP/M are you running?

Dave

 

[Hugo Holden]

Which version of CP/M are you running?

Dave

CP/M 2.2

It has the assembler that I can use to make the .ASM file into a .COM file.

What I do is port the .ASM to the SOL from a "modern computer" on the seral link.

My SOL-20 has the Northstar double density 5.25" floppy disk controller. I use that with some good 5.25" disc drives that work on soft sectored media, because I used Mike Douglas's virtual sector generator. They are really good Japanese made YD-580 drives, made by the Japanese for IBM:

https://www.worldphaco.com/uploads/EXTERNAL_DUAL_5.pdf

 

[daver2]

CP/M 2.2 supports the direct I/O (function 6) so I will modify my program for that.

I love the Z80 - so I generally write my 8080 and 8085 software in a Z80 sub-set but use the Zilog mnemonics.

These are incompatible with ASM. However, I also use M80 for CP/M as this supports the Zilog mnemonics.

Dave

 

[daver2]

Ok,

Here is the latest software...

Unless you find any bugs (either mine or original) I will just tweak the comments later when I get some more free time.

I would suggest using asm80.com in the first instance to generate a HEX file, downloading that HEX file, and then convert that from HEX to whatever you want.

Dave

 

[Hugo Holden]

Ok,

Here is the latest software...

Unless you find any bugs (either mine or original) I will just tweak the comments later when I get some more free time.

I would suggest using asm80.com in the first instance to generate a HEX file, downloading that HEX file, and then convert that from HEX to whatever you want.

Dave

Thanks Dave.

I will post the results when I get it running. Still waiting for IC's and sockets to arrive, it may be a few weeks before the hardware is finished.

 

[Hugo Holden]

@nullvalue:

I have been doing some pcb assembly, I noticed that on the middle board in the camera with the MC14572 IC, on the silkscreen, one of the 27k resistors is labelled 15k, and the 100pF capacitor position is labelled as 47(presumably for 47pF). Was that some sort of intentional change or modification, or should we stick to the 27k & 100pF ?

Also I noticed on board 1 of the 88CCC, the pin array for the 2N3646 the transistor body is rotated 180 degrees compared to what the part requires, it could possibly encourage somebody to fit the transistor with the C-E terminals reversed, but it willl work it is just that the transistor's base wire would have to be bent between the C&E wires to mount it. If 2N3904 is fitted instead, the silkscreen circle with the flat lines up and all is good.

On another topic I noticed Cromemco's camera circuit, the voltage regulators. They show two 0.1uF caps in parallel on the 7808 ad 7908 regulator's inputs. Looking at a photo of the camera insides it looks like Cromemco simply used gigantic 0.1uF disc capacitors on each side of the board. A large part like that is a lot better than any modern small 0.1uF disc or a tiny monolithic ceramic part. That is probably why they got away with that. I think its a risky proposition for voltage regulator instability just with only two small 0.1uF caps on the regulator inputs. The minimum recommended value for the input capacitor on a 78xx regulator part is generally 0.33uF, and especially since it is being fed by a cable to the camera the is say 6 feet or so long. So in my unit I simply replaced one of the two 0.1uF input capacitors on both the 7808 and 7908 regulators with a 10uF 25V Tant, just to be on the safe side. So it leaves the input with a parallel Tant capacitor with one 0.1uF capacitor. If you do it too, make sure to get the polarity of the one on the negative rail correct.

Also I notice that in the photo, they appear to have added a reflective foil to the inside of the enclosure, so as to bounce some light back from the two LED's onto the image sensor.

And one other thing, as far as I have been able to determine, the types of D mount lenses we are using for 8mm film work, the focal plane where the image sensor (or "film") must be is 12.29mm(0.484") from the flange of the mounting face on the lens. Do you agree with that? It seems to match roughly up with what I see in the photos. I was thinking that it might required to have to position the socket with the image IC in it, off the board a little in a specific position to get it accurate. It could depend on the type is socket used and its profile. And I think the board might need to be shimmed in the slots in the case to prevent it changing positions.

Here is some stuff on the flange distance, probably Cromemco were only using the Camera for near objects (not any images at infinity) so the error in the flange length would adjust out with the lens:

Flange focal distance - Wikipedia

en.wikipedia.org

 

[hmb]

I have been doing some pcb assembly, I noticed that on the middle board in the camera with the MC14572 IC, on the silkscreen, one of the 27k resistors is labelled 15k, and the 100pF capacitor position is labelled as 47(presumably for 47pF). Was that some sort of intentional change or modification, or should we stick to the 27k & 100pF ?

This issue is discussed on page 3 of the original Cromemco ACC manual. The PCB silkscreen on the reproduction has the same error as the original PCB for the values of C5 (should be 100pF, incorrectly printed as 47pF) and R4 (should be 27K, incorrectly printed as 15K).

My assumptions regarding the optimum distance between the D-mount lens and the sensor surface are the same as yours.

 

[Hugo Holden]

This issue is discussed on page 3 of the original Cromemco ACC manual. The PCB silkscreen on the reproduction has the same error as the original PCB for the values of C5 (should be 100pF, incorrectly printed as 47pF) and R4 (should be 27K, incorrectly printed as 15K).

My assumptions regarding the optimum distance between the D-mount lens and the sensor surface are the same as yours.

OK thanks! For some reason I missed that in the manual, but if you knew that was the case, whay did you not correct the labels on the pcb ?

One interesting thing in this case, is that it is not actuallly possible to check if the image is in focus on the Chip. Because it only has a digital output. In analog systems you can do it by inspecting the high frequency components in the analog signal.

 

[daver2]

@Hugo Holden,

With a minor tweak to the software (one byte I think), we can get the software to work with the Dazzler but just ignoring the camera.

We can then 'stuff' dummy data into the camera buffer (starting at 1000h) to observe the result on the Dazzler.

You can set the buffer up outside of the program, then run the program to see the results.

It may also be better to set the Dazzler mode into 32x32 colour so we can see the actual pixel 'value' stored in the Dazzler display as a coloured pixel rather than a shade of grey - so two changes.

I will post more later.

Dave

 

[Hugo Holden]

@Hugo Holden,

With a minor tweak to the software (one byte I think), we can get the software to work with the Dazzler but just ignoring the camera.

We can then 'stuff' dummy data into the camera buffer (starting at 1000h) to observe the result on the Dazzler.

You can set the buffer up outside of the program, then run the program to see the results.

It may also be better to set the Dazzler mode into 32x32 colour so we can see the actual pixel 'value' stored in the Dazzler display as a coloured pixel rather than a shade of grey - so two changes.

I will post more later.

Dave

Hmmm, that sounds interesting.

I have been thinking more about this camera and starting to wonder why, since the output of the image sensor is digital, how they proposed to get some "shades of grey out of it" since the Dazzler board is capable of shades of grey on the 32 x 32 output mode.

It appears that cells in the image sensor chip, that how shall I put it, are on the bordeline betewen being either on or off (logic high or low) would over a number of frames collected, you could get a sort of average for the light level falling on them. For example by averaging frames, by the 12th frame capture thing at least, using the software that you so elegantly reverse engineered, in essence recreating a sort of analog sensor function, to paint the image in a grey scale. If you think I am talking nonsence please say so, because it might be the Chardonnay talking. But there is more...

I once was told that if you were looking at a person holding a tray, like a breakfast tray, covered in many small discs, about the size of a dime, on one side the discs were white and on the other side they were black, and the person holding the tray was shaking it up and down to make the discs fall randomly, that on the average 50% of the discs would be black side up and 50% of them white side up. But due to the random geographic distribution of them over the surface of the tray, if you viewed the tray from above at say 20 meters away, averaging them, the tray would simply appear grey in color or better put luminance level. (except that once in a blue moon the Mona Lisa would appear for a moment, or any other image you imagined)

I wondered why when I first saw the Cylops/Dazzler software that they were capturing 12 to 15 frames, when only one frame could do it, do you think the above is the reason ?

 

[daver2]

It as something to do with the 2 milliseconds delay between the 'n' frames that it collects.

For each pixel of the dazzler display, the software sets the pixel value to 0 when it starts processing the pixel data from the camera frames (= black).

For each corresponding pixel in each camera frame, a value of 1 is added to the Dazzler pixel value if the corresponding pixel value in the camera frame is a 1. This gives us our grey scale.

The question now is what does the sensor do in the time gap between frames?

I will hunt the data sheet out...

Of course, it is just a 1024 bit DRAM with the lid removed...

The light falling on the DRAM cells causes the charge to dissipate at a rate proportional to to the illumination of each cell.

You precharge each cell with a logic '1' and then sample each of the 1024 cells multiple times with a constant time gap between the samples.

The speed (= the number of frames) at which a given bit flips from a '1' to a '0' is proportional to the light illumination.

The more logical '1's there are across the frames, the higher the Dazzler pixel value counts, meaning the closer to white the pixel becomes.

Dave

 

[Hugo Holden]

It as something to do with the 2 milliseconds delay between the 'n' frames that it collects.


Dave

The output from the image sensor for any pixel address generated by the 4040 IC, can only be a 0 or a 1. So to get any grey scale out of that , it must be that certain locations are changing depending on light level and change their state over time. 2mS must have been a significant figure where enough of them are altering state to acquire a signal that could ultimately be interpreted as a grey scale. It must be a ramp like decay, where the longer one waits, for some fixed illumination level, the more likely a memory cell will change state. It is quite something isn't it ? to acquire (or create) a sort of analog result (or a grey scale at least) from a sensor chip where its output is 0's and 1's, it is reminiscent of pwm that achieves the same thing, but not the same.

I wonder if the designers got the idea of how to create that clever frame software for the better result, after seeing the Cyclops Camera image on the X-Y scope. It would be interesting to build that scope adapter, if for nothing other other than to test out the camera and understand exactly what its image sensor was doing.

 

[daver2]

I remember back in the early 80s removing the top of a ceramic DRAM chip and using that as a light sensor.

There were two 'halves' of the chip (with a gap between them) so you could only use part of the DRAM array for the sensor.

One problem we did come across at the time was that DRAM chips from different manufacturers used a slightly different mapping of extrnal address lines to RAM matrix - so a bit of playing with the address lines was necessary to achieve the desired result.

Going back even further, I remember scraping the black paint off the glass encapsulated OC71 transistors to make a light sensitive transistor. This was much cheaper than buying the OCP71 transistor which was designed for use as a light sensor - but at a price I couldn't justify being a school kid. My dad could get me plenty of black OC71 transistors from his contacts!

Dave