Quote
ce the great - 2008-09-15 2:13 PM
If someone could find the files or a backup image, you CAN temporarily replace the system files
(until the next cold reboot
).
After that, you can use a backup utility to store them on a compact flash and that should be it.
All you have to do now is find an english 360lx and copy the system files
(\windows
) from it - and share them with us
well, i have english 360lx, and always wondered how the hell usedhandhelds got hold of those portuguese units. they've had them sitting there for years now.
as for copying the rom files. C:Amie already answered.
now for the 360lx specific details on this, I wrote a rom dumper for MIPS/SH3 CE 2.11 before
(nobody before really bothered for some reason
), but I'm using VirtualCopy API to do it, and MSDN says only CE 2.10 and later have that.
this does not mean you can't dump the rom of course, just need to target virtual addresses instead of physical
(or maybe check how drivers on CE2.0 could access physical addresses, there must have been a way
). I'm pretty sure 2.0 doesn't need SetKMode for accessing any virtual address, but must test this. worst case, there is probably another hack to allow CE2.0 threads run in kernel mode
(that jlime loader also uses on CE2.0, but never looked at it
).
I'll try to dig out my 360lx or other CE 2.0/1.0 machine - but if you are willing to run tests that would be good.
after the rom is successfully dumped, the problem is still twofold.
1. extracting the files, well, I'm sure we can do that, the rom structure is simple enough, but must change compression method
(if CE2.0 uses any at all, CE2.11 does and the problem below is the same for 2.11
), CE before CE3.0 uses different compression, and I only have the decompression libraries for the CE3.0 and later ones. for overcoming this, my only idea coming to mind is call the decompression functions inside the CE2 kernel, but that's of course not exposed, so that would be more extra fun to find them
(calling is not a problem though
). luckily the kernel itself is never compressed
of course if they're stored uncompressed that's a nice waste of rom space but easier for us
2. putting the files on the device. you will have to restore the missing
(intentionally stripped
) relocations for many DLL's, and I have no idea how easy that is for SH3 processor. this part seems the biggest trouble of all. but of course entirely possible, however if we cannot develop good heuristics for the SH3 processor
(I could for ARM cpu
), this boring task will take an awful lot of time
(could be a full hour for bigger dll's, and even if not, there's quite a few dll's altogether
).
finally, any resources in coredll.dll, will remain portuguese even after all this effort, because coredll can only be replaced by reflashing the ROM with new coredll
(same for filesys.exe but that doesn't really have string resources *iirc*
).
the rest of the OS is ok, and you don't have to copy all the OS, just some exe's and dll's and stuff so I don't see the RAM consumption as a real problem. at least it is a smaller problem than the above listed ones.
final note: wish CE 1.0/2.0/2.11 supported MUI's, then you could make it english relatively easily.
also, almost forgot to say. a few files can be copied off the device using totalcommander CE, but that's nowhere near enough, still, it might be a bit helpful for you, and I can check which files can be copied.
(the background behind this is that there's two ways of storing a file in the ROM, one allows you to simply copy the file, the other does not. both ways are used in every ROM
)
PS: why don't you register on the forum?
Edited by cmonex 2008-12-28 12:00 PM
)