Now, I'm sure you've all been checking back at this topic every day for an update. And it is finally here.

I've managed to use a modified version of DEFLATE to compress the video files. So far with normal videos, its been getting compression ratios of about 40%-50%. This video right here got a compression ratio of 46%. It's 90 secs and is 1.1 MB.



I also fixed the memory problem. Now all the pages start with 00 and are safe for use on a real calculator.

Edit:
    I've never officially said this. But ON stops the videos. ON creates an interrupt and therefore doesn't require any code to be run until it is pressed, that way the videos play faster.

Edit2:
    Wow. The oldspice video got a compression ratio of 69%. It's now only 230k.

I don't know of any so I just made this up.


;###################################
;div 24 by 24
;bcd / ehl
;ouput: ehl = quotient
; bcd = remainder

divScratch equ $8000

divBCDbyEHL:
ld ix, divScratch
ld (ix), d
ld (ix+1), c
ld (ix+2), b
xor a
ld (ix+3), a
ld (ix+4), a
ld (ix+5), a

ld b, 24
div24Loop:
sla (ix)
rl (ix+1)
rl (ix+2)
rl (ix+3)
rl (ix+4)
rl (ix+5)

ld a, (ix+5)
cp e
jr c, notBigEnough
jr nz, oversize

ld a, (ix+4)
cp h
jr c, notBigEnough
jr nz, oversize

ld a, (ix+3)
cp l
jr c, notBigEnough
oversize:
inc (ix)
ld a, (ix+3)
sub l
ld (ix+3), a
ld a, (ix+4)
sbc a, h
ld (ix+4), a
ld a, (ix+5)
sbc a, e
ld (ix+5), a


notBigEnough:
djnz div24Loop

ld l, (ix)
ld h, (ix+1)
ld e, (ix+2)
ld d, (ix+3)
ld c, (ix+4)
ld b, (ix+5)
ret

As far as I know, it works. You can change the outputs and inputs pretty easily as you can see, and you'll have to define divScratch to somewhere.

But, if I know this forum, just wait a few hours and you'll have one half as big and twice as fast from calc84maniac.

Edit:
    Oops, that version had values hardcoded in, now it doesn't.

Okay, now that is awesome. The fact that the nSpire is being utilized so well is just awesome, even if it is a rickroll. Someone should do the Double Rainbow... 

Now, sound would actually be quite easy to do. I'll illustrate how a filmstrip works:

----------------------------------------------------------------------------
------ ------ ------ ------ ------ ------ ------ ------ ------ ------ ------
|o   | | o  | |  o | |   o| |    | |    | |    | |    | |    | |    | |
|    | |    | |    | |    | |   o| |  o | | o  | |o   | |    | |    | |
|    | |    | |    | |    | |    | |    | |    | |    | |    | |o   | |
|    | |    | |    | |    | |    | |    | |    | |    | |    | |    | |
------ ------ ------ ------ ------ ------ ------ ------ ------ ------ ------
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
----------------------------------------------------------------------------

As you can see, the top section contains the picture that is displayed on the screen. Alongside the picture area, there is a little area for sound (the ~ things). While a picture is shown on the screen, the sound adjacent to the picture is played on the theater's speaker system.
A digital video would work much the same way. While a video is shown on the screen, the little sound bite associated with that picture would also play through the speaker system.

Getting the information to play the sound is not what is difficult. That's easy, just make every 5th byte sound data or something. The problem is playing it on a calculator. Most computers and ipods have sound cards, so all the program has to do is send the sound data out for processing. Some cheaper devices just have a Digital to Analog Converter, which when sent a value, puts that proportion of voltage on the line. For this you would have to send the sound data out at a regular interval.

However, the Nspire has neither. The Nspire has a choice of 100% or 0% voltage, not 65,536 steps. So to make intermediate values, you put it high then low for varying amounts of time depending on the value. And to make this happen accurately at 22,050 Hz takes nearly all the processor time. To add sound, you essentially have to make a sound player and add video. You can't easily add sound to a video player because it require extreme priority. With so many mp3 players around, unless you have great quality sound, people are going to complain while if you have a bad video, it's just a calulator.

That's a pretty cool website. I made it all the way to paradise city. (0, 1000) Was it worth it? No. But I still did it.

Apps don't come out pretty. Here it is relatively as small as I could make it but the header is just massive. I was getting kind of annoyed with bcall(_jForceCmdNoChar)'s refreshing of the screen so just press any button to quit the app.

code:
.nolist
#include "ti83plus.inc"
.list
.org $4000

 db 080h, 00Fh
 db 000h, 000h, 000h, 000h
 db 080h, 012h
 db 001h, 004h
 db 080h, 021h
 db 001h
 db 080h, 031h
 db 001h
 db 080h, 048h
 db "Hello", 000h, 000h, 000h
 db 080h, 081h
 db 001h
 db 080h, 090h
 db 003h, 026h, 009h, 004h
 db 01Ah, 086h, 054h, 0E9h
 db 002h, 00Dh, 040h, 0A1h, 06Bh, 099h, 0F6h, 059h, 0BCh, 067h
 db 0F5h, 085h, 09Ch, 009h, 06Ch, 00Fh, 0B4h, 003h, 09Bh, 0C9h
 db 003h, 032h, 02Ch, 0E0h, 003h, 020h, 0E3h, 02Ch, 0F4h, 02Dh
 db 073h, 0B4h, 027h, 0C4h, 0A0h, 072h, 054h, 0B9h, 0EAh, 07Ch
 db 03Bh, 0AAh, 016h, 0F6h, 077h, 083h, 07Ah, 0EEh, 01Ah, 0D4h
 db 042h, 04Ch, 06Bh, 08Bh, 013h, 01Fh, 0BBh, 093h, 08Bh, 0FCh
 db 019h, 01Ch, 03Ch, 0ECh, 04Dh, 0E5h, 075h
 db 080h, 07Fh
 db 000h, 000h, 000h, 000h
 db 000h, 000h, 000h, 000h
 db 000h, 000h, 000h, 000h
 db 000h, 000h, 000h, 000h
 db 000h, 000h, 000h, 000h

bcall(_clrScrnFull)
bcall(_homeUp)
bcall(_clrTxtShd)
ld hl, text
loop:
ld a, (hl)
or a
jr nz, notDone
bcall(_newLine)
loop2:
bcall(_getCSC)
halt
or a
jr z, loop2
bcall(_jForceCMDNoChar)
notDone:
bcall(_putC)
inc hl
jr loop


text:
.db "Hello world", 0



.end
Hex:
80 0F 00 00 00 00 80 12 01 04 80 21 01 80 31 01 80 48 48 65 6C 6C 6F 00 00 00 80 81 01 80 90 03 26 09 04 1A 86 54 E9 02 0D 40 A1 6B 99 F6 59 BC 67 F5 85 9C 09 6C 0F B4 03 9B C9 03 32 2C E0 03 20 E3 2C F4 2D 73 B4 27 C4 A0 72 54 B9 EA 7C 3B AA 16 F6 77 83 7A EE 1A D4 42 4C 6B 8B 13 1F BB 93 8B FC 19 1C 3C EC 4D E5 75 80 7F 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 EF 46 45 EF 58 45 EF 4C 45 21 A3 40 7E B7 20 0D EF 2E 45 EF 18 40 76 B7 28 F9 EF 27 40 EF 04 45 23 18 E9 48 65 6C 6C 6F 20 77 6F 72 6C 64 00
(copied from the app compiled as a program)


TruSound was just my attempt to get sound to work on calculators missing the extra ram pages. (Actually, it was the final product of my older, never released sound programs, of which the first was 1 bit sound). Also, I don't like to use things I didn't make, so I wouldn't let myself use a sound program that wasn't created by me.

i do know a BASIC syntax for this:

Code: [Select]

getTime->L1


And just like almost every basic command, it has a bcall counter part. bcall(_getTime) puts seconds, minutes, and hours all on the floating point stack. The method of retrieval can vary, but there are two distinct strategies. Pop and grab each one through op1, or pop them consecutively into op1 2 and 3.

So, method 1:
EF5B51 EF9043 grab OP1 seconds EF9043 grab OP1 minutes EF9043 grab OP1 hours
And method 2:
EF5B51 EF9043 EF8D43 EF8A43 OP1 = secs OP2 = minutes OP3 = hours


Just remember that those answers are TI floating point. So you'll have to convert them.

Well, maybe. The video and audio have to be interlaced in some easy fraction. So assuming 23000 bytes per second on audio and 800 bytes per screen (768 + driver commands) 1/2 would be 14.5 fps. Which I guess is perfect. That was easy.