Making a DSU from scratch for an orphan DCS100

[pieroc91]

I'm still here as well! In fact, I've just added a few new users, after dpreview announced their closing.

Jarle

That's awesome, let's bring back to life the forum! (very sad the closure of DPReview)

[pieroc91]

On a side note i noticed the sensor to be almost not responsive to blue light, maybe the pigments went dead?

Maoby, who is a vintage digital collector from Canada, has posted some comparisons with his DCS100 and other cameras. This is one vs a D500: https://www.flickr.com/photos/maoby/462 ... 960370835/

In his shots, he's getting some blue, but very little green. I don't know/remember how he is processing these raws to jpg. It may be that in his case, and maybe in your case, too, the demosaicing process is not correctly interpolating channel signals to adjust for color response of the channels, crosstalk, etc...

Maybe try pure red, green, and blue captures, with filters, or test patches, to see how the sensor + CFA are responding to those colors?

Hmmm... just thought that maybe these early cameras didn't use RGGB CFAs. Sure enough, the DCS Story says the M3 used a 3G RGB CFA. Not sure what that is, but it may be this: https://patents.google.com/patent/US5374956A/en

Hi SQLGuy! you were absolutely right about the 3G RGB CFA, color balance is another story.
I'm talking to Maoby on DPRevived and he handed me some "RAW" from his DCS100 and i was able to test how to recolor.
Indeed i could see the same behavior as my sensor responding quite wierd to colors, so I guess my sensor is just that way.

At first moment i tried a color bar then some RGB circles and indeed, blue response is almost none but i guess that's enough to recover color data.

Maoby's pic with some manual processing on PS for color recovery:

[pieroc91]

On a side note i noticed the sensor to be almost not responsive to blue light, maybe the pigments went dead?

In his shots, he's getting some blue, but very little green. I don't know/remember how he is processing these raws to jpg. It may be that in his case, and maybe in your case, too, the demosaicing process is not correctly interpolating channel signals to adjust for color response of the channels, crosstalk, etc...

Oh, as far as i can see he is using the original plugin for PS 6 on a Powerbook G3.

[pieroc91]

Well is not much but is honest work.

For the next step i'm doing a small cache inside the FPGA itself so i can format the information and re sync it in order to send it faster than the camera rate so i have some idle time between bursts of data and allow the PSRAM to self-refresh. After much struggle with the cache size i got it somewhat working.

Those repeating patterns is the cache sending the same cached data multiple times. It is not internally syncronized to anything internally, that's why it looks that bad, also there was no picture being taken, just a "black" frame.
The idea is only send the data to RAM once and the rest of the times (the other repetitions) left the RAM idle so it refreshes happily.

[pieroc91]

After testing with some actual image i wasn't reading anything coherent and after looking at some signals i found some that didn't look as expected coming from the camera, not sure actually why, they look fine with the logic analyzer but the fpga picks them up quite bad.
Anyway, it was easier to ignore that signal and that gave me some coherent readings.

That image was actually cached on the FPGA and resync before going out, i'm having issues syncing things inside the FPGA, that image already looks jittery and cache size was only 2 bytes, if i extend the cache size to 128 bytes (what i intend to use) i got a jittery mess.

That's the same shot but very underexposed

Anyone know how to unlock the XXX channels?

[pieroc91]

Well well well, ignoring that bad signal wasn't the route to go, but having that signal messed up lead me to the problem of not having good clock from the camera, probing around showed me some not so nice signals and decided to check how was implemented on the schematics.
Sure enough, i'm missing all the pull down resistors on every signal... this thing did stuff by miracle.


It's time to add those resistors and try again.

[Stan Disbrow]

Hi,

Ah. So you made Maybe Gates. Been There. Done That.

Stan

[pieroc91]

Hahaha maybe gates, that's a really good one.

Well adding the pulldowns didn't "fix" the issue of that signal, strangely enough I took apart the DCS to trace the signal till the point I know is correct because it is used in circuit to drive the Horizontal gate (which works as intended) and it looks exactly the same... maybe that signal actually looks like that and I was expecting something else.

The good thing is now I now there is no problem with the camera and I need to workaround it by coding.

[pieroc91]

AH! improvements at last... inspected every signal, every line of code and it was all correct.
Not sure how this fixed it but it did, on every clock cycle I made the FPGA to copy the state of the camera clock to an internal FPGA register and used that register as clock instead of the clock directly... and that worked.
My guess is that something internal on how the FPGA assign signals when are defined as clocks must be causing some weird behavior and considering it a regular signal instead of a clock fixed it.



Now is time to get back to the cache part, on which i started working a little bit and see how it behave with different speed and sizes



Is not OK at all but is somewhat behaving as far as its coded.

[pieroc91]

As most of you pretty sure noted my DCS is missing the shutter button assembly so... why not use it as an opportunity to learn 3D modeling while I think about ways to code what's missing. I'll send my first design to the print shop and i'll post the results. Wish me luck.

[pieroc91]

Well, not only 3d work has been done, i've managed to fix the internal FPGA caching, i'm still having issues with my clock signal doing weird jumps. I've found that if i replace the statement "if <something> = <value>" for "if <something> > <value> -1" reduces the issue, which is super strange because those are totally unrelated things. There's something very weird happening inside my FPGA.


That's how the camera cache spits the image, the black bars should be straight.


Removing all the 00s from the file i can reconstruct the read, removing 00s is also removing black pixels which induces that jitter but is good enough to know my cache is working correctly.

[pieroc91]

Well, i'm very surprised on how my 3d printed shutter button resulted being my first 3d model ever, only needed a few minor adjustments (sanding and painting are on the todo list) and is quite a painful to ergonomics but hey, the rest of DCS is also ergonomic as a lego brick so i think i got that fine.



Also i finally got the clock signal working as it's needed, i had to synthesize a new clock signal from the fpga clock and then sync it to the camera clock to get a reliable clock signal, is not a real fix but a very elaborated workaround, the important thing is now it works.

I need to polish some cache timings and addressing and i'm ready to start the RAM implementation.