I already own a TI-84+SE, which I bought because I didn't like the unsettling modernity of the CE; Plus, I also bought it because of the fact that the CE lacks a link port, which I use for my own projects.

However, I did come across the TI-84+CSE during my travels across the Net and it seems, to me, like a reasonable hybrid between the TI-84+SE and TI-84+CE. I want to purchase one for myself, but note that I will mostly just be programming it in Assembly rather than actually using it as a calculator. (From what I've seen, it's a tad slow, so I bought the TI-84+SE because it was a much more tried and true calculator by comparison.)

So, taking a look at the available include files (https://taricorp.gitlab.io/83pa28d/lesson/week1/day01/index.html#include-files), it seems the include file for the CSE is a lot shorter than the regular 83/4/+/SE. I believe this naturally implies that there exist many things we could do in Z80 asm on the CSE but can't because we don't know where everything is located in memory or how it all works yet. I also read a post on this forum earlier about how nobody has yet worked on discovering all the bcalls for the CSE.

So my question is, is the TI-84+CSE still a viable assembly programming platform (regardless of speed), even though it has less documentation and is less popular than the TI-84+SE and CE? (also, apologies if I am making any conceptually erraneous statements/questions, I am very new to TI calc programming, but I am willing to learn.)

Yes

It has doors CS 8. Thats about all going for it in my opinion.

The CSE is pretty comprehensively understood as far as I know - you can find information here: https://wikiti.brandonw.net/index.php?title=Calculator_Documentation#TI-84.2BCSE

There are speed issues due to it being similar to an SE but needing to drive a much larger screen. If you're creative you can still make good things for it.

Thank you all for the info. For anyone wondering, I’m trying to make an app that grabs pixel data from a microcontroller connected via the I/O port, display it on the screen, and send keypresses back to the microcontroller.

That would be pretty straightforward to do with ArTICL. The "app" on the calculator would be pretty trivial, as simple as a TI-BASIC program repeatedly running :RecallPic 1:Input Str1, which ArTICL on the microcontroller pushing an image to Pic1 and pulling the contents of Str1. Of course, if your goal is to cheat by having the microcontroller run a CAS or a chat program, I'm less enthused.

Thank you, I'm aware of ArTICL; I'm actually using an RP2040-based devboard, which is why I won't just be able to plug-and-play with ArTICL. It is excellent reference though, along with the linkguide.

As for why I'm picking assembly, performance is critical for the application. I already know that my 250MHz microcontroller will outpace the calculator's reception of display data by a lot, so I want to make sure I'm not wasting many CPU cycles. Moreover, as far as I'm aware, I won't be able to use the entire screen are with pure TI-BASIC on the TI-84+CSE; using the whole 320×240 display with 16-bit color was my main motive while picking both the calculator model and deciding the language I'd write the application in.

And I can assure you I'm doing this out of pure interest, and I think it would just look cool on my portfolio too. The goal here is to create a programmable microcomputer with a basic Windows 95-like "OS" that may be interfaced with via a USB Ethernet web interface, or a TI graphing calculator. The microcontroller enclosure I'm brainstorming will not make an attempt to be undetectable, and should in theory add roughly 2 inches of height to the calculator one snaps it on to. CAS or not, it would make for a pretty stupid-looking cheating device, haha. (I condemn cheating in all forms.)

I'm being bombarded by schoolwork at the moment, but I am using my spare time to prototype the actual protocol that would supposedly power the display stream and handle keypress input. The dream of getting my parents to drop >$200 on a graphing calculator for programming purposes is rather distant, so right now I'm working on a monochrome version of the whole project which would work with the TI-84+SE I already have, then when I *eventually* get my hands on a CSE I can port it all over; or in the worst-case scenario, I could rewrite most of it for the huge benefit of more resolution and color.

Got it, thanks for clarifying. It sounds like it might be worth considering using 320x240 in 8-bit color mode, or even 160x120 in 8-bit color mode, if you're concerned about pixel-pushing fast enough.

Incidentally:

• https://www.ebay.com/itm/285848630438 : $48 OBO shipped
  
• https://www.ebay.com/itm/276463190109 : $42 shipped
  
• https://www.ebay.com/itm/285854564049 : $41 OBO shipped

I would be confident about saving lots of money on a used one if my experience with used products off the Internet wasn't so bad. I guess I just have bad luck, but I suppose that I might give the one on the top a shot... it's the perfect color and has an acceptable return window...

I note that ebay has excellent and transparent (read their policies!) buyer protections, to the extent that it is a real pain point for sellers sometimes; I am not anxious about such things when buying from ebay.

Well that sounds alright. I'm more of an Amazon gal but I should give Ebay a try.

Now, where to funnel ~$50 from....

Can you block copy a screen/sprite at a time from the io port to video memory?

I’m not really sure, but my guess is that you do need some kind of CPU intervention as there is no DMA mechanism in the calc for this (AFAIK).

I have since resolved to stick to my monochrome calc, but I do know that I’ll be displaying 4-level grayscale on the screen by reading the status of the link port itself to get 2 bits at a time. Due to the structure of the data that the calc will be receiving through the link port, literally all it needs to do is pipe the link port input directly to the screen buffers, which are then copied to the LCD controller’s RAM as required.

You're going to be a little hard-pressed to transfer anything resembling realtime full-screen 2-bit grayscale (12.28Kb/1.5KB per second) over the link port while a 4-level grayscale interrupt is taking big chunks of your CPU power. Without doing the math, my gut feeling is you'll need to compromise on something: resolution, refresh rate, number of grayscale levels, etc.

When I am using Graylib 1.0 with my Axe program that directly modifies buffer memory, I get about 3FPS. When I use Axe's built-in grayscale mechanism the frame rate is much much higher (in the domain of 40ish) but the grayscale itself looks terrible. I might as well repeat the built-in one a couple times after each frame transfer to give up a little FPS but retain grayscale quality, but the Graylib implementation is undoubtedly the best one of all.

I might as well make two separate programs: one that works at an easy 30fps with sub-par grayscale and another that works at 3fps but looks amazing in terms of grayscale quality.