Thanks for the reply. I can't seem to get things to improve. If I flip the connector around it seems to short out the CH341a and not even that is detected. Flip it back and it's ok but doesn't detect the chip. I'm at a bit of a loss. There's only really 2 ways you can connect the thing up that I can see. Unless I have to bridge any of the connectors on the CH341a?
Modding the Kodak Reels 8mm Film Digitizer (Firmware Hack)
- Thread starter Mac84
- Start date
Do you have any other electronics with a compatible rom on it that you can test your reader with? That way you'd at least prove that the reader and its cables are still functioning properly.
Resolution hacking updates.
I was finally able to move the input buffers so that will not collide with each other. This took ages to work out, as there are multiple areas that the read and write these buffer addresses, some seem to be within interrupts.
So I can now capture 1920x1440, process and encode at that resolution -- for about 130 frames.
The new main issue is the while I moved the input frames to the very end of the memory, the H264 compression buffer is huge, and it eventually runs to the end of memory (same locations.) So the next step will be to reduce the size of the compression loop buffer.
So many other issue to address.
1) Current the optics are still wrong. I'm using an 8.5mm lens mount about 15mm closer, so close I have to remove to lens to load film. Also too close that when I focus for the center, the edges are out of focus. Ultimately, a 12mm or 16mm macro lens, mounted slightly higher than the stock lens might be needed. Currently my 12mm macro will not focus at stock Reels distance.
Here is a full 1920x1440 scan with this system:
2) The compression at 1920x1440, is way worse. I'm about to average around 20Mb/s, yet as this is not a 700px image scaled up to 1920 any more, there is more entropy to encode, so this bit-rate is too low.
3) This is lot of work for only subtle changes for Super-8 scans.
Once I get the focus and bitrate issues corrected, the right image will be best. Yet, this is likely too much of a modification of the average user.
Attached in the current firmware (Type C) in ZIP
My first successful true 1920x1440 scan -- this is leader scan shows the resolution benefits, also the compression issues.
I was finally able to move the input buffers so that will not collide with each other. This took ages to work out, as there are multiple areas that the read and write these buffer addresses, some seem to be within interrupts.
So I can now capture 1920x1440, process and encode at that resolution -- for about 130 frames.
The new main issue is the while I moved the input frames to the very end of the memory, the H264 compression buffer is huge, and it eventually runs to the end of memory (same locations.) So the next step will be to reduce the size of the compression loop buffer.So many other issue to address.
1) Current the optics are still wrong. I'm using an 8.5mm lens mount about 15mm closer, so close I have to remove to lens to load film. Also too close that when I focus for the center, the edges are out of focus. Ultimately, a 12mm or 16mm macro lens, mounted slightly higher than the stock lens might be needed. Currently my 12mm macro will not focus at stock Reels distance.
Here is a full 1920x1440 scan with this system:
2) The compression at 1920x1440, is way worse. I'm about to average around 20Mb/s, yet as this is not a 700px image scaled up to 1920 any more, there is more entropy to encode, so this bit-rate is too low.
3) This is lot of work for only subtle changes for Super-8 scans.
Once I get the focus and bitrate issues corrected, the right image will be best. Yet, this is likely too much of a modification of the average user.
Attached in the current firmware (Type C) in ZIP
My first successful true 1920x1440 scan -- this is leader scan shows the resolution benefits, also the compression issues.
Last edited:
Filed some plastic off the clip and managed to read it. I've attached the raw dumped firmware from the M127 machine, plus the unpacked partitions from ntktool. When I open it in ntkMPE I get the following options.
I've not been brave enough to modify them and flash it back yet. Looks like the firmware should be named FWDV180NC.BIN or FWDV180N.BIN.
If anyone is interested...
ROM is an MCX25L3206E
Capture chip Novatek NT96550BG (2025-AJ K5FNM)
Theres also a Nanya NT5CB64M16FP-DH RAM chip by the looks of it
Last edited:
I've tried to compress a modified bin with NTK tool and flash it back using an SD card. Curiously if you place any file on the SDCARD with the name FWDV180.BIN the machine doesn't start (screen stays black, no lights). Remove the file and power it on and the machine starts. I assume the BIN file is failing some sort of check. This was when I just compressed the modified partition. I'm trying to recreate the original structure now with NTKtool.
This is the unmodified dump from the ROM>
If I perform the following, I get this:
I tried manually setting the Baseval, but I do not think this is anything to do with setting the offset. I do not want to risk flashing the firmware if the offsets are incorrect.
Does anybody know if this causes an issue? It seems the other firmwares only have a single partition.
This is the unmodified dump from the ROM>
If I perform the following, I get this:
- Unpack both partitions
- Modify larger partition with NtkMPE
- Open partition 1, pack firmware using mode C and leave Baseval
- Open partition 2, pack firmware using mode C and leave Baseval
- Merge the partitions
I tried manually setting the Baseval, but I do not think this is anything to do with setting the offset. I do not want to risk flashing the firmware if the offsets are incorrect.
Does anybody know if this causes an issue? It seems the other firmwares only have a single partition.
Using the cli to pack and specify the offset works, so must be a bug in the UI.
However, merging the 2 partitions or just creating a single bin with the modified partition all results in the same thing. The machine refuses to boot or appear powered with that file on the sd card. Remove the file and all is well. Unsure where to go from here...
Code:
.\bfc4ntk.exe -p "C:\Users\xxxx\Documents\xxxx\CH341\M127 ROM\CAM-M127-A1-V1.0-ROM\[email protected]" "C:\Users\xxxx\Documents\xxxx\CH341\M127 ROM\CAM-M127-A1-V1.0-ROM\[email protected]" 000af000However, merging the 2 partitions or just creating a single bin with the modified partition all results in the same thing. The machine refuses to boot or appear powered with that file on the sd card. Remove the file and all is well. Unsure where to go from here...
Resolution hack update V4. Type C firmware attached
I wasn't able to limit the size of the H264 compression buffer, but by dropping the processing resolution to 1600x1200, on was able to fit one of the two buffers lower in memory, and now have no conflicts. The bit-rate control was struggling with all the additional grain/texture, so this build is now running a fixed QP of 25. This sets the bit-rate between 30-60Mb/s (image dependent) and is stable in my tests.
This firmware will work with a stock lens, but the resolution benefits will require a different lens with a narrower FOV.
Compare these frames between my V2 firmware (stock processing, stock lens, fixed WB) and V4 with a new lens and 4X resolution on the processing. While there is only limited subject detail improvement, the grain is more natural. Note: nly the center is the new lens is anygood, too much blur and chromatic aberration on the outer parts of the frame. Now with stable firmware (mostly, I did break playback somehow) I can fix my lens issues.
I wasn't able to limit the size of the H264 compression buffer, but by dropping the processing resolution to 1600x1200, on was able to fit one of the two buffers lower in memory, and now have no conflicts. The bit-rate control was struggling with all the additional grain/texture, so this build is now running a fixed QP of 25. This sets the bit-rate between 30-60Mb/s (image dependent) and is stable in my tests.
This firmware will work with a stock lens, but the resolution benefits will require a different lens with a narrower FOV.
Compare these frames between my V2 firmware (stock processing, stock lens, fixed WB) and V4 with a new lens and 4X resolution on the processing. While there is only limited subject detail improvement, the grain is more natural. Note: nly the center is the new lens is anygood, too much blur and chromatic aberration on the outer parts of the frame. Now with stable firmware (mostly, I did break playback somehow) I can fix my lens issues.
Last edited:
Finally worked out how to keep the correct offsets after modifying the firmware.
- Open the firmware dump with NtkTool
- Make a note of the offset of partition 1
- Use the bfc4ntk.exe tool to extract and specify the offset of partition 1
Code:.\bfc4ntk.exe -x '..\M127 ROM\m127orig.bin' '..\M127 ROM\[email protected]' 000af000 - Open the decompressed firmware with NtkMPE and set the desired bitrate
- Use bfc4ntk.exe to recompress the modified ROM at the same offset
Code:.\bfc4ntk.exe -p '..\M127 ROM\[email protected]' '..\M127 ROM\m127modified.bin' 000af000 - Open the modified ROM in NtkTool and compare the offsets and extracted sizes. These should now match.
3D printed the lens offset. Attached is more model for the 3D print. Now my frames in focus and not skewed. There is even space between the lens, and the open film loading door.
V4.2 (Type C) still occasional saw a buffer collision between the compression data, and the second input frame buffer. This firmware should address that.
While my hardware hack is about done, there are still quality improvements to achieve. In this example, some damaged film jammed the feeder, but when the frame was held the quality went up.
So difference between the frame is hurting the quality.
When the grain was different between compressed frames, the image is blurred, particular when the scene lack contrast:
But when the frame isn't moving, there is significantly more details (this is the grain I want in every frame.)
This could be a QP factor for P frames? Any ideas on what this could be?
Last edited:
I also tried to change the lens. I bought one with a 12mm focal length, but without luck: There´s no chance to get a decent focus. Also the threading of the lens seems "very cheap". Which lens did you buy?
I went through a lot of lenses. It has to be a macro lens, and they are rare (or at least poorly described.) Also with any lens you will need a spacer to move the lens further away from the sensor to focus. Optically a 12mm lens would be 12mm from the sensor to focus at infinity, here we need to be more than 12mm away (mine is ~20mm from the lens front) to focus ~28mm away. 7mm spacers are common-ish, but I found 5mm, which is what I needed.
All purchased from Scorpion Vision in the UK. Shipping is not cheap. The lens I used is the SVL-1228MAC
Lens: https://shop.scorpion.vision/products/m12-lens-12mm-f2-10
Spacer: https://shop.scorpion.vision/collections/optical-accessories/products/m12-extension-ring-5mm
Hi @domb84
Thanks very much for dumping and sharing the firmware.
There are some other filenames that appear in the smaller partition:
LDDV180N.BIN
FWDV180NT.BIN
FWDV180NC.BIN
You may end up using the programmer anyway, but one of those names might work.
Best,
Joe
Attached in V5.0 firmware.
Locked quantization: QP25
Locked white balance: RGB weights 1.75, 1.0, 1.0
Pipeline resolution: 1600x1200 (to use all of this you need to replace the lens)
Encode resolution: 1600x1200
I moving the seconds input buffer any to just after the encoding working space, but before the compressed output. There is little more unused memory when encoding at 1600x1200. This improved reliability.
Progress from the original high bit-rate hack (scan a month ago, pipelines resolution ~720x540, encode 1600x1200):
V5 Firmware:
Before : After
Locked quantization: QP25
Locked white balance: RGB weights 1.75, 1.0, 1.0
Pipeline resolution: 1600x1200 (to use all of this you need to replace the lens)
Encode resolution: 1600x1200
I moving the seconds input buffer any to just after the encoding working space, but before the compressed output. There is little more unused memory when encoding at 1600x1200. This improved reliability.
Progress from the original high bit-rate hack (scan a month ago, pipelines resolution ~720x540, encode 1600x1200):
V5 Firmware:
Before : After
Attachments
Last edited:
Here is another post to document all my firmware changes to date.
Address map of changes to Type-C Reels firmware (should help in supporting other types)
0x13a2f0 - I'm hooking a function call to 0x13b4b0 that set up the input buffer address (either the read or write location)
Hook code is between 0x1fc1a0 and 0x1fc240
0x1fbdb4 to 0x1fc240 All the new code is replacing legacy audio functions.
0x239934 - zeroed out a jump to print and unneeded console message
0x239980 - zeroed out a jump to print and unneeded console message
0x23fdf8 - replace the dynamic QP value (compression quantization) with a fixed value.
was lw $a, 0x38($s1)
now ori $a2, $zero, 0x19 (using QP 25)
0x2a173c to 0x2a1758 - this mute the error message "CFA need to be R", saying the Bayer phase was wrong, and the color was bizarre. Instead this prevents a jump to calculate the offset, and directly sets $v0 to 0x200. I do not know why this works.
0x2b7e44-60 - replaced auto white balance with hard coded RGB Gains.
0x2b7e44 Red = 0x1c0
0x2b7e48 Grn = 0x100
0x2b7e4C Blu = 0x100
0x2be8cc - Muted the error message "CA VIG Setting not ready" - my guess this is a lens shading error, as the FOV was changed and the resolution increased, it doesn't have the shading correction for this lens at that FOV (or the new lens). Lens vignetting is not a big issue (I see no issues.)
0x2bf928 - removed a function call to 0x27aee4 and set the return $v0 to 0x0. Which would check and print "convert 2 sen id fail". Not sure why I needed this, might now be unnecessary. This change is harmless.
0x2bf908-a84 this function was altered to create space, for a jump to 0x1fbdd0. The changes are not significant, only I hadn't learned yet how to redirect function yet. The jump to 0x1fbdd0 computes to the frame size for the large FOV, and prints out the size changes.
The new size calculations:
new_width = (old_width-440)*4;
new_height = ((new_width/2 + new_width/4)>>2)<<2; // 3/4 width and divisible by 4.
new_x_offset = abs(old_x_offset + old_width/2 - new_width/2);
new_y_offset = abs(old_y_offset + old_height/2 - new_height/2);
0x2eab6c - I'm hooking a function call to 0x2ea95c that set up the input buffer address (either the read or write location)
Hook code is between 0x1fc0f0 and 0x1fc190
0x2eae00 - I'm hooking another function call to 0x2ea95c that set up the input buffer address (either the read or write location)
Hook code is between 0x1fc040 and 0x1fc1b0
0x2bfe74-e9c - This for capture size calculations. Does the same math as the preview, but with no print out. Calculation code is between 0x1fbf10 and 0x1fc000.
0x333f28-0x3376c0 Replaced boot JPG image
0x3376c8-0x33ae70 Replaced shutdown JPG image
0x3301c0 and 0xdb12b0 I changed the folder name from "Filescanner" to "Filescan5.1". I needed a way to easy compare and track firmware versions.
0xdbd910-984 All the strings used for formatting messages.
V5.1 is attached, just has code clean up (same functionality as v5.0.)
Future hack ideas:
1) Getting more grain texture unfortunately is fighting with the nature of long-GOP compression, and increasing the bit-rate seems to reduce the reliability. Why there are buffer over runs when it is only encoding 2fps doesn't make sense.
2) Frame control for 18 or 24, would be nice (20 is weird.)
3) Find the auto exposure, tweak that.
4) White balance controllable, rather than fixed.
5) please add more...
Address map of changes to Type-C Reels firmware (should help in supporting other types)
0x13a2f0 - I'm hooking a function call to 0x13b4b0 that set up the input buffer address (either the read or write location)
Hook code is between 0x1fc1a0 and 0x1fc240
0x1fbdb4 to 0x1fc240 All the new code is replacing legacy audio functions.
0x239934 - zeroed out a jump to print and unneeded console message
0x239980 - zeroed out a jump to print and unneeded console message
0x23fdf8 - replace the dynamic QP value (compression quantization) with a fixed value.
was lw $a, 0x38($s1)
now ori $a2, $zero, 0x19 (using QP 25)
0x2a173c to 0x2a1758 - this mute the error message "CFA need to be R", saying the Bayer phase was wrong, and the color was bizarre. Instead this prevents a jump to calculate the offset, and directly sets $v0 to 0x200. I do not know why this works.
0x2b7e44-60 - replaced auto white balance with hard coded RGB Gains.
0x2b7e44 Red = 0x1c0
0x2b7e48 Grn = 0x100
0x2b7e4C Blu = 0x100
0x2be8cc - Muted the error message "CA VIG Setting not ready" - my guess this is a lens shading error, as the FOV was changed and the resolution increased, it doesn't have the shading correction for this lens at that FOV (or the new lens). Lens vignetting is not a big issue (I see no issues.)
0x2bf928 - removed a function call to 0x27aee4 and set the return $v0 to 0x0. Which would check and print "convert 2 sen id fail". Not sure why I needed this, might now be unnecessary. This change is harmless.
0x2bf908-a84 this function was altered to create space, for a jump to 0x1fbdd0. The changes are not significant, only I hadn't learned yet how to redirect function yet. The jump to 0x1fbdd0 computes to the frame size for the large FOV, and prints out the size changes.
The new size calculations:
new_width = (old_width-440)*4;
new_height = ((new_width/2 + new_width/4)>>2)<<2; // 3/4 width and divisible by 4.
new_x_offset = abs(old_x_offset + old_width/2 - new_width/2);
new_y_offset = abs(old_y_offset + old_height/2 - new_height/2);
0x2eab6c - I'm hooking a function call to 0x2ea95c that set up the input buffer address (either the read or write location)
Hook code is between 0x1fc0f0 and 0x1fc190
0x2eae00 - I'm hooking another function call to 0x2ea95c that set up the input buffer address (either the read or write location)
Hook code is between 0x1fc040 and 0x1fc1b0
0x2bfe74-e9c - This for capture size calculations. Does the same math as the preview, but with no print out. Calculation code is between 0x1fbf10 and 0x1fc000.
0x333f28-0x3376c0 Replaced boot JPG image
0x3376c8-0x33ae70 Replaced shutdown JPG image
0x3301c0 and 0xdb12b0 I changed the folder name from "Filescanner" to "Filescan5.1". I needed a way to easy compare and track firmware versions.
0xdbd910-984 All the strings used for formatting messages.
V5.1 is attached, just has code clean up (same functionality as v5.0.)
Future hack ideas:
1) Getting more grain texture unfortunately is fighting with the nature of long-GOP compression, and increasing the bit-rate seems to reduce the reliability. Why there are buffer over runs when it is only encoding 2fps doesn't make sense.
2) Frame control for 18 or 24, would be nice (20 is weird.)
3) Find the auto exposure, tweak that.
4) White balance controllable, rather than fixed.
5) please add more...
Forgive the obvious question, but what rating is your SD card you're using? Could that be slowing down the copy process? E.g. my digital camera refuses to record video if the SD card is not an x10 rating or something.
I'm using a SanDisc Extreme Pro, rated to 100MB/s, the scanning is only using ~0.5MB/s. It is an internal limitation to the way the buffering is done (I'm guessing.) This is old dashcam tech, not designed for quality. Reels was originally putting out only 8Mb/s (1MB/s at playback speed, encode is 1/10th of that.) So running four times the internal processing resolution, at four time the bit-rate, we are doing pretty well. But it is still worth seeing if 100Mb/s (12.5MB/s) is possible.
Hi Joe, yes I tried all of those. I have managed to get a better SOP8 clip and I flashed my modified firmware back and it didn't boot. Luckily I flashed the original dump back and it came back to life. I'm going to have another play with it, but hopefully someone who is cleverer than i can modify it successfully!