On Sun, Mar 10, 2013 at 2:19 AM, Kevin O'Connor kevin@koconnor.net wrote:
It is printing the same sequence of bytes over and over again:
0002d160 30 30 33 0d 0a ff 55 aa 48 e9 ed 4e 93 55 aa 48 |003...U.H..N.U.H| 0002d170 ec ed 4e 93 55 aa 48 e9 ed 4e 93 55 aa 48 e9 ed |..N.U.H..N.U.H..| 0002d180 4e 93 55 aa 48 e9 ed 4e 93 55 aa 48 e9 ed 4e 93 |N.U.H..N.U.H..N.| 0002d190 55 aa 48 e9 ed 4e 93 55 aa 48 e9 ed 4e 93 55 aa |U.H..N.U.H..N.U.| 0002d1a0 48 e9 ed 4e 93 55 aa 48 e9 ed 4e 93 55 aa 48 e9 |H..N.U.H..N.U.H.|
I'm not seeing this right now, but I think I have seen it in previous tests. I think subtle changes in the binary layout may make this junk come out/not come out.
It is obvious that what we see is the beginning of the ROM at offset 0, it even stops at the first '\0' it encounters. Which seem to indicate that the print function is doing the right thing. Except the address of the string is not right.
My suspicion would be that the address of the string on the stack is getting corrupted between calls, or like in the Windows bug, we're dereferencing arguments on the stack using a register which is not meant to. Also, another possibility is that we're using segment registers that the emulator doesn't like us to use.
Thanks again for looking at this.
Pleasure :) Tell me if you find anything.