As stated elsewhere, V1.4 will be the stable version: apart from bugfixes and perhaps some more machines, I don't want to change the feature-set of that release. V1.5 will be where the new features get implemented. At this page, I want to collect some requests for the new firmware and bring up ideas about how to implement them.
Claiming new memory
One of the problems we will run into, is that in some devices the room for hacks in segment 0 is extremely small. We need to develop code to be able to put the hacks elsewhere.
- In free space in segment 1-3: For most devices, this will work. For a.o. the TomTec, it won't because these segments can't be flashed due to a bug.
- => maybe install a loader in segment 0 to write in segment 1-3 ??
- In the picture space: We run the risk that the code gets overwritten by a picture. Any way to prevent this? Perhaps there's some free space somewhere we can use?
Feedback from the device
A few implementation requests deal with getting feedback from the device, e.g. button-presses. This would mean hacking the USB reception code.
Hello, I have tested the hack with a sangha picframe, and it works fine. However later I have bricked my device when trying to upload picture datas. I have found the error later, it was because my device have only 1mb of flash, and the code use 2mb by default, and overwrite the firmware in this case.
- this got me too, in my case with a Praktica View Pix 96x64 keyring. Will take it into my lab at work and see if I can restore the firmware with an in-circuit programmer.. Phil.
I plan to build a flash programmer to reprogram the flash and to try new firmware without risk. So I think the function to upload pictures should be removed because dangerous and not very usefull.
I have bought another DF of another mark, but the firmware is now located at address 0x00033290 (page 6 & 7), and the display message command do not work, I'm trying to hack it.
I have a third display frame with a 320*240 TFT display that seem to be hacked. I have found all things to patch except for the display controller. This DF works too with photo viewer. May be later it could be interresting because display quality is very good.
About an OS, it could be good for now to create a command to read and write a byte remotly (in ram), and jump to custom address ?. bye
One of the ways to solve this, would be to create a mini-OS of our own, which e.g. gets started as soon as the device is reset with the USB-cable plugged in. This way, we can put the LCD in the most convenient mode (12-bit), create our own protocol (no more wrapping commands into mass storage requests), use all of the 2K of RAM that's available to us, etc. This, however, is a shitload of work, which I won't be doing on my own. Anyone want to join me if that project actually started?