I told you, that
It is the negative of sum of all bytes in segment 8 and 0xFFFC first bytes of segment 1 mod 0x10000.
A segment consists of 0x10000 bytes. I have not tried, but according to that, if you increase one in one byte in segment 1 or 8, then the checksum is decreased by one.
I suggest reading other people's posts carefully and not quote too much, only necessary parts,
(Although I say that, I once ask again about the memory of the fx-es no-plus series, which one of you already said) because my post is (I think) very long, and can be updated regularly.
------------------------------------
We only have ROM of other calculators (those in fx-es plus emulator ver 3.0 ones and fx-570vn plus), not fx-991es plus or fx-83gt plus.
However if you can find checksum procedure in your calculator (according to barcode spelling page in tieba baidu, byte #53 and #54 (when I use #, I means effective character) control PC, and #55 control CSR), it would be possible to read its memory.
Unfortunately, the ROM of fx-570vn plus is not entirely correct. (However it is still usable) For example, when you use hack [{12}^25 {kW->hp Sigma( 1 . }^7 {12}^12], the checksum procedure show three times, which, after some more experiments, prove that address 01:69F4 pop 8 bytes. Which is inconsistent with real calculator. However if you substitute Pa->mmHg to kW->hp it behave correctly. We can assume the emulator uses the same (C, I think because the U8 dev kit contains a ccu8 program) source code as the real calculator, but compile differently, and with some modification to not turn off, etc.
Explanation: 01:69F4 is the start address for checksum diagnostic screen in emulated calculator, does not take any bytes in stack. In emulated calculator set stack to contains [01:69F6 01:69F6 01:69F6 #####....] (##### is anything that make calculator hang) and then execute "POP PC" the checksum will show three times and then freeze. (We need to jump to 69F6 not 69F4 to avoid "PUSH LR", so when the calculator execute corresponding "POP PC" it will pop our value of PC in stack. Address 01:69F6 of emulated calculator corresponds to address 01:69F2 of real calculator. Not too much, but segment 0 is (I think) shifted severely.
Explanation on value of stack: 01:69F4 corresponds to four bytes (F4 69 x1 xx) (x can be anything), and the particular case (F4 69 31 2E) translate to ( kW->hp Sigma( 1 . ).
So, if you want to find checksum procedure you have to try many overflow hack, with different byte #53 and #54. You don't need to test every cases, and if you can find any that potentially related to the checksum procedure, post it here.
In case you do not understand what I am saying, reply but not quote. (after read carefully my previous posts)
---------------------------------------------------
n-th chaotic point mode on emulated calculatorDoes not behave identically to the real calculator, but similar.
As someone in
fx-es(ms) group said, the n-th chaotic point mode is caused by the stack being shifted by 68 bytes each time we press "=". So you have to change the value of SP.
The best way to do this is change value of (word) 00:0000.
Normally on 570vn+, it is "8DEA" (little endian), so to access 16th chaotic point mode, we have to change it into 8DEA - 16d * 68d = 89AA.
And then press ON. The value at 00:0000 is default value of SP in vector table.
The chaotic points are quite different too, but, at least we understand why it happens and partially reproduce it on emulated calculator.
I will find ways to access that on 570VN+ calculator.
---------------------------------------------------
@kasio, if you delete all your posts because you find "basic overflow" unrelated to your calculator, I think get to "basic overflow" is possible (press ON while Reset all), assume fx-83GT PLUS is similar to fx-82ES PLUS. As
fx-es(ms) group said, it is very hard to get to that mode, but I think it is not impossible.
---------------------------------------------------
About the character
r In fx-570vn+, the position that handle different cases of character r is at 01:2D46 (BL ER12). It may be different in real calculator. It is known that r can directly control mode, and I successfully get to the "68 mode" by enter
1111
1 ------ M+
___
v r
(mixed fraction (1 + (1111) / ( square root ( r ) )) M+)
in real calculator after a lot of tries. If you (
kasio) try more, you might find out how to access "68 mode" and from that, you can access basic overflow.
--------------------------------
EDITIn emulated calculator, the character
r call function with address [2C46h + ([80FAh] - 2) << 1], which translate to
table_2C46[sub_mode - 2] // (1)
where, sub_mode = (byte)[80FAh], equal to 2 --> 8 in non-hack case, and table_2C46 is ptr[ 7 ], with content
{0x1E02, 0x1E02, 0x1DFA, 0x1DF2, 0x1DEA, 0x1DE2, 0x1DDA}
Note that, in (1), the table is of basic type 2-bytes that I call "ptr", thus don't need the "<<1".
When sub_mode == 0, it evaluates to
[2C46h + (0 - 2) << 1]
= [2C46h + 11111110b << 1]
= [2C46h + 11111100b]
= [2C46h + FCh]
= table_2C46[126]
a
(not table_2C46[254] as I expected), equal to 0033h on the emulator (I think it is different on real calculator).
-------------------------------------------------------------------------------
EDIT(from this site)
mariohackandglitch was able to chabge a mode/SUM value on the diagnostics test (firmware screen)
It is possible to change, either segment 1 or segment 8, so execute arbitrary code is possible. But, it is also quite dangerous, because you can corrupt the content of the memory, thus make the calculator unusable. I think he means to get a different value when enter it the correct way (shift + 7 + ON), not to find a way for it to show different checksum just that time, and then next time it return to normal checksum. (The checksum procedure does not change the checksum)
Edited by user202729, 06 January 2017 - 10:04 AM.