Can't wait for this to come out!  I wonder is TI is pushing the 84 now due to poor Nspire sales?

You know, it's quite likely that this thing will have more VRAM than CPU RAM, and the VRAM will still be fairly fast. We could write for it a new garbage collector that buffers sectors into VRAM. (Assuming, of course, that we can still read from it, like we currently can.) And unlike buffering into the extra 80 K of RAM we don't have anymore, TI can't remove the VRAM without breaking their own shiny new display. Best of all, it'll make a really cool "busy" animation.

What do you mean by video buffer in the archive? Streaming a static picture out of the archive would be quite fast, and the assembly community will definitely find a way to do it, what with the severely limited RAM we're bound to deal with. But if you're thinking of dynamically changing the picture in the archive, that would definitely be pretty slow, and wear out the chip faster than any ridiculous thing we've hacked up.

Tangentially relevant discussion from #cemetech:
(12:02:14 AM) BrandonW: I very much have my doubts about accessing 4MB of Flash with the paging hardware as-is. I think they changed it to support the color LCD, and while they were at it, allowed more Flash.
(12:02:22 AM) BrandonW: Or, perhaps the logic was vice versa.
(12:02:49 AM) DrDnar: I bet they threw in more flash more as an after thought.
(12:03:17 AM) ParkerR: Or maybe once they are trying to be nice...
(12:03:20 AM) ParkerR: Naah that cant be it
(12:03:25 AM) ParkerR:
(12:03:27 AM) DrDnar: Can't be it.
(12:05:22 AM) DrDnar: Since you figure TI will invariable choose the least-efficient method of storing pictures, I bet they realized that 320*240 = 76800 * 4 = 307200 bytes, so 1.5 MB won't hold very many pictures. (Least efficient method = bitmap with 24-bit color and each aligned to 4-byte boundaries, i.e. wasting 8-bits.)
(12:06:24 AM) DrDnar: 1.5/0.3 = 5 and 1.5 / 0.08 = 18
(12:11:46 AM) DrDnar: We'll have to take up the slack in TI's penchant for wasting space by making lossy-compressed image decoders ourselves.

Yeah, exactly.

Also, unlike the 128 K of RAM, the 4 MB of flash is advertised. (TI buys flash chips from other companies---at least three are known---and the chips only come in certain sizes. TI can't knock off 128 K of flash unless they custom manufacture the chips.)

So I quickly made up some sample images showing various ways to downsize an image. I want to point out the nearest neighbor is the most simple way to downsize an image and also produces the worst results, at least for typical photographs. Similarly, if the TI-84+C uses palette-tized color, there are various methods TI could use to reduce the color depth of images. The color reduction image uses 4-bit color (16 colors) to highlight the differences between algorithms, but it's possible the TI-84+C will use 8-bit color (256 colors) or 16-bit color (65536 colors). (16-bit color is good enough for most non-photographic purposes; the primary reason to use 24-bit color in computers is that it's a lot easier for software to work with.) Again, the simplest way to handle color reduction is using a fixed palette with no dithering, which also gives the worst results. I'll let you decide which algorithms TI will use.

EDIT: I screwed up a bit with the fixed palette one. It actually has 74 colors. And still sucks the most.

Edit 2: I just noticed the moiré pattern on the inside of the hat on the bicubic sharper reduction, which I also used for the color reduction image set.

The image resizing only needs to be done once, so it will probably end up being bicubic. (default option in GIMP and many other decent photo editors)

I wouldn't be surprised at all to see a palleted system, but if it's there it will probably be adaptive pallete, since the screen is capable of far more. And I seriously doubt it will be reduced to 16-color. 256-color seems far more likely (16 is only a nybble per pixel. 256-color adaptive pallete is easier to write in C)

I was wondering which system TI Connect would use to convert images before sending them to the TI-84+C. It may be true that there are good existing open source solutions, and it's also true that TI will probably never consider using an open source solution, and decide against licensing commercial code.

I want to point (again?) out that using 8-bit color maybe not be so great for games because a back-buffer would require 77 K of RAM. There may not be enough RAM in the system to make a back buffer, and if there is, filling/sending it would require at least 3 page changes, possibly 5. 4-bit color reduces that to 2 or 3 page changes, and if TI adds no RAM, still leaves games with 10 K of RAM, assuming nobody minds RAM resets. And that's just filling, nevermind drawing. But the best option would be selectable color modes. If there's a monochrome mode, a back-buffer would only require 9600 bytes.

And, of course, a non-back-buffered gaming graphics solution would invariably force programmers to continuously consider flickering issues.

Im wondering why they went with such a high resolution screen? Surely something like a 160x120 would have sufficed?