Uh, lulz?

Well, this proves that porting is going to be REALLY hard.

Somebody should make a tool for displaying pictures in the B/W format possibly using a customisable pallet and resizing options. Then pictures could still be 768 bytes of data. I know I wrote a quick routine and posted it on Cemetech for just that purpose,so maybe somebody can take it and turn it into a useful program

I was considering attempting just such a shell, DJ_O, but I have no time.

Lol, that would be a lot of arc. >.<
Maybe image compression?

It would not be too hard on a processor/RAM point of view but to keep the emulator as close as possible to normal speed the screen would have to be refreshed less often. Grayscale emulation would definitively be hard. I would say maybe something like Emu8x for the 83+SE/84+SE but that can also emulate the TI-73 and 83+ instead of just the 82, 82 Stats/83/76.Fr, 85 and 86.

I could probably count as many as 12 different patterns, systems, and styles of grayscale. Everybody does it differently, mostly because the only games where it is used are worthy of awesome graphics. Grayscale games are written by experienced coders usually, and they are all tailored to the game because it works better different ways for different reason, what with the slow CPU and all. Grayscale emulation would be impossible, programs would have to be rewritten into a standardized way or new ones would need to be written. A detection routine may be possible, finding where the screen is updated constantly... But I suggest using an interrupt that only updates the screen when needed. I have a feeling, however, that a converter will be written so games can be ported to the CSE in a snap.

I guess that the emulator could feature multiple display modes instead of just Nspire-like. For example, 3x scaling would be the slowest of all, while 2x and 1x would be faster, but harder to see due to small screen. Adding scanlines that don't move would be twice faster, more when extra scanlines are used.

Some examples where you don't necessarily have to update every single pixel:

My routine to draw a 96x64 B/W image using the format that the regular 83/84 calcs have took 308016 t-states to update (about 20FPS at 6MHz).

A routine to just copy a whole image in color is somewhat faster. To make the code small, it would take about 3222600 t-states for a full color image with uncompressed data. Adding a little extra code to make it faster, it can be brought down to 2553600 t-states (about 2.35 FPS).

That being said, the CSE makes it very easy to update only a portion of the screen. so if you have areas of the screen that do not get updated frequently, such as menu items or an HUD, and you cut down how much of the screen is updated to just a 240x240 region, you can draw a 15x15 tilemap of 16x16 sprites at about 3FPS (6MHz) (a single 16x16 sprite, full color, takes about 8512 t-states to draw). You could get 7FPS for a 10x10 tilemap, but then you are only using 160x160 pixels of the screen (half the width, 2/3 the height).