How did you do that exactly? And does it work stable?BennVenn wrote:Success! A big thanks to skaman!!
(must write 0x77 twice)
I am assuming that "write 0x77" does mean a AA-55-77 sequence like this:
Code: Select all
mov a,0aah // mov [far 0c0aaaah],a ;\
mov a,055h // mov [far 0c05554h],a ; causes ALL bytes = C8h (sometimes FFh, or CAh)
mov a,077h // mov [far 0c0aaaah],a ;/
Whenever executing the above sequence (once, or twice, or several times), and then reading from [C0FFxxh], I am just receiving C8h bytes from the chip (occassionally with a few CAh or FFh bytes inserted on some reads).When reading from [C000xxh], I am getting C0h instead C8h. Anyways, that are just garbage or status values, not the hidden data.
Another odd thing is that, after sending the above sequence, the chip stops responding to any normal commands (eg. command AA-55-F0 doesn't return to normal FLASH data read mode anymore).
However, if I remove the whole write AA-55-77 stuff, and re-upload my test program to the SNES, then it does sometimes pop up with the hidden data - although I haven't issued the AA-55-77 stuff (nor the 38h,D0h stuff) in that situations at all.
So, it does look as if the 77h is starting to enter the hidden data mode on SNES, but it does still require whatever random bus traffic before completely reaching the hidden data read state.
I've tried to insert extra reads & writes & delays here and there, but haven't been able to reproduce that effect yet.
EDIT: Thinking about it. When I re-upload (and reboot) my test program, then MX15001 chip might automatically issue the 38h,D0h stuff (if it's doing so when receiving a /RESET from SNES side). So that might also explain where the hidden data is coming from even when NOT requesting it (ie. on the SNES, the AA-55-77 might be just causing the FLASH chip to fail to return to normal data mode after having received the 38h,D0h stuff from the MX15001).