He probably did that on purpose to avoid scrolling too far in the video.

Well, you have BASIC right out of the box.

Pretty cool. The “half horizontal resolution” mode doesn't look bad at all.

This reminds me that the classic consoles such as the NES actually were quite limited on how many tiles could be updated per frame. They took advantage of having an extra screen-sized buffer, just as in this example (some games didn't even use that) to update rows or columns of tiles off-screen just before they scrolled into view. In this case, there is no direct hardware support for sprites; those would still need to be directly drawn, but if that can be done fast enough, this certainly does look promising, framerate wise. The biggest key here will be how many pixels can be updated per frame, and how much CPU time will be needed by AI and logic.

And Basic can do this?

Since the calc is as fast for math calculations as the 84+SE (only graphics/drawing are slower), I wouldn't be surprised if such speed could be rivaled using ASM libs in a BASIC program (such as xLIB 2?). It wouldn't be as fast with collision detection, of course, but it could be a good alternative to just updating the entire screen every frame.

But yeah, the calc isn't locked down in any way in terms of programming. Of course now you're stuck with a Mathprint OS, but otherwise for programming this calc is an huge contrast with the stance TI took against Ndless on the TI-Nspire.

To be honest I am surprised that the drawing before scrolling is that slow. It seems to me that it's not super optimized or it runs at 6 MHz. Kerm made a demo program once that could redraw the entire screen 4 times a second.

Oops i updated the link to the video to remove the screen artifacts. It can be seen here:

That does look really nice! How much space does all the data take up?

EDIT: Or is the source posted anywhere?

Is it archived while read?