Thanks to sagarvaze for unraveling the way of the
OS-update-installers.
The OS update application self-extracts some files to directory %TMP%\{<some
CLSID>} in case of the updaters 1.05, 1.11 and 1.05.1000 (FX9860 AU). The 1.03
updater extracts the neccessary files to "C:\programs\C ASIO\fx-9860 OS
Update". The subdirectories "{<some CLSID>}" and "fx-9860 OS Update" resp. are
temporary and automatically deleted after completition of the update by the
installer.
Possibly the directory-names are different on different systems. Searching the
system volume (f. i. C:\) for "UpdateCode.bin" should be successful, if the
directory shouldn't be locatable easily.
When the update process is waiting for the calculator to be connected, these
directories contain
if OS 1.05, 1.05.1000, 1.11, 2.00:
CESG502.IN_, CESG502.sys, EnumDev.dll, OSupdateDLL.dll, UpdateCode.bin,
UpdateExe.bin
another parallel directory %TMP%\{<some other CLSID>} contains:
0x0407.ini, 0x0409.ini, 0x040a.ini (OS 2.00 only), 0x040c.ini, 0x0411.ini,
1031.MST, "fx-9860 OS Update.msi", Setup.INI, _ISMSIDEL.INI.
if OS 1.03:
EnumDev.dll, OSupdate.exe, UpdateCode.bin,
UpdateExe.bin
UpdateExe.bin is the mini-OS, which is
loaded into the calculators RAM starting at 0x88030000 and takes over control
while the flash is unavailable. It is identical for 1.03, 1.05 and 1.11.
UpdateCode.bin is the flash-image which will be transferred to the calc.
The first 64k of the flash seem to be untouched by the OS update. So, the
calculator's hardware information is retained.
The following procedure has been tested for the 1.03 updater OSupdate.exe:
Change to "C:\Programme\C ASIO\fx-9860 OS Update".
Start OSupdate.exe.
Follow the instructions.
Everthing is like a normal update (except the installers redundant show). If
triggered by the OS update application, the update is refused, when not
upgrading. If triggered by the OS update contact closure or syscall 0x159, the
updater does not heed for the version. The hole to access the OS update
contacts of the fx-9860G slim is hidden by a piece of adhesive tape (10mm
N;7mm W of the P-button). The GII has no OS update contact reachable from
outside. Its cover has to be removed (search for P104). OSupdate.exe does not
delete directory "fx-9860 OS Update", nor any file inside. The 1.03 updater
installs 1.05, 1.10(see below) and 1.11 images without any problems, too. When
modifying UpdateCode.bin, the int checksum at offset 0x0026FFF8 has to be
adjusted. It is the byte-sum of the ranges 0x00010000..0x0022FFFF and
0x00260000..0x0026FFF7 (0x00010000..0x0026FFF7 with OS 1.02). If the checksum
is not correct, the mini-OS overwrites the first four bytes at 0x00010000.
When the calc restarts, this location is checked for the string "C ASIOWIN".
If this does not match, the calc enters a kind of emergency OS update. Hint:
the messages displayed during emergency OS
update are bitmaps.
There doesn't exist an official 1.10 update-image. The test mentioned above
has been performed with an image drawn from a slim.
The 1.03-updater does not work with the OS 2.00 UpdateCode.bin or the OS 2.00
UpdateExe.bin..
There are two independent emergency OS updates. The
primary emergency OS update is located inside the first 64k of the
flash-memory. This area is not changed by an OS update! The primary emergency
OS update will be invoked, when the string at 0x80010000 is not equal to "C
ASIOWIN" or when the OS update contact is shorted during boot. This is very
important, when modding the OS. If the OS is corrupt and cannot invoke the
secondary emergency OS update any more, the calc would be unusable, if there
wouldn't be the primary emergency OS update. The primary emergency OS update
can be recognized by a frame of asterisks (*), when it's waiting. The
secondary emergency OS update is located inside the OS, which begins at
0x80010000. It is invoked by syscall 0x159, by OS update
contact closure while GetKey() is waiting, by an OS/hardware mismatch on
startup or by a checksum mismatch on startup.
On the GII-types (9860 as well as 9750) the primary emergency OS update can be
triggered by simultaneously holding down F2, 4 and Ac/ON while pressing the
RESTART-button. Then the calc should show a blank display. Finally press 9 and
x consecutively.
OS 2.00 uses the range 0x00010000..0x0024FFF7 to
calculate the checksum. It is stored at 0x0024FFF8.
OS 2.00 tests the checksum after every calculator reset and enters the
emergency OS update, if the test fails. This behaviour is most annoying while
testing flash writing routines. Hence it had to be patched away immediatly (overwrite
opcode at 8003A41C/800489E4(slim) with a nop).
It is a bit inconvenient, to use the complete
installation process, when testing a self-written
UpdateExe.bin. Instead, the inner
OSupdaters OSupdate.exe (OS1.03) or OSupdateDLL.dll (OS1.05+) can be used.
OSupdate.exe can be started from any directory. The directory
has to contain UpdateExe.bin,
UpdateCode.bin and EnumDev.dll.
OSupdate.exe works without any arguments.
OSupdateDLL.dll can be started from any directory, too. The
directory has to contain UpdateExe.bin,
UpdateCode.bin and EnumDev.dll.
The path to the directory mentioned above has to be explicitly passed in
8.3-notation.
F. i.:
RunDLL32 OSUpdateDLL.dll,OSUpdate
C:\XYZUVW~1\casio\UpdateExeTest
(29.05.2012 10:25:33)