2 replies to this topic

[Andreas B]

I was toying with my gcc-compiled apps (not required for this), exploring the memory around the vram.
Note that PutLCD is the same function revfx uses to write a buffer to the LCD controller, just another name.

int main() {
	char *vram = (unsigned char*)0x8800498D;
	char *dptr = vram;  /* this pointer changes to explore the memory */
	int bytesperskip = 512; /* use a base 2 number like this for best results. Change the source to be able to edit this in-app too */
	unsigned int key;

	while (1) {
		memcpy(vram, dptr, 1024);
		PutLCD(vram);
		GetKey(&key);
		switch (key) {
			case KEY_CTRL_DOWN:	dptr+=bytesperskip; break;
			case KEY_CTRL_UP:	dptr-=bytesperskip; break;
			case KEY_CTRL_AC:	dptr=vram; break; /* back to start */
		}
	}
	return 0;
}

This can be found a few kb before the vram (upwards):

Forward you can find ram used for the main menu etc. Some of this might be possibly to exploit for applications

[kucalc]

Lol, that's strange. Don't know why they would place a no sign somewhere in memory.

Some of this might be possibly to exploit for applications

I noticed a while ago that accessing past 1KB from the VRAM didn't crash the calculator. I was thinking that maybe perhaps we could reallocate the addresses of the data sections and place them after the VRAM.

[Andreas B]

After poking around a bit;
VRAM:0x8800498D -> 0x88004D8D

Unknown1: 0x88004D8D -> 0x8800518C
Unknown2: 0x8800518D -> 0x8800558C

SaveDisp(3): 0x8800558D -> 0x8800598C
SaveDisp(2): 0x8800598D -> 0x88005D8C
SaveDisp(1): 0x88005D8D -> 0x8800618C

Each of these blocks are 1k in size, i have not noted any side effects of writing to the area marked Unknown. Whenever I look at that memory, Unknown1 has a screen with the "Receiving... Press AC to abort" or similar text, from when you transfer files, Unknown 2 is blank.
Instead of using the dedicated SaveDisp, we know that at least 3k of RAM from 0x8800558D to 0x8800618C is free to use.