Hacking the Kodak Reels 8mm Film Digitizer (New Thread)

[0dan0]

All my code changes additions are between 338f28 - 340008. However these are dozens of changes in the rest of the firmware to branch the old code to run the new additions. You will need to diff the stock type C with v7.7 Type C, to see all these changes and do the equivalent. But this will be hard for D units, as the changes in the base firmware are more extensive.

This is the first code change in Type C. The is a replace a jal (jump) call with a nop. In type A-C "5800020C" is jal 0x80160 (console print), yet in type D the console print is "1803020C" jal 0x80c60. This first change is at 0x1d430. So everything has moved around.

The next big issue, some of my code additions was written directly in MIPS assembly, not C code. These change assumed things like the console print was jal 0x80160. I don't know what other assumptions I've have made. Otherwise I've attempted to make the added code device type aware.

At offset 0x340000 is the device type C=3, D will be 4, followed by the address of the NVM (you will have to find that.)

My code uses these fields.

Also attached are my incomplete firmware change notes. These has the offset for changes for A/B/C, and reason for the change. There are some really tricky changes regarding the framebuffer offsets, to support the large frames, done so long ago, I hope Type D is similar.

Do a bit a time, so when it breaks. Ask questions as needed.

 

[videodoctor]

@0dan0 - Perfect timing! I've been working on D variant analysis.

What I have:

• Stock D firmware (H2825... serial)
• NVM base address: 0x80E0D600 (found via Ghidra analysis)
• Device type should be 4 (as you predicted)
• Successfully injected manual WB code already (device boots and captures, and white balance doesn't seem to shift)
• Full binary diff between stock C and your v7.7 C

Initial findings:

• Confirmed function addresses differ (as you noted with console print)
• Simple offset approach (+0x1164) won't work
• Ready to do "a bit at a time" as you suggested

I can work through your ReelsChangeNotes.txt and report findings.

Happy to test incrementally and report breakage points. Thank you again!

 

[videodoctor]

Device: Kodak Reels Type D (H-series, Serial: H2825148BK...)
Achievement: 1600x1200 output resolution working on D variant hardware!

Background​

The Type D variant has been unsupported by existing firmware mods due to significant differences from A/B/C variants. After extensive reverse engineering, I've successfully ported core functionality to D hardware.

What's Working​

1600x1200 output resolution (vs 1728x1296 stock) Device boots normally Menus fully functional
Stable recording Currently recording at 20fps (stock)

Technical Details​

Key Discovery: Type D firmware cannot use simple offset calculations from Type C. Each data location and function address must be individually mapped.


Process:

1. Identified device-specific addresses (NVM: 0x80E0D600)
2. Mapped 17 external function calls from Type C to Type D equivalents
3. Updated 0dan0's ~29KB custom code block with D-specific addresses
4. Inserted custom code at 0x0033a08c
5. Found resolution values via pattern matching (not offset calculation)

Confirmed Mappings (Type C → Type D):

• Console Print: 0x80080160 → 0x80080c60
• Resolution Width: 0x00ddb754 → 0x00ddc718
• Resolution Height: 0x00ddb758 → 0x00ddc71c
• Input buffer setup: 0x802ea95c → 0x800160a0
• Plus 13 other function mappings

Critical Finding: Offsets vary wildly across the firmware:

• Console print: +0xb00
• Resolution: +0xfc4
• Some functions: negative offsets!
• Conclusion: Each address must be found individually

Current Limitations​

Only basic resolution change implemented so far OSD, histogram, RGB controls not yet functional 18fps not yet working (requires additional mapping)

Next Steps​

Working on:

1. 18fps frame rate (finding correct location)
2. White balance controls
3. Hooking custom code for OSD/histogram features
4. Full feature parity with 0dan0's Type C firmware

For Other D Variant Owners​

DO NOT flash Type A/B/C firmware on D hardware - it will not work.


If you want to help test D variant firmware development or have a D variant device, please reply. The systematic porting approach I've developed can be applied to add more features incrementally.

Files​

Attaching:

• FWDV280.BIN - D variant firmware with 1600x1200 resolution
• Based on 0dan0's freed-space D base firmware
• Flash at your own risk (standard firmware update procedure)

To flash:

1. Copy FWDV280.BIN to root of FAT32 SD card
2. Create empty folder "NVTDELFW" on SD card
3. Power on device with SD card inserted
4. Wait ~30 seconds for flash to complete

Huge thanks to:

• @0dan0 for the original firmware work and ReelsChangeNotes.txt
• @Mac84 for the extensive documentation
• The TinkerDifferent community

This is just the beginning for D variant support. More features coming soon!

 

[Federico]

Hello everyone,

Just before the New Year, I received the components necessary for upgrading the lens on my Type C system. Since then, I've finished all of the physical upgrades, and thought everyone might find my process informative. My first approach was to utilize the part files 0dan0 had graciously provided, but as I progressed, I decided to design my own parts. I've got FDM and MSLA part printing capabilities at home, so iterating the designs was relatively simple and they did the job I needed.

At the end, I've put together a comparison image attempting to show the detail improvements I see with all of the physical upgrades. I hadn't seen this type of comparison before, and I found it helpful to qualify the investment I've put into this humble consumer scanner. I hope that it helps answer questions about whether or not upgrading the lens is worth it (I'm convinced!). Note however that I've only been using V6.6 firmware up to this point and that's reflected in the comparison image. I'm looking forward to trying the newest FW versions in the coming weeks!

Ohhh so beautiful!
I'll print your sensor cover and lens cap tomorrow: they are very elegant
Congrats for the presentation as well: I planned to do one but yours looks much better than my draft!
I'll check the new film mask that you planned to create: it seems interesting too.
Ciao, Federico

 

[videodoctor]

I've ported (what I believe are) the core improvements from 0dan0's Type C firmware to Type D hardware. The device now runs 1600x1200 @ 18fps with improved auto exposure, stable with no motor issues.

The following summary was created by Claude.ai with some notes of my own.

What's Working ​

• Resolution: 1600x1200 (changed from 640x480 upscaled to 1728x1296, better quality than stock)
• Frame Rate: 18fps
• Auto Exposure: Improved algorithm from custom code
• Stability: Completely stable, motor operates correctly
• All core quality improvements from 0dan0's mod

What's Not Working ​

• OSD Display: No on-screen histogram, frame counter, or exposure stats
• White balance GUI/control
• Frame rate GUI/control
• Likely due to Type D display hardware differences (frame buffer addresses)
• Custom code executes but output not visible

The Challenge​

Type D hardware proved to be significantly different from Type C:

1. Memory Layout: Custom code offset +0x1164 from Type C locations
2. Function Locations: Preview/capture functions at different addresses
3. Motor Timing Sensitivity: Function entry hooks break motor control completely
4. Display Hardware: Different frame buffer or overlay addresses

The Solution​

After two failed attempts that caused motor issues, I discovered 0dan0 hooks INSIDE functions, not at entry points:

Key Discovery​

Function Entry Hooks (Phase 8 v1 & v2):
- Replace stack setup instruction
- Break function flow
- Destroy motor timing

Internal Function Hooks (Phase 8 v3):
- Leave function entry intact
- Preserve motor timing
- Add hooks at safe points within functions

Applied Hooks​

Auto Exposure Hook (Type D: 0x2b688c)

• Calls custom auto exposure code
• Improves exposure algorithm
• Working perfectly

Preview Internal Hook (Type D: 0x2bfeb0)

• Inside preview function at offset +0x170
• Calls OSD drawing code (0x8033aec4)
• Executes successfully but OSD not visible

Technical Details​

Memory Offsets​

Custom Code Region:
Type C: 0x338f28 - 0x340008
Type D: 0x33a08c - 0x34116c
Offset: +0x1164

Resolution Values:
Type D Width: 0xddc718 (1728 → 1600)
Type D Height: 0xddc71c (1296 → 1200)

18fps Value:
Type D: 0x1f20c8 (60000 → 54000)

Methodology​

1. Pattern Matching: Found functions by searching for byte signatures
2. Custom Code Insertion: Ported 0dan0's custom code with updated addresses
3. Hook Analysis: Compared stock vs modded C byte-by-byte to find ALL hooks
4. Internal Hooking: Applied hooks inside functions, not at entry points
5. Incremental Testing: Phase 1-8, keeping backups at each stage

Results​

Video Quality:

• Significant improvement over stock Type D
• 1600x1200 resolution
• Proper 18fps speed
• Better exposure control

Stability:

• No crashes or hangs
• Motor operates correctly
• All menus responsive
• Recording/playback works, not extensively tested

Questions for the Community​

For 0dan0:​

1. Are there known display hardware differences between Type C and Type D? (Pretty sure this is a bona fide "YES!")
2. What are the frame buffer addresses you use for OSD drawing?
3. Any Type D-specific display register addresses?

For Type D Owners:​

Would anyone be interested in testing this firmware? I believe it's a solid improvement even without the OSD.

Files and Tools​

I can share:

• Modified firmware (Phase 8 v3)
• Python scripts for analysis and porting
• Documentation of the process
• Ghidra analysis notes

Acknowledgments​

Huge thanks to:

• 0dan0 for the original Type C firmware and detailed change notes
• The TinkerDifferent community for the knowledge base
• Everyone who documented the Reels hardware

Next Steps​

I'm happy with Phase 8 v3 as-is - the quality improvements are significant and it's completely stable. But if anyone has insights into Type D display hardware or wants to help investigate the OSD issue, I'd be interested in pursuing that.


For now, I'm just enjoying filming with better resolution and the correct frame rate!

---

Technical Appendix​

Hook Locations (Type D)​

Auto Exposure:

• Location: 0x2b688c
• Target: 0x8033b7f4 (custom auto exposure)
• Status: Working

Preview Internal Hook:

• Location: 0x2bfeb0 (inside preview function)
• Target: 0x8033aec4 (OSD drawing)
• Status: Executes, Not visible

Phase Progression​

• Phase 1-3: Device type changes and NVM address updates
• Phase 4: Custom code insertion (28KB)
• Phase 5: Resolution and 18fps changes
• Phase 6: White balance (skipped - not essential)
• Phase 7: Auto exposure hook (stable baseline)
• Phase 8 v1-v2: Failed - function entry hooks broke motor
• Phase 8 v3: Success - internal hooks preserve motor timing

 

[0dan0]

1. Are there known display hardware differences between Type C and Type D? (Pretty sure this is a bona fide "YES!")
2. What are the frame buffer addresses you use for OSD drawing?
3. Any Type D-specific display register addresses?

As I don't have a Type D, I don't know what they have changed. On all three previous models the LCD buffer was at 0x81821180. This is used in hist.c (in the repo.)
uint8_t *LCD = (uint8_t *)0x81821180; // All types

The size of the LCD buffer is 480x864 (vertical), and is 8-bit palette mapped.

This would help me, from the shell run this command:
mem dump 80000000 08000000 D.BIN

This will save the entire memory to a file D.BIN. Zip that up and share it. This will help me field a lot of things.
I use memory dumps like this (typically with a smaller window) when looking for things that change between dumps. It is how I found button addresses and NVM originally.

If the LCD buffer is at 0x81821180, you can test with
mem fill 81821180 65400 0
This will erase the UI, make the overlay transparent to the film video image.

mem fill 81821180 65400 1
This will make the screen yellow

A button press should re-render the overlay.

If you don't see the LCD change, we will need to find where the new address is.

the hist.c code, does require you configure the data at 0x340000, which you haven't done correctly yet. It will currently default to a Type A. see lines 412-428 in hist.c
volatile int* reelType = (int *)0x80340000;
volatile uint32_t* button = (uint32_t *)0xA0E8BFF8; // uncached
int32_t* nvm_base = (uint32_t *)0x80E0B78C; //Type A - exposure, sharpness, tint
int* expo_iso = (int *)0x80e56134; //Type A - sensor ISO

if(*reelType == 2)
{
expo_iso = (int *)0x80e56224; //sensor ISO
nvm_base = (int *)0x80E0B87C; //exposure, sharpness, tint
button = (uint32_t *)0xA0E8C0E8;
}
if(*reelType == 3)
{
expo_iso = (int *)0x80e556b4; //sensor ISO
nvm_base = (int *)0x80E0AD0C; //exposure, sharpness, tint
button = (uint32_t *)0xA0E8B578;
}

This is no *reelType == 4 code yet.

This is change is wrong:

Custom Code Region:
Type C: 0x338f28 - 0x340008
Type D: 0x33a08c - 0x34116c
Offset: +0x1164

All extra code should be a the same offset, this why I can update Type A,B and C so quickly. All code additions should be device independent.

Custom Code Region:
Type ABC & D: 0x338f28 - 0x340008