Then for IDA's loading address that is again 0x80000000. Furthermore I'm creating a RAM section at 0x8C000000 ( from this forum post) with a size of 0x10000 (64kb after referencing the datasheet of the CG-50's M12L64164A) and creating the ROM section at what you said 0x80000000, with the size being just the size of the file I'm loading (0xB60000 in this case). Yup it's decompressed (I can tell as there are CASIOABS strings and other OS related strings, and it sucessfully decompressed).Ĭurrently I'm using IDA's "Renesas SH-4 (big endian) " (since I assumed it was big endian, using the little endian version has no change). Make sure you have fixed and decompressed the OS image obviously. Architecture is SH4AL-DSP but SH-4A might be good too, or even SH-3 is a sane default. For it to work you need to load the flat binary at 0x80000000 and preferably also at 0xa0000000 if possible. You're welcome! I don't use IDA so I can't guide you directly a screenshot of your problem might help.
#Bible black 2 cg update
Really insightful, thanks for responding! I have extracted the firmware from the OS Update tool but currently having issues loading it into IDA. However, working with functions well hidden inside the OS can be horrendous GetKey() for instance is a practical nightmare IMO.
#Bible black 2 cg drivers
Device drivers are not very difficult to work with all things considered, because they only go a few function calls deep before touching hardware registers, which exposes the role of the routines. If there's one thing that never changes, it's the syscall tables on the black-and-white models they date back about 15 years with no major change.ĭisassembling is pretty easy, unwinding the technical stack is probably more challenging. When I tried to make a collection of all hardware-related resources I ended up only finding a couple of pages that I believe are not up-to-date, and none of them are about syscalls.Įverything that you can find documented as far back as 2011 you can pretty safely trust still works. WikiPrizm is fairly up-to-date, not because it's very active but rather because the OS almost never changes. Syscall table address (0x8002007c) : 0x80673c90Įntries that point to valid memory : 0x1f68įirst seemingly invalid entry : 0x01010000
0 kommentar(er)
