What? The CE only has RAM addresses up to D657FF. Everything else is pretty much unmapped or just mmio, and probably shouldn't be touched. Here's some code that executes double buffering; you basically just call it multiple times and it handles everything for you: (Note that you have to set currentDrawingBuffer to $D40000) first, before you try anything


Code:

I just was hoping to find usable , fastest access (read/write) areas

Yes , that's weird : concerning the area between $e4000 and $efffff or between $ff0000 and $ffffff, for any value I write there I always read value 0 in return. But when I choose an address from there as lcdbuffer, on screen I can see 0... and other values !

Those are memory-mapped port areas, a la the memory map on WikiTI (and elsewhere):
http://wikiti.brandonw.net/index.php?title=84PCE:Wait_States
If you're not careful, you could end up changing ports that you don't mean to.

Yes, I was careful : I did not make attempts in memory-mapped port areas, only the "Unmapped port range" from $e4000 to $efffff and from $ff0000 to $ffffff

I was documenting a few system calls today, and I came across a rather neat one that has no real value. (Well, maybe). Anyways, it appears that the OS has a way to save the entire ram state into flash, and then restore it on a call to _BootOS. This means, as one notable CVSoft puts it, "all of ram is saferam". Using a system call at 0002E0 (Haven't come up with a name for it), allows you to copy ram into the temp buffer. It is also extremly useful if you want to copy something to flash, such as a hook. Anyways, this allows us to write pretty much anything, as now we can use all of ram and easily restore it. However, the OS uses RAM too, so this pretty much means you can't use OS calls. Anywho, here's some example code that saves and restores ram: (Which allows for about 415744 bytes of whatever you want to do).


Code:

Does that Kerm and co. will have a safe reliable way to do hooks now? I remember him talking about how his current implementation wasn't very safe.

Of course it is safe. Just as long as a garbage collect doesn't happen to make the hook address start with 0x83, but there is a higher probability of the earth falling out of orbit than that happening. I mean, TI technically has the same bug when executing non existent assembly programs, but you don't see them worrying about it Also, no, this call erases entire sectors, so it is really only useful for safely saving things temporarily, such as a hook for testing.

Hold on... are you saying you can set the LCD to read from nonexistent memory, and then you have ALL of vBuf1/2 to play with and use as normal memory? This sounds extremely intriguing...

I believe this is exactly the case that grosged is making In addition, you can use ram saving to pretty much have all of ram + all of vram to do whatever you want with

That sounds like deep sleep mode; I think BrandonW described it as being exactly that. I think part of the power savings from deep sleep mode is turning off RAM.

Also, if you want ALL of RAM + VRAM, why bother pointing the LCD to garbage addresses? Why not just show garbage on the screen? Or why not just turn the LCD (or at least the backlight) off? Also, you can set 1 bpp mode. Then you can at least show a 9600-byte message that describes what you're doing.

A little bit ago I was sniffing through the hardware ports on the TI84+CE, and discovered a simple unlocking sequence used probably by developers for TI. Ports 0x38-0x40 control the mapping of RAM memory, while ports 0x41-0x43 control the "dev" mode. It appears that TI actually installed a 1MB ram chip, yet only decided to map 256KB of that for whatever reason. There may be more information available in this mode; but as of right now I am still exploring. The program below basically maps the externally available RAM in order to increase the storage amount. Adriweb was kind enough to test on the TI83PCE as well, and it is confirmed to work:

Download: Dev Mode

[Also added this support to CEmu]:

Haha, nice work. I'm glad we have a magical extra 768KB of RAM to work with on the TI-84 Plus CE calculators.

haha!
More seriously, I ventured into the $e00000 memory area (wait-states R/W = 1/1), and I finally found a few places where It is actually possible to write :

$e0xx08 : value=0 ! DANGEROUS, AVOID value=1 ! (or it'll get your TI soooo sloooow) (Thx, Epharius;) )

$e0xx09 : we can put here an 8bit value
$e0xx0a : value from 0 to 15 (half-byte)
$e0xx0b to $e0xx0f : 5 bytes we can modify

$e0xx10 : value=0 ! AVOID value=1 (for security) !

$e0xx11 : also here an 8bit
$e0xx12 : again a half-byte
$e0xx13 to $e0xx17 : 5 bytes we can modify

Interesting, isn't it ?

I updated ti84pce.inc with a bunch of things. Enjoy There's a whole lot more on the way too.

Yay, I've figured out a new call
It is located at 021910h and I would call it like this:
_InsertBCBytesAfterCursor
Hehe, it first shifts editTail BC bytes to left, and then copy BC bytes from the input HL to the new location of (editTail).

Inputs:
- BC = amount of bytes to insert
- HL points to data to insert

Outputs:
- Added BC bytes after the cursor in the editor
- The data pointed by HL to HL+BC is filled with 1's

Destroyed:
- HL=HL+BC
- BC=0
- DE=(editTail)



And a new more useful call located at 0218D4h:

Code:
That's all.
I would call it _Load70InA

Great work PT_! Those are some nice finds, especially that second one :p Keep up the great work!

Also, there's actually a range of ports that cause a crash when you write to that location in memory. It could be very useful as a hardware breakpoint in z80 mode, if you are so inclined. The doc is over on Wikiti in the ports section

Does this mean we can have something akin to a hibernation function on the CE? As you said "and then restore it on a call to _BootOS", and i presume _BootOS is called on boot

Yes! Actually, it's one of the calculator's touted features from TI themselves: they promoted the fact that it puts itself into a "deep sleep" mode if not turned on for a week or so, useful for students' calculators that go unused (say) all summer. This way, they'll still have battery power to be used after the summer, if students forget to charge them before the first day of school.

Thats cool! Is this copy of the whole RAM deleted when bootOS is called? Is there some flag to tell the OS weather to restore from the RAM save? I see some awesome potential if something akin to zStart's run on ram clears feature can be implemented without modifying the OS (?)

So while I was trying to understand a part of the OS, it seems to work with the (menuCurrent) values. When I went to the ti84pce.inc, I can't find the one I needed, so I started to check all these values. It seems that someone (@Mateo? ) was either drunk or copied it from the 83plus.inc, but all these values above 0Bh or so, are wrong. Here are the current, right values, almost complete:

Code: