I cannot seem to create a modified ROM that will boot. I believe it's down to the partition scheme but I'm out of ideas a this point. I can create an image where the offsets match, but after it's been compressed it's ~2.5MB so when it's flashed the rest is filled with 0's. When it's decompressed again it all seems fine, but something isn't right that I'm doing (else it would boot..). I can't imagine the compression algorithm that bfc4ntk is using is so much better when compression the same source that it's knocking nearly 2MB off.
Modding the Kodak Reels 8mm Film Digitizer (Firmware Hack)
- Thread starter Mac84
- Start date
-
It's #MARCHintosh 2025! Join in on the fun and post your project or play with some new stuff in our #MARCHintosh 2025 thread.
First, thank you to 0dan0 and the community here for all the work being done (and shared!). I truly appreciate all of it and its exciting to see how the quality of this product is being vastly improved upon, especially the speed at which you are progressing. While I don't have the experience in tinkering that many of you and others here clearly do, I am definitely a video hobbyist and so I track with most of the technical discussion here.
Second, 0dan0 your list of future hack ideas looks great. A few bits of amateur-level feedback/ideas:
Regarding idea 1 (increased grain/texture).... if dealing with buffer over seems unsolvable, I'm curious if you've explored the alternate approach that gordonmcdowell mentioned back in December:
The sample capture you posted earlier of the Washington monument demonstrated a similar result - where increased time or (duplicate captures of the same physical frame) allowed more detail/texture to be captured in a single frame. While this would increase the time needed to capture a film reel, the end result could be worth it.
As an aside, I feel like gordonmcdowell's comment about the CMOS noise is relevant - that some of the fine detail we're now seeing with the recent improvements you've been making is more likely sensor noise and not necessarily the photo-chemical grain (probably a mix of both). Either way, the look of that detail is nice and definitely something I would like to see in my scans.
Regarding idea 2 (frame control)... I would propose supporting the options 16, 18, and 24. 16fps is the standard for Regular 8mm film, and Super 8 is often 18fps, and occasionally 24 fps. That being said, it is a trivial task in most competent video editing software to easily adjust the source frame rate.
Finally, the "top of mind" request/suggestion (quite selfishly) is that once you've gotten to a more "finished" state, would you or others in the community here provide variations of your firmware files that support the various A/B/C models? I ended up with a version B model, and absolutely hope that at least some of your additional improvements will end up on my model.
Additionally, I don't know that I'll end up going as far as replacing the stock lens with the macro lens to truly benefit from the resolution adjustments you've made. so would it make any sense to also provide a "Stock Lens" firmware option that provides as much of the resolution/bitrate improvement as possible (due to the stock lens' need to "Zoom in")?
Thank you again!
@ThePhage Thank you for the nice feedback. I have never done anything like this before, any firmware reverse engineering. I've never worked with MIPS code, or Novatek SoC. My experience is as a C developer in camera development and video compression, so normal "forward" engineering. So I do have related domain knowledge, and it is fun to try and guess what each code segment does while not bricking my only scanner. I'm supposed to be scanning the in-law's 60-70s film reels, but found the images naggingly wrong, so I've delayed those scans for about 5-6 weeks.
As for the sensor noise, it is there, but not as significant as the grain. The back light is good, dropping ISO to 100, the base for this Aptina AR0330 sensor. I have thought to try encode 2 or 3 times the same frame, to get the extra texture, but I have a better lead on developing my own bit-rate control. The fixed QP25 is only good for some film stock, and sharpness settings, but is leaving quality on the table. I had changed the Qp until the unit stops crashing on some demanding sequences. Now I've found a warning message for a potential buffer overrun, but it is well before it happens. I'm using this message to dynamically reduce the quantization. So now it is automatically running at the best Qp for the scene, averaging over 50Mb/s (looking very nice.) I'm not done with this hack yet, as I only have it reducing the bit-rate as needed, I need to also be slowly increasing the bitrate as the scene complexity changes.
These bit-rate enhancement would benefit the stock lens, as does the white balance fix, but only the lens replacement will help with the scan resolution.
As for porting these changes to Type A & B, that should be straight forward. I'm documenting all my changes to help make that happen. If no else does it, I might try, just harder without a unit to test with.
As for the sensor noise, it is there, but not as significant as the grain. The back light is good, dropping ISO to 100, the base for this Aptina AR0330 sensor. I have thought to try encode 2 or 3 times the same frame, to get the extra texture, but I have a better lead on developing my own bit-rate control. The fixed QP25 is only good for some film stock, and sharpness settings, but is leaving quality on the table. I had changed the Qp until the unit stops crashing on some demanding sequences. Now I've found a warning message for a potential buffer overrun, but it is well before it happens. I'm using this message to dynamically reduce the quantization. So now it is automatically running at the best Qp for the scene, averaging over 50Mb/s (looking very nice.) I'm not done with this hack yet, as I only have it reducing the bit-rate as needed, I need to also be slowly increasing the bitrate as the scene complexity changes.
These bit-rate enhancement would benefit the stock lens, as does the white balance fix, but only the lens replacement will help with the scan resolution.
As for porting these changes to Type A & B, that should be straight forward. I'm documenting all my changes to help make that happen. If no else does it, I might try, just harder without a unit to test with.
Last edited:
I just completed a 2GB capture (3+ minutes of footage) at 82Mb/s (10MB/s). This is using a prototype of the rate control I'm working on.
Here is my new console output. Every two frames the Qp is lowered by one. If the bitrate is stressing buffers, the Qp is increased by 2 or 4, depending on stress level. Crazy this works, but I will tune further before posting.
Averaging Qp 17 is way better than 25.
Here is my new console output. Every two frames the Qp is lowered by one. If the bitrate is stressing buffers, the Qp is increased by 2 or 4, depending on stress level. Crazy this works, but I will tune further before posting.
Averaging Qp 17 is way better than 25.
Version 5.2 Attached.
The bit-rate now averages around 55Mb/s, and gentler version of the new rate control. At 80Mb/s there was still a few capture failures, so still some work to do.
This build also adds 18fps as the default. At address 0x1ef984 use 0x60EA for 20fps and 0xF0D2 for 18Hz.
Next step(s): want to be able to force a stop capture on an error, that way there is less risk pushing for the highest bitrate.
The bit-rate now averages around 55Mb/s, and gentler version of the new rate control. At 80Mb/s there was still a few capture failures, so still some work to do.
This build also adds 18fps as the default. At address 0x1ef984 use 0x60EA for 20fps and 0xF0D2 for 18Hz.
Next step(s): want to be able to force a stop capture on an error, that way there is less risk pushing for the highest bitrate.
Hello 0dan0,
I have a question, is the image with stock res 10 already with the patched ABW? I ask because the right part of the image has a blue cast on the building columns that is not noticeable on the left side. However, a beamer salesman once told me that you should not judge the quality by still images, but always in normal playback. Therefore, it can also just look like this in the still image. Otherwise, as always, great work
Left is completely stock, with original auto white balance, and yes is happens to get the WB pretty good for this segment, but it all over the place through the video. The fixed/locked WB is a tad too blue, but is easy to fix in post.
Here is a short version at 4K, as youtube preserves more at 4K (do play at 4K, as the HD encoding on youtube is bad.)
Here is a short version at 4K, as youtube preserves more at 4K (do play at 4K, as the HD encoding on youtube is bad.)
Hi @domb84
I was messing with the firmware you dumped last night and noticed that after repacking the firmware partitions and merging them, like you have done, that the first 2,296 bytes of the original file are not reinstated. What they are and whether or not some of them need to be updated to reflect the modified firmware I don't know. But prepending them to the merged binary as is is worth a try. You could also try using ntkcalc to update the checksum of the whole binary after merging and prepending. I don't have one of the M127 machines to test with, sorry.
Best,
Joe
Version 5.3 attached. Just bit-rate stability, last version would lower the Qp to a limit of 16, but for some reels this would crash. This build uses 19 at the lowest Qp value, no other code changes. Scanned for hours on this setting. Bit-rate averaging 48Mb/s.
I was hoping to get 80Mb/s stable, but this hardware encoder is only rated at Level 4.2, which is 50Mb/s. While the encoder is running at a low input frame rate, setting a Qp for a larger amount data would occasionally result in:
ERR: H264 ENC Interrupt error! HwInt = 0x10, BSLen = 0x1fa02
crashing the encoder. I tried to work around it with no success.
In my investigations I found this useful function FUN_0007f9fc(), which returns the current system time (since boot) in microseconds. I was using this time various hacks, like the encoder take 22-24ms per frame, useless it crashes.
In hardware hacks, I've add a 3D printed insert, to reduce the light spill, to improve the contrast.
I was hoping to get 80Mb/s stable, but this hardware encoder is only rated at Level 4.2, which is 50Mb/s. While the encoder is running at a low input frame rate, setting a Qp for a larger amount data would occasionally result in:
ERR: H264 ENC Interrupt error! HwInt = 0x10, BSLen = 0x1fa02
crashing the encoder. I tried to work around it with no success.
In my investigations I found this useful function FUN_0007f9fc(), which returns the current system time (since boot) in microseconds. I was using this time various hacks, like the encoder take 22-24ms per frame, useless it crashes.
In hardware hacks, I've add a 3D printed insert, to reduce the light spill, to improve the contrast.
Thanks i’ll take a look into it. I’m a complete novice with this so it’s a bit slow trying to reflash the chip with each change. My main concern is that the compressed rom is actually around 1-2MB/s smaller than the original, so something seems very wrong! Not just the 2k bytes.
I finally got my new lens and spacer. It does take a bit of work to make them fit, but a little Dremeling goes along way.
The original screws are 0-80 x 0.2". I don't have a 3D printer, so to get the 7mm spacer I got 0-80 x 0.5" screws to extend the base. I figured this would work well for leveling, aiming, and fine focus.
However, in the process I broke the clip for the sensor ribbon cable. I guess you can never be too careful. :-( Now the unit doesn't seem to initialize. Still working on the that part, but I am excited to try it out. Once I get it operational with the original FW, I will start figuring out how to update @0dan0 's latest to the my B type.
I have a projection color meter at work. I want to measure the base light source. That may give us a better idea for a fixed white balance.
Thanks for all the amazing work, this is a great resource!
The original screws are 0-80 x 0.2". I don't have a 3D printer, so to get the 7mm spacer I got 0-80 x 0.5" screws to extend the base. I figured this would work well for leveling, aiming, and fine focus.
However, in the process I broke the clip for the sensor ribbon cable. I guess you can never be too careful. :-( Now the unit doesn't seem to initialize. Still working on the that part, but I am excited to try it out. Once I get it operational with the original FW, I will start figuring out how to update @0dan0 's latest to the my B type.
I have a projection color meter at work. I want to measure the base light source. That may give us a better idea for a fixed white balance.
Thanks for all the amazing work, this is a great resource!
This is a more robust design for alignment for sure. Sorry to here about the broken sensor clip. I'm surprised mine stills works after so many removals, and my thread on the original lens mount is toast.
I'm thinking I purchasing a second unit, but I would like to make show it is not type C. Some units like mine only have three posts to tension the film, some have four. Are the four-post versions, Type A or B, or it this unrelated? So far no one has been willing to share serial numbers on ebay.
I'm thinking I purchasing a second unit, but I would like to make show it is not type C. Some units like mine only have three posts to tension the film, some have four. Are the four-post versions, Type A or B, or it this unrelated? So far no one has been willing to share serial numbers on ebay.
No progress report. Does anyone know how to control the motors? I would like to have a control to disable them.
FUN_001069d8(0, 0x4000001, 1, 0); Seems to be a call to shutdown the unit, but when I use it it gets into a loop before the motors are switched off. I expect there is another call required, or I attempting this from the wrong thread.
Another approach might be to use the shell command, if I could fake a "dsc shutdown". Anyone discover the processing loop for the shell?
FUN_001069d8(0, 0x4000001, 1, 0); Seems to be a call to shutdown the unit, but when I use it it gets into a loop before the motors are switched off. I expect there is another call required, or I attempting this from the wrong thread.
Another approach might be to use the shell command, if I could fake a "dsc shutdown". Anyone discover the processing loop for the shell?
Hi @domb84
I think what you want can be achieved using the GUI. The following workflow seems to work:
1. Unpack the firmware partitions using Quick unpack (taking note of which file is Partition 0 and Partition 1)
2. Make your changes
3. Compress Partition 0 using full compression (mode c)
4. Compress Partition 1 using full compression (mode c)
5. Merge the compressed partitions (in the same position as they were extracted)
You can also try my suggestion of prepending the first 2296 bytes of the original firmware to the resulting binary. If you're using a Unix-like OS this can be done with dd and cat:
Bash:
dd if=CAM-M127-A1-V1.0-ROM.bin of=header.bin bs=1 count=2296
cat header.bin merged.bin > rebuilt.binEdit: You can also use this less intuitive one-liner:
Bash:
head -c 2296 CAM-M127-A1-V1.0-ROM.bin | cat - merged.bin > rebuilt.binHope this helps.
Best,
Joe
Last edited:
Version 5.4 attached. I was able to find a way to stop the motors in the event of encoder crash. While running at 50Mb/s has its risks, now at least you only have to wind back 5-6 frames, restart the unit, and continue. Some code has been moved to create more coding space, plus some work in progress that is not activate yet.
Changes at 0x1a9ff8 this used to do be a call to print the last error message on an encoder crash, now in calls my shutdown code at 0x1fc540. The shutdown code is super crude, sends 0xffs to 0xb0260000 - 0xb0267fff, this freaks the unit out enough to turn off the motors.
Changes at 0x1a9ff8 this used to do be a call to print the last error message on an encoder crash, now in calls my shutdown code at 0x1fc540. The shutdown code is super crude, sends 0xffs to 0xb0260000 - 0xb0267fff, this freaks the unit out enough to turn off the motors.
Last edited:
Firmware V5.5 attached
This new firmware includes a grey frame detector to stop the capture automatically when the file is run out at the end. While I haven't had it fail. I do have the sprocket hole visible, as the detector is using the luma minimum to maximum in the frame, a low difference is the sign of a grey frame.
Note on all the changes: https://docs.google.com/document/d/1AT6ePRO7csoXD_1yUocJsVlNRvMUsktMsBqlPPmCwbo/edit?usp=sharing
Future:
- At 50Mb/s recording a long reel hits the 4GB limit (~11m30), causing the capture to stop (the file is still good), however the motors still run and your lose you position. The original developers never encountered this situation as at 8Mb/s, that would be an 70minute reel.
- Still trying to find the exposure control (or the auto tonemapping), to at least damped it.
- manual white balance controls
- on-screen feedback would be deluxe
This new firmware includes a grey frame detector to stop the capture automatically when the file is run out at the end. While I haven't had it fail. I do have the sprocket hole visible, as the detector is using the luma minimum to maximum in the frame, a low difference is the sign of a grey frame.
Note on all the changes: https://docs.google.com/document/d/1AT6ePRO7csoXD_1yUocJsVlNRvMUsktMsBqlPPmCwbo/edit?usp=sharing
Future:
- At 50Mb/s recording a long reel hits the 4GB limit (~11m30), causing the capture to stop (the file is still good), however the motors still run and your lose you position. The original developers never encountered this situation as at 8Mb/s, that would be an 70minute reel.
- Still trying to find the exposure control (or the auto tonemapping), to at least damped it.
- manual white balance controls
- on-screen feedback would be deluxe
Last edited:
Feedback needed.
I have found how to set the exposure to full manual, and you only need a working serial port. From the command prompt
> ae set <ISO> <exposure time in µs> 0
e.g.
> ae set 50 8191 0
ISO (in hex) is 32 to 640 (50 to 1600) - the auto exposure does increase ISO
Exposure (in hex) is e5 to 7fff (0.229ms to 32.767ms)
The ISO is written to address 0x80e556b4 (writing the ISO value forces manual also)
Exposure is written to address 0x80e556b8
> mem w 80e556b4 32
> mem w 80e556b8 1fff
These are the same as "ae set 50 8191 0", although I've found using the mem w command more reliable.
So I can programming set a hard coded exposure, or maybe hijack the exposure bias. However the autoexposure does have it benefits for handle underexposed scenes.
I experimenting with this settings:
> mem w 80e556b4 32
> mem w 80e556b8 3fff
ISO 50 with 16ms exposure. This is good so far for under exposed scene, leaving them darker. However it can now overexpose on bright scenes.
I expect I need to find auto exposure and limit it so it doesn't gain up the underexposed scenes. Still to be found.
I'm now experimenting with ISO 50 Shutter 0xf00 (3840µs)
I have found how to set the exposure to full manual, and you only need a working serial port. From the command prompt
> ae set <ISO> <exposure time in µs> 0
e.g.
> ae set 50 8191 0
ISO (in hex) is 32 to 640 (50 to 1600) - the auto exposure does increase ISO
Exposure (in hex) is e5 to 7fff (0.229ms to 32.767ms)
The ISO is written to address 0x80e556b4 (writing the ISO value forces manual also)
Exposure is written to address 0x80e556b8
> mem w 80e556b4 32
> mem w 80e556b8 1fff
These are the same as "ae set 50 8191 0", although I've found using the mem w command more reliable.
So I can programming set a hard coded exposure, or maybe hijack the exposure bias. However the autoexposure does have it benefits for handle underexposed scenes.
I experimenting with this settings:
> mem w 80e556b4 32
> mem w 80e556b8 3fff
ISO 50 with 16ms exposure. This is good so far for under exposed scene, leaving them darker. However it can now overexpose on bright scenes.
I expect I need to find auto exposure and limit it so it doesn't gain up the underexposed scenes. Still to be found.
I'm now experimenting with ISO 50 Shutter 0xf00 (3840µs)
Last edited:
A benefit of running a manual exposure, there is now lower noise. My bit-rate control is going to highest Qp limit (19), and staying there, as the images are cleaner.
Last edited: