Modding the Kodak Reels 8mm Film Digitizer (Firmware Hack)

[Joe90]

Curious. It looks incredibly similar. Even the menu UI appears to be the same. Is it worth me getting a chip programmer and dumping the firmware? I assumed they were all based off the same hardware with (at most) slightly tweaked firmware.

I'm assuming these are all variations on the Winait DV188N and DV180N? The only difference between those seems to be the 7" reel capability of the 188.

Apart from the Kodak machines they all look very similar but some have different hardware (e.g. LCD panels).
If you can get a copy of the firmware using a chip programmer, I'll happily make you a firmware image with the modifications you want from the forum here. You'd also be helping a user on VideoHelp who can't start their M127 machine after flashing Somikon firmware to it.

 

[Kai Robinson]

For things like firmware, please, by all means use the resources section to store them.

 

[Hawke]

I was about to give up, it took about 150 builds to allow the use of the lens' full FOV, without the color going wrong.

New lens should be arriving Monday. I still feel the image pipeline is still losing resolution somehow, so maybe none of this will work out. The challenge has been fun.

View attachment 19905

Impressive work.
Can you perhaps already provide this firmware for the C model?

 

[0dan0]

Seems my new macro lenses are potentially held-up in customs. In the meantime here is the latest build (type C) where you can use the existing reframing controls to scan everything the sensor sees. This is great for hardware hack that want to do 16mm scan with the existing lens, or replace the lens for high-res scans of 8mm. This hack increases the zoom-out range 2.3X over the stock firmware.

Here are the list of updates since the white balance hack (included here):

A lot of new code added between 0x1fbdb4 and 0x1fc000. This replaced a lot of old dashcam code related to audio, so I have this area to do new development.

0x1fbdc0 - prints to serial port the current pixel offset and image size

offset:972 482
size:840 632

0x1fbe00 - modifies the offsets and sizes (for preview)

0x1fbe80 - prints to serial port the offsets and sizes

offset:432 78
size:1920 1440

0x1fbf10 - modifies the offsets and sizes (for capture/recording)

0x239930 - zeroed out a jump to print and unneeded console message
0x239980 - zeroed out a jump to print and unneeded console message

0x2a1750-8 - the complete fluke/guess to fix the color error with the CFA offset. This prevents a jump to calculate the offset, and instead sets v0 to 0x200. I do not know why this works.

0x2b7e44-60 - replaced auto white balance with hard coded RGB Gains. Red-0x2b7e44-46 = 0x200, Green-0x2b7e48-4a = 0x100 and Blue-0x2b7e4c-4e = 0x100

0x2bf928 - removed another unwanted printout

0x2bf908 - This is the function the gets the preview frame offset and size. It was modified to jump to 0x1fbdc0 to tweak the calculations

0x2bfe70 - This is within the function the gets the capture frame offset and size. It was modified to jump to 0x1fbe80 to tweak the calculations

Tools used so others can enhance further (I had used none of this before, learned for this project):
- NtkTool - for packing and CRC the firmware https://dashcamtalk.com/forum/threads/ntktool-bngui-v0-4-novatek-firmware-packer-unpacker.29281/
- Ghigra - to decompile the firmware (Reels code is MIPS 32-bit little endian) https://ghidra-sre.org/
- web MIPS tools to learn the opcodes
https://mips-converter.jeffsieu.com/ (single instruction analysis)
https://www.eg.bucknell.edu/~csci320/mips_web/ (single instruction analysis)
https://shell-storm.org/online/Online-Assembler-and-Disassembler (code assemble disassemble)
https://rivoire.cs.sonoma.edu/cs351/wemips/ (MIPS emulation)
- Also used local LLMs via Studio LM to as a crude compiler (this got be started.)

 

[0dan0]

Have my new macros.

Surprisingly does get the film mostly in focus, some edge softness.
However, is confirmed my fears that there is something else limiting the resolution of this system.

So while new lens has almost perfect coverage, it is not improving the resolution as expected, there still seems to be some low-res stage that the image processing is operating at. When at max zoom out, there shouldn't be upscaling halo artifacts we see here (highlights have darker dots in the middle.) These dots are not present (less so anyway) when setting the Reels zoom-in to max. This is not a lens artifact, to get generating in the processing pipeline. This is all with sharpness set at -2.0. So while the hacked firmware is reading a full 1920x1440 image, and encoding at 1600x1200, there is interim processing at 640x480 or similar.

Anyone want to help be find this next stage of the hack?

 

[fishgee]

0dan0:​

I would love to help with your upgrade investigations, but my background is electronics hardware, not software. So I'm not sure I have the expertise you need. If you have any low level grunt work that would help you out, let me know.

 

[Hawke]

Have my new macros.
View attachment 19961
Surprisingly does get the film mostly in focus, some edge softness.
However, is confirmed my fears that there is something else limiting the resolution of this system.View attachment 19963

So while new lens has almost perfect coverage, it is not improving the resolution as expected, there still seems to be some low-res stage that the image processing is operating at. When at max zoom out, there shouldn't be upscaling halo artifacts we see here (highlights have darker dots in the middle.) These dots are not present (less so anyway) when setting the Reels zoom-in to max. This is not a lens artifact, to get generating in the processing pipeline. This is all with sharpness set at -2.0. So while the hacked firmware is reading a full 1920x1440 image, and encoding at 1600x1200, there is interim processing at 640x480 or similar.

Anyone want to help be find this next stage of the hack?

Hello,

I have now ordered the UART adapter and hope to receive and install it this weekend.
I haven't worked with Ghidra yet, but I'm no stranger to assembler. I'll take a closer look at the subject, but I only have a few hours at the weekends. But I hope it just takes longer, but that we can still solve the problem here

 

[0dan0]

@Hawke this is excellent news.

I have determined when initializing the preview from the function at 0x2bf908, the corner offset and capture image size and followed by the processing resolutions.

For max zoom out.

This data return by 0x2bf908:

732​

452​

840​

632​

840​

632​

1260​

840​

632​

1260​

First two are the top left corner coordinate form the 3.2K sensor. corner:892 482
Followed by the image size: 840 632 within the 1920x1440 maximum window.

We see 840, 632 repeat twice, and 1260 are likely image pitches (4:2:0 chroma.)
As you zoom in, the data changes like this:

738​	460​	828​	616​	828​	616​	1244​	828​	616​	1244​
746​	464​	812​	608​	812​	608​	1220​	812​	608​	1220​
752​	468​	800​	600​	800​	600​	1200​	800​	600​	1200​
760​	476​	784​	584​	784​	584​	1176​	784​	584​	1176​
766​	480​	772​	576​	772​	576​	1160​	772​	576​	1160​
774​	484​	756​	568​	756​	568​	1136​	756​	568​	1136​
780​	492​	744​	552​	744​	552​	1116​	744​	552​	1116​

For a stable preview, I only altered the first four columns. My theory now is the processing resolution and the maximum resolution for input to the LCD are the same. We using high contrast straight edge, the aliasing for a 1920x1440 capture, put the processing resolution between 830 and 850 pixels, so 840 of columns 5 and 8 are likely processing stages. If I accept a bad LCD render (for now), can we run the processing at 1920x1440, is 5.2X pixel count gain over 840x632. This should work as we know the dashcam hardware this is based on could do it.

The function capture setup at 0x2bfce0 only has four parameters (that I've found), corner offset and resolution. So even if the preview is set to full resolution, with a flickering LCD, when capture begins the LCD looks fine. This means that somewhere else the pipeline is being reinitialized to 840x632. This is a good, thing and it another lead, hope if still here.

What need to happen is to initialize capture at 1920x1440 (done) and processing at 1920x1440 (not found yet,) and finally encoding at 1920x1440 or similar.

 

[Captain Noob]

Hello,
I have a Kodak Reels "Type C" machine and I've read about all the fantastic firmware modifications implemented so far. Before I will try to flash my machine with a modded firmware, I wanted to backup the original version. But I'm stuck with the following problem:
I attached/soldered a TTL-USB adapter to the mainbord and installed Putty on my PC. It works fine and Putty also shows the console-output of the device, but my problem is:
I´m not able to issue a command to the machine (to backup the firmware etc.). The command prompt in the terminal window doesn't show up.

Any ideas what I´m doing wrong?

I can send text to the machine which is also displayed in the terminal-window, but I´m not able to "force" a command prompt to the output-screen. And once again, I´m really impressed by all the things you all have done so far!
And best greetings from Germany!

 

[0dan0]

In the PuTTY Terminal configuration set Local echo to "Force on" works for me.

 

[Captain Noob]

In the PuTTY Terminal configuration set Local echo to "Force on" works for me.

Thank you for the reply. I also checked both Line-discipline options. Could you send me the text-output when you turn-on your machine? I would like to compare it with my output (see mine attached below)
As I said, I can send "text/commands" to the machine and it´s also displayed in terminal window, but it´s ignored by the machine and not executed. And I don´t know if I have to wait for some kind of "command prompt" like ">" or so.

 

[0dan0]

Seem the RX might not be connected.

This is my current console output.

 

[0dan0]

Yes, an Enter key will get me a prompt >

 

[Captain Noob]

Seem the RX might not be connected.

This is my current console output.

You are correct! The Tx->Rx pin is indeed faulty! Thank you for the hint!

 

[Hawke]

Hello,

somebody know where to buy a compatible display for the C-Model?

 

[0dan0]

Hello,

somebody know where to buy a compatible display for the C-Model?


View attachment 20028

what happened?

 

[0dan0]

I have now proven this hardware is capable for a 2K scan (1920x1440).

Now while it is has issues, major glitches, this is a pixel of pixel encoding at 1920x1440, no interim scaling.

I'm seeing details that have never showed before, the sharpness of the sprocket edge, and one pixel thick scratches, no aliasing anywhere.

Also the above image is at sharpen 0.0. Clearly the sharpness was tuned for this resolution (i.e. Dashcam res), not the crazy results it get with the cropping region of the default lens.

Attached is the current work in progress build, no not use unless you want develop on it.

Search on strings HACK PT1 and HACK PT2. PT1 is the preview setup, and PT2 is the record setup, lots of new code in there.

If you zoom-in the capture works correctly, like stock FW, as the working frame buffer shrinks to 840x632 (and smaller.) All the code changes is the width, height and pitch of the frame. At the larger sizes we are getting buffer corruption, same memory is being used twice to different purposes. Maybe somewhere in the code there assumptions for buffer size. The SoC has plenty of memory, so this is fixable. I just don't have any strong leads.

I never never worked out where the 840x632 (res at max zoom-out) is originally computed, only where the results of that computation are stored. The hack modify places where the resizes are stored in memory. I expect something is using the size before I modify it, so frame buffers are allocated with the wrong size. Also frame buffers are likely allocated once on startup, so find that, we may have a stable working solution to upgrade a standard def res. scanner to be a 2K scanner.

This is a demo of how far the resolution can be improved. Both are crops from 1920x1440 encodes with a higher bit-rate. Left is a new lens using most of the sensors capture area, right is the stock lens with a much smaller capture area.

 

[Mac84]

Absolutely amazing progress @0dan0 ! I would have never guessed there was some in-process scaling. The results are truly impressive and I am eager to see what you discover next!

 

[0dan0]

I'm diving into where the frames are stored in memory, and have run into a new question. When the system boots it reports:

NPT
DV280 Loader NT96658 Start ...

658B_DDR3_LV1_3_1024Mb 06/28/2020 21:25:22

I always read that 1024 as 1GByte. Yet that Mb <- seems to be Mbits. Only 128MBytes, that is tiny. Does anyone have the parts list, or images on the underside on the mainboard? I'm looking for the part number for the DDR memory. When I do a memory dump, the data repeats every 128MB, so it seems confirmed.

Having a small memory, might explain the tiny frame buffer Reels has designed for.

 

[Mac84]

I'm diving into where the frames are stored in memory, and have run into a new question. When the system boots it reports:



I always read that 1024 as 1GByte. Yet that Mb <- seems to be Mbits. Only 128MBytes, that is tiny. Does anyone have the parts list, or images on the underside on the mainboard? I'm looking for the part number for the DDR memory. When I do a memory dump, the data repeats every 128MB, so it seems confirmed.

Having a small memory, might explain the tiny frame buffer Reels has designed for.

Oh interesting, I think I saw 1GB, but that divided by 8 is 128MB.

I think there is a Novatech SOC which I think has embedded memory. I’ll attach some photos to this post, but I don’t think I see any other chips that could be RAM related.