Any of those would be pretty acceptable considering that we're talking about a calculator here. However, as soon as we can figure out what kind of buffer size we have to deal with (SafeRAM?) and where the heck the screen itself is, then we can start to work on video.

I'm currently on Step 2, the "Freeze your calculator and figure out how to get it unfrozen part."

Well, one of the main problems is the virtual memory, which pretty effectively blocks us from knowing much about the Prizm itself.

But, we're way ahead of where the Nspire was for the first year only a week or so after the calc came out, because we have the ability to run arbitrary machine code. It's mostly a matter of eliminating the checksums for convenience (probably with a shell) and getting a good assembler working.

Virtual memory is kind of odd, but it basically works like this:

In reality, for many systems, the usable RAM areas are scattered far apart and a program constantly has to switch between them to use them. With virtual memory, every program(except for the OS) is presented with a continuous piece of empty memory that is free to use and may even be larger than the total RAM available. The processor keeps track of all of the complicated paging and the program has an easier to use memory space. The problem is that what we want is the physical memory. The virtual memory shields the physical memory and there's no easy way to get around it, at least without modifying the OS.

That's wrong 

You can disable the virtual memory by writing to the MMUCR register.

After some experiments i wrote a short bash script for converting an avi file to a cuv file (for the video player). It doesn't have audio support and the used dither is not the best one can think of. It uses ffmpeg, image-magick and bc.

In my tests (in the SDK) the audio (played from the original video) gets asynchron, so the framerate is probably wrong

* converts Wall-E for viewing it in his Math lessons...

#!/bin/sh
[ -z ${1} ] && echo "Usage: $(basename $0) <filename>" && exit||filename=${1}
duration="$(ffmpeg -i $filename 2>&1 | grep "Duration" | cut -d ' ' -f 4 | sed s/,// | cat)";
seconds="$(echo $duration | awk -F: '{ print ($1 * 3600) + ($2 * 60) + $3 }' | sed 's/[,]/./')";
framerate=40;
framesd="$(echo "$framerate*$seconds" | bc)";
frames=${framesd%.*}
for i in $(seq 0 $frames);
do time="$(echo "
scale = 3;
result = $i/$framerate;
if (0 < result && result < 1) {
print "0"
}
print result;
" | bc)";
echo $time;
ffmpeg -vframes 1 -ss $time -i $filename -f image2 pipe: | convert - -resize 128x64\! -ordered-dither o3x3  pbm:- | sed '1,3d' | cat >> demo.cuv;
done;

After some experiments i wrote a short bash script for converting an avi file to a cuv file (for the video player). It doesn't have audio support and the used dither is not the best one can think of. It uses ffmpeg, image-magick and bc.

In my tests (in the SDK) the audio (played from the original video) gets asynchron, so the framerate is probably wrong

* converts Wall-E for viewing it in his Math lessons...

Code: [Select]

#!/bin/sh
[ -z ${1} ] && echo "Usage: $(basename $0) <filename>" && exit||filename=${1}
duration="$(ffmpeg -i $filename 2>&1 | grep "Duration" | cut -d ' ' -f 4 | sed s/,// | cat)";
seconds="$(echo $duration | awk -F: '{ print ($1 * 3600) + ($2 * 60) + $3 }' | sed 's/[,]/./')";
framerate=40;
framesd="$(echo "$framerate*$seconds" | bc)";
frames=${framesd%.*}
for i in $(seq 0 $frames);
do time="$(echo "
scale = 3;
result = $i/$framerate;
if (0 < result && result < 1) {
print "0"
}
print result;
" | bc)";
echo $time;
ffmpeg -vframes 1 -ss $time -i $filename -f image2 pipe: | convert - -resize 128x64\! -ordered-dither o3x3  pbm:- | sed '1,3d' | cat >> demo.cuv;
done;

Hmm nice. Unfortunately I do not know much about bash scripts, how do I run them? Do they require Linux?

On a side note, welcome on the forums.

Quote from: DJ Omnimaga on January 26, 2011, 02:06:22 am

Yeah but your previous post seemed like it made it look like it caused more troubles for us to figure out how the Prizm RAM works...

It did, simply because it prevents easy RAM dumps. Now that we have the OS, it shouldn't be as much of a problem.

Ok, thanks for clarifying. I'm so not tech-savy about that stuff. X.x