Compression is almost certainly impossible. I could actually almost see this being easy as a matter of fact. Just interlace the video and sound byte for byte and during the time that was previously used to decompress, write a byte to the screen.

Using this strategy, the video would be forced to run at 27 fps and the filesize would be 44KB/s (0.91DCS/s). Meaning 34 seconds of video. But it's possible.

Clearly no grayscale though. Sound requires uninterrupted CPU time and grayscale requires interrupts.

It just happened. The first ever true calculator Rick Roll.



Description:

Using my new program for the 84+, FourVid, I am able to play 4 level grayscale videos on the calculator. Then by combining that with my other program, TruSound, I am able to play videos sync'd with sound!

Obviously this is on an 84+SE. Both the sound and video files are 1.3MB in size, which means that I had to clear the memory on both of them before I started.

Here are the files needed to play it. Just note that the sound file is clocked for wabbitEmu (15MHz) so it will run too fast on a real calculator (16MHz).

Also, if you have sent any of my videos to your real calc. You may have noticed that you are missing some memory. This is because some of the app pages started with $FF and the calculator won't delete them. So the only way to get the memory back is to back up everything on your computer and then clear All Mem. This RickRoll video also suffers from the same problem. Sorry about that. I'll fix that soon.

Haha, the files are too big for this post. Video, player, song.

That is just... intense. I didn't know you could swap pages that quickly, though.

Swapping pages is instant. Meaning it's the fastest way to move data. (You're not really moving it though.)

It doesn't seem to work on a real calc, what do you have to do with the files?

It should work. I was showing people at school. Send both files, from the same post, and run the program. The app only contains data. Oh, and it definitely won't work on an 83+ for so many reasons.

I'm thinking of doing a variation of DEFLATE. Here is the specification if anyone is interested. (if you're going to look at it, the important part is the top of page 11) It is essentially LZ77 paired with huffman tables for the distances and lengths. It's what .png uses so I figure it's good for pictures/video. What I think I'll do is just use the uncompressed and Fixed huffman table parts of it because I don't think my file sizes are big enough to be able to use the dynamic huffman table properly.

Since LZ77 using a sliding window, that creates a sort of problem when doing it on the calculator due to memory requirements. I am thinking of using a sliding window of 768*2*2=3,072 because that is two frames. To accomplish this quickly and efficiently, I'm going to move data around by switching pages rapidly. In what might be the most hacked memory configuration yet, I will have the flash page in the $4000 slot. I will have $3A00 bytes of page $81 swapped into the $8000 range through port ($28). Then, I will alternate having pages 0 and 3 swapped into the $8000 range and the $C000 range so that the two frames are always in the same place: $BA00 and $FA00. Hopefully, this will allow me to get the speed and address space required to make this work. (I'm backing up page 0, so don't worry.)

What do you mean by dithering in this case? If you are talking about the scan lines, those are only present in wabbitEmu. I tried it on my real calculator and they are hardly noticeable.

You are also definitely correct about the compression artifacts. I traced the steps through and it looks like SUPER caused them when it converted the .flv to .jpg's. But as of now, I don't know any other way to do that step.

For decompression on the calculator, there is definitely enough time. 16,000,000 hz * 50 % (grayscale) /15 = 533,000 clock cycles per frame. That's 347 clocks per byte, clearly enough time to do something amazing. The only thing I'm doing right now is converting strings of 00's and FF's to 00 00 (length) and FF FF (length).

SirCmpwn, the problem with Fake is that once the kids figure out that it's enabled, they'll just delete it and start deleting things again. I would think that Fake is more to stop teachers rather than other students. Plus, it can't stop you from individually deleting files. (And I too learned that it doesn't work on MP OS's the hard way.)

As for an 83+ patch, I'm sure I can do that. It's not much different other than the fact that unlocking flash is different and port (06) doesn't AND the page numbers.

I don't think Err:MSM is supposed to happen. I would imagine that the program crashed and jumped to somewhere it wasn't supposed to. I've got Waiting... Please install an operating system now from crashing a program before.

Are they smart enough to do the FLASH self-test to clear the archive?

That can only be invoked when you don't have an OS. And it clears all the flash, not just the archive.

Thepenguin77, can the final OS patch that allows still allows deleting apps/progs, but moves it, be ported to the 2.43?

I already did. Check back in the responses.