Hmm the home screen seems like home screen games won't be as compatible, after all >.< (it's more than 16x8). Illusiat might be fine, but NPC text might look funny.

As for the RAM I am not surprised, but I hope images will remain in archive like the PRIZM. I would hate if one single pic took the entire RAM. I'm sure the RAM chip is much larger, though, due to graph buffers. That extra RAM might be interesting for ASM/Axe coders

As for the fonts, I think they tried to keep it as close as possible to the old models. I don't like them much, but I like them much more than the PRIZM fonts.

Could an admin or staff include in the news also that TI-BASIC seemed to run at around 1.5x slower than the 84+ speed, according to Vijfhoek? (at least for graph commands) That isn't uber great news, but I was glad that it ran faster than the regular 83+.

EDIT: Something I am kinda worried about: Kerm mentions something about a charging port in one of the pics. That scares me. What if TI decided to remove USB charging and go the Apple way of forcing customers to buy their proprietary cable that doesn't fit anywhere else than the device if you lose your cable? I hope not, but sometimes we never know...

If the 40350 test passes, you can use this to dump ROM pages:
prgmPAGEDUMP 114 bytes of codeAsmPrgm
EFD74AEF2842
2005210000
180E21FF00
EF464B5D54B7
21FF00ED527DF5
21049ECDE49D
21FF9DE7EFF142
3803EFC64F
21FF9DE7210040
E5EF6A4EE17D12
137C12134D44
F1EF175021FF9D
E7EFD84FC9

F5CB3FCB3FCB3F
CB3FCDF39DF1
E60F0630FE0A
38020637807723
C9

1550414745
000000Use it like this:
0:Asm(prgmPAGEDUMP)
This will create an appvar named PAGE00 and automatically archive it. Similarly, you can do 1:Asm(prgmPAGEDUMP) and get PAGE01 and 255:Asm(prgmPAGEDUMP) to get PAGEFF, because $FF = 255. Then, just send them to another calculator and post them online for analysis. Definitely get pages 0-7, and send those to another calc just in case dumping additional pages segfaults or something. (Who knows, maybe TI made it so that even reading from the certificate causes a reset.) Those pages should at least point us in the right direction. Pages 240-255 (especially 254 and 255) might also be good.

This will throw ERR:INVALID DIM if Ans is not a number, not an integer, or not in the range 0-255. This will throw ERR:MEMORY if there is not at least 16400 bytes of free RAM.

For automation, {0, 1, 2, 3, ...}:Asm(prgmPAGEDUMP) will fail. But For(A, 0, 7):A:Asm(prgmPAGEDUMP):End will dump the first seven pages for you.

I wonder how long will an OS take to install on that thing (and what RSA key size will it use)...

Could you rehost the images at img.removedfromgame.org? imgur is blocked here at school.

It could also mean programs aren't run from $9D95 and the labels aren't being treated correctly, in particular the call(s) and the AppVar name. Or that the BCALL table has changed.

I want That screen is great and that much Archive? YES

No, what happens is that code is copied to 8000h, then it is called. When you use "call", the the program counter is pushed to the stack. The code that got copied to 8000h is:

Code: [Select]

pop hl
push hl
ret
(which, as discussed elsewhere can be optimised )
Basically, HL now has the address that the original routine called it from. Then, we use bcall(_DispHL). If that bcall() has been changed or destroyed in some way, then there will be issues.

EDIT: The purpose of the code is to figure out where programs are run from. Once we know that, we can figure out how broken compatibility will be and start fixing our programs now, before the release.

Err... i think we're talking about different programs. I was looking at "prgmPAGEDUMP", oops

Quote from: aeTIos on November 14, 2012, 01:00:13 pm

The speed is said to be bad.

Was it tested again today? Yesterday there were reports about a 1.5x drop in speed, but then other reports about the speed being on par with the 84+.

Well that's what I call "bad". I mean, come on, we've got a 320x240 screen, then I expect at least a bit of a speed gain too.