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

  • It's #MARCHintosh 2025! Join in on the fun and post your project or play with some new stuff in our #MARCHintosh 2025 thread.

Mac84

Administrator
Staff member
Founder
Sep 4, 2021
237
286
63
New Jersey, USA
www.mac84.net
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.
 

Attachments

  • IMG_4597.jpeg
    IMG_4597.jpeg
    1.7 MB · Views: 47
  • IMG_8909.jpeg
    IMG_8909.jpeg
    1.3 MB · Views: 46
  • IMG_8894.jpeg
    IMG_8894.jpeg
    1.4 MB · Views: 42
  • IMG_8899.jpeg
    IMG_8899.jpeg
    1.2 MB · Views: 41

0dan0

Tinkerer
Jan 13, 2025
77
102
33
Thank you @Mac84 and @wnt2fly. I going to proceed assuming the memory integrated and only 128MB. Crazy how there are no leaked datasheets for this obsolete part.
 

Hawke

New Tinkerer
Dec 30, 2024
18
7
3
what happened?
I wanted to look at the display, or the exact type, to see the differences between the A, B and C models. I dropped the display, I tried to catch it and I brushed against a glass bottle which then fell directly onto the display. Now it is broken, you can only see very faintly that the backlight is still working. Well, the device still works, but it's difficult to use when flying blind :-(
 

Hawke

New Tinkerer
Dec 30, 2024
18
7
3
Thank you @Mac84 and @wnt2fly. I going to proceed assuming the memory integrated and only 128MB. Crazy how there are no leaked datasheets for this obsolete part.


1739210771908.png

Oh, that would be very little RAM. One approach could be to set the GOP to a smaller value, I think a sequence of I- and P-frames is always written directly to the SD card. This could possibly reduce the RAM load.
Unfortunately, I haven't gone any further because of the setback with the display, that was already a stupid event.
 
Last edited:

larryc39

New Tinkerer
Jan 2, 2025
4
3
3
This is probably old news, but here's the datasheet for the Novatek chipset: https://dashcamtalk.com/cams/Novatek NT96655 Data Sheet.pdf

And there's some dashcam guys that worked with similar chipsets a decade ago. Maybe some of what they found would work with our machines?

 
  • Like
Reactions: Mac84

0dan0

Tinkerer
Jan 13, 2025
77
102
33
I also found the NT96655, I hoped to find what the differences are to the 96658, as the 55 doesn't have integrated RAM. I think I'm over my confusion able the tiny RAM size. There seem to be plenty of unused memory.

Here is an crudely annotated memory dump during 1920x1440 capture (1920x1440 sensor data, processing and encoding):

More resolution raw data:
 
  • Like
Reactions: Mac84

0dan0

Tinkerer
Jan 13, 2025
77
102
33
Something doesn't quite add up, which where the video corruption could be coming from.
MemoryAnim.00.jpeg


Here we see Luma data straddling 0x06000000. Yet on the console there is this info:
H264EncInit: buf addr=0xA60A55C0, size=0x410A60, GopNum=15

H264 is initializing something at 0x060A55C0, which in the middle not the top a the frame buffer. This address doesn't move for other resolutions.

Note: 0xA60A55C0 and 0x060A55C0/0x860A55C0, are all the same address. The 0xA address is likely a non-cache version of the address.

When I capture and process at 848x636 and encode at 1920x1440. The top of the video buffer lines up with 0xA60A55C0, and the resulting images are good (just lower stock resolution.)

Clearly a new memory map supporting the large images needs to be fixed. Any ideas for next steps?


--

UPDATE: I the position of the text for 0x06000000 is wrong in the video. The top of the luma frame is at 0x060A55C0. So this initialization of the encoder is correct., something else is still wrong.
 
Last edited:
  • Like
Reactions: fishgee

fishgee

New Tinkerer
Jan 6, 2025
10
4
3
I found some info on the NT96658 on a Chinese site. To get the entire doc would entail setting up an account and a credit card. It being China, I was reluctant to go that far. But I was able to screen shot the first spec pages that may or may not help you guys. See attached DOCX file. It does have 1GB of ram.
 

Attachments

  • NT 96658.docx
    1.6 MB · Views: 30
  • Like
Reactions: 0dan0

0dan0

Tinkerer
Jan 13, 2025
77
102
33
Thank you. "Built-in 1Gb DDR3 SDRAM" , now triply confirmed. This feature sheet is good to see.
 

larryc39

New Tinkerer
Jan 2, 2025
4
3
3
So I did a couple runs on my two units to see the various C version firmwares. The 0dan0 C firmware definitely has better clarity than the Mac84 version. For both cases I tried the full zoom out/left, Exposure -0.5, Sharpness -1.5, and Tint 0. My 0dan0 unit I had "adjusted" the focus of the camera, although in the end it was exactly in the factory spot when I was done. I didn't adjust the camera on my Mac84 unit.

1739237382207.png


1739237401161.png


The one thing I didn't like is going that far negative in sharpness is it left the image very smooth yet blurry feeling. I reran a 0dan0 scan with +0.5 sharpness, and though I got more noise I felt like I also got a little more detail, I.E. a little more texture to the grass, the grey pants had obvious wrinkles, etc.

1739237526964.png
 
  • Like
Reactions: Mac84

Hawke

New Tinkerer
Dec 30, 2024
18
7
3
I found some info on the NT96658 on a Chinese site. To get the entire doc would entail setting up an account and a credit card. It being China, I was reluctant to go that far. But I was able to screen shot the first spec pages that may or may not help you guys. See attached DOCX file. It does have 1GB of ram.
I think it's not 1GB , above in this document there is 16KB data cache (upper case B) , almost used for bytes, below at built-in memory they used 1Gb (lower case b) almost used for bit. :-(
 
  • Wow
Reactions: fishgee

0dan0

Tinkerer
Jan 13, 2025
77
102
33
Today's progress. I did a series of captures, erasing the memory between captures so I could more easily see how the memory was being used (from the shell: mem fill 82000000 04000000 ff). Each capture use a different source resolution, all encoding to 1920x1440. The encoding resolution is not the problem, but the source resolution has a fixed buffer size. The incoming source 4:2:0 data is stored in two buffers, likely a double buffer, one for even frames, the other for odd numbered frames. The first frame is always at 0x250A3F0 and the second at 0x25E4BB0. As the input resolution increases (when you zoom out), more of the buffer is used. The gap between the buffers is only 894912 bytes. This sets the maximum source resolution at ~892x668, way short of the 1920x1440 we want. When source resolution is above the gap size, the buffers collide (areas in red), explaining the glitching seen. Also the second frame buffer bleeds into something potential used for compressed data (the non-YUV data glitches.)

1739298733193.png


This is the new target, increase the size of these two frame buffers. All help welcome as I don't know my next step.
 
Last edited:
  • Like
Reactions: fishgee

fishgee

New Tinkerer
Jan 6, 2025
10
4
3
"I think it's not 1GB , above in this document there is 16KB data cache (upper case B) , almost used for bytes, below at built-in memory they used 1Gb (lower case b) almost used for bit. :-("

Wow. Good catch Hawke (eye). So we have a gray area in our knowledge again? Is it possible for one of you coders to write/compare data to memory past the 1Gb boundary and see if it errors out then?
 

0dan0

Tinkerer
Jan 13, 2025
77
102
33
128MB has been confirmed, as the memory repeats at the 128MB boundaries. 1Gb = 128MB
 
Last edited:
  • Like
Reactions: Mac84

0dan0

Tinkerer
Jan 13, 2025
77
102
33
Slow slow progress. I believe the function FUN_002f5094() set up the addresses for the two capture buffers, as it has these telling error logs:

ERR:%s() Input buffer0 Y channel address - 0x%08x
ERR:%s() Input buffer1 Y channel address - 0x%08x

This function is called at the video frame rate, which is 25fps on Reels. So this function needs to remain running, and can't be gutted like auto white balance.
 
  • Like
Reactions: fishgee

Andreas

New Tinkerer
Oct 15, 2024
8
5
3
I'm looking, so far in vain, where you can turn off the automatic exposure. Has anyone made any progress here? I'm using ghidra...
 

0dan0

Tinkerer
Jan 13, 2025
77
102
33
Looking for the AE is hard, and there doesn't seem to be any active error messages in that code. It might be near AWB, but I haven't looked hard for it yet.
 

domb84

New Tinkerer
Jan 27, 2025
11
3
3
So, I dismantled the M127 machine and found it has an MX25L3206E ROM chip. I've connected up a CH341a chip programmer with an 8 pin chip clip. When I attempt to dump the ROM from it though it's never detected. I powered the machine back up and it seems to still function so it doesn't appear that I've damaged it in the process. Has anyone attempted to dump the ROM from a MX25L3206E using a CH341a before? Any tips?
 

wnt2fly

New Tinkerer
Dec 23, 2024
12
6
3
So, I dismantled the M127 machine and found it has an MX25L3206E ROM chip. I've connected up a CH341a chip programmer with an 8 pin chip clip. When I attempt to dump the ROM from it though it's never detected. I powered the machine back up and it seems to still function so it doesn't appear that I've damaged it in the process. Has anyone attempted to dump the ROM from a MX25L3206E using a CH341a before? Any tips?
I did it about a month or so ago to a wolverine pro and the kodak C unit. I found that the CH341a reader I got I had to have the wires backwards. i had the same issue, flipped things around a few times until it was detected in the software. IIRC the red strip didn't align w/the dot on the chip
 
  • Like
Reactions: Mac84