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

 

[Cogniclaw]

Hello! I've used the Mac84 firmware on other machines, just got another used machine on Ebay, "B" type (D2825148BK00561 serial)
Anyhow, the latest 0Dan0 firmware 7.7.0 (B) flashed flawlessly & is working great- I've noticed something however & wanted to ask if this is normal for anyone else- as I'd sold the prior Reelz i had & as such only have the one on hand.... I'm getting a ton of noise in light areas & practically ZERO noise in the dark regions of the image ( keeping ISO at 100 EV between 0 & 2) - Is this something you've encountered? Is it normal? Something that settings could fix?

THANK YOU FOR YOUR TIME & DEDICATION!!!

@0dan0

 

[0dan0]

Hello! I've used the Mac84 firmware on other machines, just got another used machine on Ebay, "B" type (D2825148BK00561 serial)
Anyhow, the latest 0Dan0 firmware 7.7.0 (B) flashed flawlessly & is working great- I've noticed something however & wanted to ask if this is normal for anyone else- as I'd sold the prior Reelz i had & as such only have the one on hand.... I'm getting a ton of noise in light areas & practically ZERO noise in the dark regions of the image ( keeping ISO at 100 EV between 0 & 2) - Is this something you've encountered? Is it normal? Something that settings could fix?

THANK YOU FOR YOUR TIME & DEDICATION!!!
View attachment 26329View attachment 26330
@0dan0

This is the "denoising" that is eating all the grain in the shadows. I've turned some of it off, the frame to frame denoising, but not the spatial denoise. The alternative lens helps a big, but here is not control for this.

 

[larryc39]

I can't keep up with you guys. I started to mod my machine tonight, if I understand the photos I've seen before, for the spacer item,

The piece with the four holes and socket receptacles mounts on the bottom, where the PCB was, with the bar part at the back facing the unit. The back holes are used to align with the pins on the existing PCB mount area and only two screws of the original six are used to secure it. The other four screws are used to mount the camera PCB assembly to the bracket with the two diamond "pins" and then this is slid into the larger, lower part until things are lined up.

I would suggest removing the undercut from the larger piece as it just makes it harder to print andor uses up supports that are hard to remove on a small area.

 

[videodoctor]

Thanks for your patience with me, @0dan0 ! I've attached the compressed D.BIN file that I grabbed from my D unit. I used your "freed up space" version of the D RBN (shows "Type D - WIP" on boot screen).

As far as I can tell, the LCD address is still the same. When I ran the mem commands you provided, I got both the blank/black overlay as well as the yellow color. A button press restored the screen. I'll update my version to use the same custom code region as you indicated. Thank you again!

 

[0dan0]

I can't keep up with you guys. I started to mod my machine tonight, if I understand the photos I've seen before, for the spacer item,
View attachment 26334

The piece with the four holes and socket receptacles mounts on the bottom, where the PCB was, with the bar part at the back facing the unit. The back holes are used to align with the pins on the existing PCB mount area and only two screws of the original six are used to secure it. The other four screws are used to mount the camera PCB assembly to the bracket with the two diamond "pins" and then this is slid into the larger, lower part until things are lined up.

I would suggest removing the undercut from the larger piece as it just makes it harder to print andor uses up supports that are hard to remove on a small area.

The undercut is to clear the surface mount components on the other side of the sensorboard. Yes it's a tad harder to print because of this, but not sure what the alternative would be.

 

[larryc39]

Wait, so then you're saying the piece with the grooves in it, the larger non-size-adjustable piece goes on top and the smaller one of three choices piece goes on the bottom?

 

[sheider]

Wait, so then you're saying the piece with the grooves in it, the larger non-size-adjustable piece goes on top and the smaller one of three choices piece goes on the bottom?

Yes, notice the "T" and "B" lettering that @0dan0 helpfully included in his design.
Also, if you have trouble focusing with the bottom piece height that you depicted, then try 1 of the other 2 heights that he helpfully shared here.
Or if you prefer a single-piece design, you could try the one that @Deano shared in his very helpful writeup.

 

[videodoctor]

@0dan0 , were you able to see the reelType value in the D.BIN dump I provided? I've finally got a hook calling into your hist.c code, but I'm getting a crash in the unit. I probably don't have the frame number pointer correct, or it's not finding reelType where it thinks it should be.

 

[larryc39]

Yes, notice the "T" and "B" lettering that @0dan0 helpfully included in his design.
Also, if you have trouble focusing with the bottom piece height that you depicted, then try 1 of the other 2 heights that he helpfully shared here.
Or if you prefer a single-piece design, you could try the one that @Deano shared in his very helpful writeup.

Yeah those letters didn't really catch my eye in the model and were obscured in my print. I was aware of the three heights tho.

 

[0dan0]

@0dan0 , were you able to see the reelType value in the D.BIN dump I provided? I've finally got a hook calling into your hist.c code, but I'm getting a crash in the unit. I probably don't have the frame number pointer correct, or it's not finding reelType where it thinks it should be.

Reel type must be at 0x80340000

Looking at D.BIN (very helpful) the Type D NVM is at 0x80E0ADA4, not what you had suggested. This is matches the data I expected to find for brightness, sharpness and tint, all set to defaults at zero. In memory look for 04 00 00 00 04 00 00 00 04 00 00 00 (04 is the set zero, values at from 00 to 08, for -2.0 to 2.0)

We need to find where the ISO is stored, and the button presses.
Button presses should be between 0x80E80000 and 0x80E9000

So do a
mem dump 80E80000 10000 ButOff.bin

Then with the up arrow pressed
mem dump 80E80000 10000 ButOn.bin

Search for 00 00 00 01 00 00 00 01 In the second file.

It should be 0s in the first. You will have then found the button address offset.

FIRST:
My guess will be 80E8b7d0
So you can test with :
mem r 80E8b7d0 (while playing with the buttons.)


For ISO my guess is 0x80e5590c

try:
mem w 80e5590c 320
mem w 80e55910 640

then:
mem w 80e5590c 64
mem w 80e55910 64

See if the exposure is affected (when an image is on the display.)

Attached is a memory dump from Type C 7.7.1. This will help we look for things to compare.

If my guesses are correct, hist.c will need these lines of code added:

if(*reelType == 4)
{
expo_iso = (int *)0x80e5590c; //sensor ISO
nvm_base = (int *)0x80E0ADA4; //exposure, sharpness, tint
button = (uint32_t *)0xA0E8b7d0;
}

and manwb.c will need:

if(*reelType == 4)
{
nvm_base = (int *)0x80E0ADA4; //exposure, sharpness, tint
active_settings = (uint32_t *)0x80DDC660;
button = (uint32_t *)0xA0E8b7d0;
}

 

[0dan0]

Reel type must be at 0x80340000

Looking at D.BIN (very helpful) the Type D NVM is at 0x80E0ADA4, not what you had suggested. This is matches the data I expected to find for brightness, sharpness and tint, all set to defaults at zero. In memory look for 04 00 00 00 04 00 00 00 04 00 00 00 (04 is the set zero, values at from 00 to 08, for -2.0 to 2.0)

We need to find where the ISO is stored, and the button presses.
Button presses should be between 0x80E80000 and 0x80E9000

So do a
mem dump 80E80000 10000 ButOff.bin

Then with the up arrow pressed
mem dump 80E80000 10000 ButOn.bin

Search for 00 00 00 01 00 00 00 01 In the second file.

It should be 0s in the first. You will have then found the button address offset.

FIRST:
My guess will be 80E8b7d0
So you can test with :
mem r 80E8b7d0 (while playing with the buttons.)


For ISO my guess is 0x80e5590c

try:
mem w 80e5590c 320
mem w 80e55910 640

then:
mem w 80e5590c 64
mem w 80e55910 64

See if the exposure is affected (when an image is on the display.)

Attached is a memory dump from Type C 7.7.1. This will help we look for things to compare.

If my guesses are correct, hist.c will need these lines of code added:

if(*reelType == 4)
{
expo_iso = (int *)0x80e5590c; //sensor ISO
nvm_base = (int *)0x80E0ADA4; //exposure, sharpness, tint
button = (uint32_t *)0xA0E8b7d0;
}

and manwb.c will need:

if(*reelType == 4)
{
nvm_base = (int *)0x80E0ADA4; //exposure, sharpness, tint
active_settings = (uint32_t *)0x80DDC660;
button = (uint32_t *)0xA0E8b7d0;
}

I updated my type-D firmware with the above code changes. This has not merge in your other patches. So you should just grab bytes from 338f28 - 340008. Repo is up to date. Note: the code from 338f28 - 33b200 still will need some Type D support.

Like this motor shutdown code:

If has branches for A thru C, not D yet.

I will have some more time this weekend.

P.S. Attached is the WIP for motor shutdown fix.

I guessing the motor shutdown is at 80ddb670

You can confirm by starting a capture, then:
mem w 80ddb670 30

The motor should immediately stop.

 

[videodoctor]

Reel type must be at 0x80340000

Looking at D.BIN (very helpful) the Type D NVM is at 0x80E0ADA4, not what you had suggested. This is matches the data I expected to find for brightness, sharpness and tint, all set to defaults at zero. In memory look for 04 00 00 00 04 00 00 00 04 00 00 00 (04 is the set zero, values at from 00 to 08, for -2.0 to 2.0)

We need to find where the ISO is stored, and the button presses.
Button presses should be between 0x80E80000 and 0x80E9000

So do a
mem dump 80E80000 10000 ButOff.bin

Then with the up arrow pressed
mem dump 80E80000 10000 ButOn.bin

Search for 00 00 00 01 00 00 00 01 In the second file.

It should be 0s in the first. You will have then found the button address offset.

FIRST:
My guess will be 80E8b7d0
So you can test with :
mem r 80E8b7d0 (while playing with the buttons.)


For ISO my guess is 0x80e5590c

try:
mem w 80e5590c 320
mem w 80e55910 640

then:
mem w 80e5590c 64
mem w 80e55910 64

See if the exposure is affected (when an image is on the display.)

Attached is a memory dump from Type C 7.7.1. This will help we look for things to compare.

If my guesses are correct, hist.c will need these lines of code added:

if(*reelType == 4)
{
expo_iso = (int *)0x80e5590c; //sensor ISO
nvm_base = (int *)0x80E0ADA4; //exposure, sharpness, tint
button = (uint32_t *)0xA0E8b7d0;
}

and manwb.c will need:

if(*reelType == 4)
{
nvm_base = (int *)0x80E0ADA4; //exposure, sharpness, tint
active_settings = (uint32_t *)0x80DDC660;
button = (uint32_t *)0xA0E8b7d0;
}

Thanks, @0dan0! I confirmed that the button address is correct at 0xA0E8b7d0 by seeing 01 for up arrow and 02 for down arrow.

The ISO address doesn't seem to be correct, but I'll keep looking around that range.

I haven't been able to successfully tie into an auto exposure hook yet---I found another hook during preview creation and drew a green rectangle on the LCD, but it only appeared for a few frames and then disappeared. I think the handler I tied into is only called a few times unlike the AE hook you've used in the past. While capturing, I've noticed a "UIFlowWndMovie_OnTimer()" in the serial output, but I wasn't able to successfully tie into that.

I've only been compiling hist.c and injecting at the start address you provided. Should I be compiling manwb.c too and inserting directly after that mod? I noticed the "--- CUT HERE ---" marker in the hist.bin and I've been cutting there to get the ELF header info out of the compiled BIN.

Thanks again! It's been fun and painful to go back and forth with code edits and firmware boots, but that's the nature of the game.

 

[Federico]

Hi guys, I have some newbie questions about post-scanning enhancement of the footage.
I'm using (using is an overstatement) DaVinci but I am no expert at all.
I can do editing and basic enhancement (removing dust, scratches, etc.) but I have no method nor experience, so each project is different.
I know that this is a bit off topic, but probably, given the output of the Kodak, there may be some settings/procedures that work better with this kind of footage.

• I'd like to know what FPS you use to capture, and why. Do you maintain it throughout the whole editing process? What is the final FPS for your 8mm and super 8mm footage? Do you render at 16 (or 18) and keep it at 16 (or 18) all the way through?
• what filters/corrections do you apply?
• what is the final format/settings you use for the rendered version: are you aiming to reduce the compression completely - I think that given the quality of the original footage there is a point where very low compression is irrelevant if not worsening the output - or what do you use to judge the output compression? About this point I believe that most of us want to preserve the best quality of the footage but keep it somehow sharable: having 1Gb/minute seems too much to me: what's your POV?
• Is there any way to avoid compression while rendering: I mean if I feed a 1Gb footage, what settings/format should I use to obtain a similar size output without pushing high compression? It seems that the original compression/quality cannot be maintained without using a 'low-quality' setting: every medium-high quality setting do increase the rendered file size.

Sorry for the super trivial questions, but I imagine (and hope ) they may be the elephant in the room for some other reader here, not just me.
Thank you!

 

[0dan0]

Thanks, @0dan0! I confirmed that the button address is correct at 0xA0E8b7d0 by seeing 01 for up arrow and 02 for down arrow.

The ISO address doesn't seem to be correct, but I'll keep looking around that range.

I haven't been able to successfully tie into an auto exposure hook yet---I found another hook during preview creation and drew a green rectangle on the LCD, but it only appeared for a few frames and then disappeared. I think the handler I tied into is only called a few times unlike the AE hook you've used in the past. While capturing, I've noticed a "UIFlowWndMovie_OnTimer()" in the serial output, but I wasn't able to successfully tie into that.

I've only been compiling hist.c and injecting at the start address you provided. Should I be compiling manwb.c too and inserting directly after that mod? I noticed the "--- CUT HERE ---" marker in the hist.bin and I've been cutting there to get the ELF header info out of the compiled BIN.

Thanks again! It's been fun and painful to go back and forth with code edits and firmware boots, but that's the nature of the game.

You will need both hist.c and manwb.c built. But I expect there are a lot other things to fix first. You should be using all the same hooks as the earlier models, otherwise it will be more difficult to maintain. Use the differences before C original and C now, and make the needed changes to D. I think you done some of that.