Hacking the Kodak Reels 8mm Film Digitizer (New Thread)
- Thread starter Mac84
- Start date
To add to the tabulated serial numbers, my European/UK (RODREELSEU) unit, delivered in September after a 2 month shipping delay has S/N C1725148BK002**, very close to that quoted by MHreels (#107). Until I've completed a first pass on my collected 8mm family films I'm reluctant to risk experimenting with firmware updates, but would be happy to try the enhancements if I was confident of being able to revert the system to the factory-installed firmware. Have any other users confirmed the compatibility of the H2324148BK Series Kodak firmware that MHreels attached?
I also have a European model and the number is exactly the same as yours. My number is just longer, it has a 37 added at the end. I have tried all the firmware version C that are out there and they all work for me.
New here, so hello to everyone. Just got my Reels... had a Sniper DV8 about 18 years ago, so I am back at it. Newby question: can anyone here sell a hacked/upgraded chip/board with the upgrade successfully installed already? If not, what is the easiest upgrade I can do that doesn't require code/wiring, etc knowledge? TIA
Upgrading the firmware only requires an SD card. However, new "2025" serial numbered units may not be compatible. Can you share the serial number of your unit? Via the sticker located at the bottom of the model, that'll help ensure compatibility and reduce the risk of updating incompatible firmware.
Heya, been lurking this thread for a while. I have what may be a "D" unit with original firmware. I do have some basic soldering ability. If the steps for dumping aren't too crazy I coud give it a shot. Also happy to mail it off to someone with more experience and time than myself. Let me know how I can help.
Attachments
Excellent!
I recently did a live stream (start at the 22 minute mark in this video) where I took apart the device and soldered on three small cables to communicate with it via a UART serial adapter (I'm using an Arduino nano as one) to dump the firmware. Take a look and see if that's something you are comfortable with.
The wires are thin, but if you are experienced it shouldn't be too bad. If you have any questions let me know!
Here are also written instructions for opening the device and so on:
https://docs.google.com/document/d/1htmhRHyY_kEjoiTgSInV0PeXvzyXTMaXDYJ_3Ai4A4A/edit?usp=sharing
Also, depending on your location, I'd be happy to have it shipped here to modify for you.
While we are waiting for an original image for the new type D unit, progress continues. Currently all my text and histogram rendering using the preview video buffers, the YUV data that contains the lower resolution of the film-scan for display. This is a very useful buffer as I used it for my exposure control, and computing the histogram, but for displaying settings, this is wrong place. I've since found the LCD's display overlay bitmap. It had alluded me, as it was not in a format I would have expected, like RGB 24bit or RGBA 32bit. The JPEG images in the firmware are 864x480, but there is no 864x480 surface anywhere in the memory, but it did find a 480x864 (first pixel is the top right corner) that is 8-bit palette mapped (a throwback from 20+ years ago.)
This is the palette (colors 0 to 255 , 0 is transparent to the video layer below)
For all unit types, the overlay bitmap is at 0x81821180
If you have a serial port to have play with it.
> mem fill 81821180 65400 0
Makes the screen completely transparent
> mem fill 81821180 65400 ff
fills it with white
Once I have the font engine working on the overlay buffer, I will move the exposure stats and data to the right edge (off the film scan area.) I will leave the histogram as is, as that needs the full color of YUV.
This is the palette (colors 0 to 255 , 0 is transparent to the video layer below)
For all unit types, the overlay bitmap is at 0x81821180
If you have a serial port to have play with it.
> mem fill 81821180 65400 0
Makes the screen completely transparent
> mem fill 81821180 65400 ff
fills it with white
Once I have the font engine working on the overlay buffer, I will move the exposure stats and data to the right edge (off the film scan area.) I will leave the histogram as is, as that needs the full color of YUV.
Last edited:
Thanks to the advice here. I got my replacement unit and have no skipping issues anymore.
It is also a D variant. I took a stab a disassembling the unit tonight. I’ll do the soldering and dumping later this week.
I followed Mac84’s stream to see what the process entails. I found it quicker to take the LCD and then straight remove the board.
For now, here are some pics of the D variant board, in case that’s interesting to anyone. But it looks like the same board as the other variants to me.
It is also a D variant. I took a stab a disassembling the unit tonight. I’ll do the soldering and dumping later this week.
I followed Mac84’s stream to see what the process entails. I found it quicker to take the LCD and then straight remove the board.
For now, here are some pics of the D variant board, in case that’s interesting to anyone. But it looks like the same board as the other variants to me.
Attachments
Last edited:
@Mac84 I am interested in shipping my Reels unit to you.Excellent!
I recently did a live stream (start at the 22 minute mark in this video) where I took apart the device and soldered on three small cables to communicate with it via a UART serial adapter (I'm using an Arduino nano as one) to dump the firmware. Take a look and see if that's something you are comfortable with.
The wires are thin, but if you are experienced it shouldn't be too bad. If you have any questions let me know!
Here are also written instructions for opening the device and so on:
https://docs.google.com/document/d/1htmhRHyY_kEjoiTgSInV0PeXvzyXTMaXDYJ_3Ai4A4A/edit?usp=sharing
Also, depending on your location, I'd be happy to have it shipped here to modify for you.
Good news! @0dan0 @Mac84 I have dumped the variant D firmware. My S/N is H2825148BK02147.
One important question: I dumped everything twice and got different md5 hashes for the DUMPCODE.BIN, but not for UITRON.BIN. Is that to be expected? They're in the a and b folders, respectively. I trust "b" more.
drive.google.com
Thanks Steve for the good guides on dumping, this made it very easy for me. I did some thing my way, which might help others.
1. For disassembly you don't need to take out the metal assembly, instead you can get at it by removing the LCD w/ bezel.
2. Standard ribbon cable has the perfect pitch for soldering to the GND, RX, TX, (3V3) pads.
3. I used a simple USB2TTL adapter (CH340, which can do 3V3 and 5V logic) and Putty to talk to the Kodak over serial.
(not the neatest job)
Can't wait to try out the firmware ;-).
Cheers!
One important question: I dumped everything twice and got different md5 hashes for the DUMPCODE.BIN, but not for UITRON.BIN. Is that to be expected? They're in the a and b folders, respectively. I trust "b" more.
VAR4.zip
drive.google.com
Thanks Steve for the good guides on dumping, this made it very easy for me. I did some thing my way, which might help others.
1. For disassembly you don't need to take out the metal assembly, instead you can get at it by removing the LCD w/ bezel.
2. Standard ribbon cable has the perfect pitch for soldering to the GND, RX, TX, (3V3) pads.
3. I used a simple USB2TTL adapter (CH340, which can do 3V3 and 5V logic) and Putty to talk to the Kodak over serial.
(not the neatest job)
Can't wait to try out the firmware ;-).
Cheers!
Excellent! Thank you so much for your efforts, this is wonderful!
That's good to know about the LCD way in, my LCD didn't want to be removed properly, so I assumed other units were just as picky. I've never had to solder the v3.3 pin, but I guess if your adapter supports it, it won't cause you any trouble.
I think the "DUMPCODE.BIN" also dumps any temporary data (settings, etc) stored in the memory chip. So it could be possible that it does differ. Although usually that data is in another partition and can be removed using the unpack/repack firmware tools.
Here's a comparison between C and D, lots of code changes!
Let's see if the above solves the issue for @JKCalhoun
...
Last edited:
PerfectExcellent! Thank you so much for your efforts, this is wonderful!
That's good to know about the LCD way in, my LCD didn't want to be removed properly, so I assumed other units were just as picky. I've never had to solder the v3.3 pin, but I guess if your adapter supports it, it won't cause you any trouble.
I think the "DUMPCODE.BIN" also dumps any temporary data (settings, etc) stored in the memory chip. So it could be possible that it does differ. Although usually that data is in another partition and can be removed using the unpack/repack firmware tools.
Here's a comparison between C and D, lots of code changes!
View attachment 25626
Let's see if the above solves the issue for @JKCalhoun
Thanks, Steve!
Out of curiosity I'm wondering if there is a smarter "code differ" since I can see the same sequence of bytes shown as different—they instead seem to be out of phase instead. (I'll look around to see if I can find one.)
EDIT: HexFiend (on MacOS) seems to be a little less naive when it diffs.
Attachments
Last edited:
It would be nice to have the option to manually set the maximum ISO. With the QP at its lowest setting, dark scenes at a high ISO (400) create too many visual artifacts, causing the recording to stop because the codec can’t handle the combination of high grain and high ISO. I can’t capture a reel at the highest quality since it always stops at the same scene with ISO 400. Dark scenes don’t need brightening—it’s film. @0dan0, you were right to doubt whether that was a good thing.
Last edited:
At least now Type D users can now be unbricked.
The changes in the new firmware are more extensive that any other model. Function addresses have moved, so this might take a while.
The changes in the new firmware are more extensive that any other model. Function addresses have moved, so this might take a while.
Last edited: