Quote from: willrandship on February 22, 2013, 12:09:31 am

Maybe they should have implemented a disp buffer, like Linux uses. It stores all the console output and displays it as fast as possible, but the program continues running, ignoring whether it has actually displayed.

Ah so that's what a buffer does.  I still can't believe that TI would reduce the speed but upgrade the screen.

This seems to be aimed at the new student that know nothing about calculators but want the one that looks the coolest/ prettiest.

_Nicco_, TI didn't exactly reduce the speed. They shipped it with the same processor and RAM as the G hardware 84SEs, but with a screen that takes ten times as long to update.

The new calc was definitively just to increase sales by attracting students and parents with the color gimmick. Granted, it's much easier to read such screen than the old one and you can now program in the dark (I don't recommend it, to avoid damaging your eyes, but in case power goes out or something it can be pretty handy).

They did not decide to slow it down with a slower processor, but rather didn't want to improve its hardware speed, so as a ticalc comment says, you get the same speed for computing, but the larger screen is a bottleneck.

Ooh, not that we could implement this or anything, but what if they just subdivided the screen into 16 chunks, 4800 bytes each, and allowed you to page each chunk of the screen individually? The screen hardware would continuously update from the buffers not currently paged, and you can write to them as fast as to any other RAM.

It might probably require heavy modifying of their OS, which I doubt they would want to do unless the calc received a lot of poor reviews and negative criticism due to its slow screen. Just the scrolling in the PRGM editor will be a nightmare if you Goto in a 15 KB large program. Using many sub-programs (or Doors CS 8 instant Goto feature) will be a must.

The thing is that according to stuff I have read, the speed actually impacts school-related calculator uses too:

1) When typing stuff on the home screen, it's apparently slightly sluggish, like on the PRIZM. While this isn't necessarily an issue, it can be a tad annoying for those who type fast when they type equations and stuff

2) Vertical scrolling is slow. Horizontal will be fine for games, but the problem is that when you enter calculations or navigate menus, Y= and PRGM, it scrolls at about 4-5 FPS. Imagine if someone decides to make a 1 KB large math program and he has to Goto the end of the code: It will scroll all the way through the code, 4-5 lines a second instead of about 20. Scrolling through menus, such as the CATALOG or the MATH ones will be a nightmare.

Basically, this might annoy students in class as well (which is why I hope that TI adress this at one point). Would there be a way for TI to add vertical z-addressing back without radical hardware changes? That would solve the problem.


EDIT: I found this pic in TI's PDF files:



So some color might be possible on the home screen after all. Just not via pure BASIC.


Programming-wise, we have seen nothing, though. To judge the true calc speed we will have to wait until we see game demos running on it. Also, although I am disappointed at the slower speed, I think this might be a good thing to a certain extent: The arrival of the 84+ resulted in an invasion of totally unoptimized BASIC games, because it ran at 15 MHz instead of 6, so people spent less time optimizing, since now their games just ran fast enough. I remember trying many RPGs in the past that ran at 4 FPS, yet they were as limited as Illusiat 6 (which runs at 11 FPS). In other words, maybe this calc will do like the TI-82 and 83+ and encourage newer BASIC programmers to try coding properly again .

Mhmm, color on the home screen would be nice, i bet there will be some awesome asm libs for basic......
Maybe the asm programmers should get togeather and agree on tokens so that it doesn't happen like xlib and omnicalc using real(

wouldn't zstart need to write extra-tokens into the program then? or just create an appvar of where what highlighting is in which program?

I'm not sure exactly how it works, but pretty sure it would just be something that looks at newly-visible/recently-edited code and just displays it differently.
Ofc how to integrate something that intense into the program editor when something as simple as instant goto is a challenge would be interesting to see

It would have to be a little more advanced than that, though, because of the status bar. Actually, if the LCD wasn't rotated 90 degrees, that might be possible, because the controller supports "Partial Image Display" that displays a certain part of the LCD RAM on a specified number of scanlines. But since our scanlines are vertical, that doesn't help very much.