I've been working on a video codec for the TI-8x calculators (or for virtually any device with a monochrome screen) sporadically over the past couple of years. My initial target was the TI-86, but I haven't written any actual assembly code for it yet; I only have working C source for the encoder and decoder.

In my tests, I have achieved compression ratios between 55% and 88% (45% and 12% of the original file size, respectively), depending on the selected video quality. The quality is pixel-exact at 55% and is still quite good up to about 70%. Above that the quality degrades significantly (but it does produce some interesting "artist" effects ). To translate these figures to real-world numbers, a 4:44 long video at 8 fps (128x64 pixels) at 70% compression (decent quality) totals about 694678 bytes. That's an average of 307 bytes per frame, out of the original 1024 bytes in an uncompressed frame. Obviously this is a longer video than anyone would likely to store on a calculator (and about 6 times bigger than the capacity of the TI-86), but shorter videos, say 30 seconds or so, might be quite practical.

Anyway, I'm trying to find out if any other programmers would be interested in such a video codec. If so, I'll post more information about it and some animated GIFs to demonstrate the quality levels, and then I'll probably continue developing it so others can use it. Otherwise I might just abandon this project to focus on other projects.

Be forewarned, though: as I mentioned above, I haven't written any Z80 code yet, so I don't know for sure how well it'll perform. However, I did design the codec to be simple and easy to decode. The encoder, running on a real computer, does the hard work. On my slow, old computer, the encoder runs in about 20 seconds, while the decoder runs in about 2.5 seconds (both on the same 4:44 test video). The C decoder isn't even well optimized. Also, a full-screen video at 8 fps will allow over 5000 clock cycles at 6MHz per 8x8 pixel block (the codec is block-based), which I think will be more than enough. Heck, 500 clock cycles per block may be enough.

I'd love to try translating this codec to z80 (if I can find the time). I definitely encourage you to post it, and we can see what we can do with it. Heck, this might be what we need, combined with the GBC webcams that Shaun and I have, to get streaming videochat over CALCnet working.

What do you plan to use for encoding the video? As I mentioned, decoding should be pretty fast, but encoding is somewhat processor-intensive. For example, I have a function that compares two blocks and returns their "visual" difference. It does so by a) counting the number of bits that are different (equivalentally, the number of 1 bits after xoring the blocks), and b) adding up the squared differences between the blocks after blurring them with a simple 2x2 box filter. The filtered difference gives preference to blocks with differences spread out rather than clumped together. This comparison function runs up to 144 times per block. It also has to test out 15 bitwise rotations (as opposed to angular rotations) per block. I can see this adding up to tens or hundreds of thousands of cycles per block, or millions of cycles per frame.

Of course, if you're willing to sacrifice quality, frame size, and frame rate, it may be feasible to encode video in real time on the calculator. Also, I didn't design it to be robust; any errors in a frame will, at best, stick around forever, or at worst, throw off the decoder's position in the stream entirely. You may have to change the design to account for that. I designed it more for static (non-real-time), error-free files that can be played backward almost as easily as playing them forward.

That sounds pretty awesome. You should definitely post screenshots. Kerm, it would be awesome if you could video chat over CALCnet.