Yay, your first optimization! Those are equivalent in everything but t-states and bytes. Yours is 3 t-states faster and 1 byte shorter.

Of course the best optimization would be   ld    hl, 205. 

Well... I did it. The program does the same thing in both languages. It was a fun challenge, but it was also really hard. The main problem is that bcall is represented by $EF, and it has no token counterpart. So the next logical thing is to skip that step and straight call $0028. But guess what, no $00 either.

Here is the code in both languages.

Basic:
:
:
:Disp "(0.0)_Hel
lo!!!!"
:Return
:_sin-1(fMax(0fMa
x(0CubicReg 0_ra
ndM(HDegree>>(not equals)me
an(mean(mean(mea
n(00000000mean(a
bs(Vertical ?2in
t(Vertical 210^(V
ertical tanh-1(?V
ertical rEtanh-1(
?Vertical CubicR
eg Ey

And assembly:
.db $BB, $6D
sbc a, $2A
djnz $9DC9
ld a, ($1130)
add hl, hl
ld c, b
cp e
or h
cp e
cp h
cp e
cp h
cp e
cp a
dec l
dec l
dec l
dec l
ld hl, ($D53F)
ccf
add hl, hl
_9DAF:
jp $3028
_9DB2:
.db "(0.0) Hello!!!!"
_9DC1:
.db $30, $30
jr nc, $9DF5
jr nc, $9DF7
jr nc, $9DF9
_9DC9:
ld hl, $9DB2
xor a
ld ($9DB1), a
ld ($9DC1), a
call $9DAF
.dw _putS
call $9DAF
.dw _newLine
cp e
ret

BB 6D shows up as a ? on the calc as you can see from the screen shot. But that is the only token that I had to use calcsys to get. The rest of the program was typed in by hand. For converting back and forth, you change those first two returns to BB 6D.

Has a calculator every been completely junked? BrandonW bricked a few, but he made a fix for that. The only thing I guess you could really screw up would be the LCD. Unless maybe you replaced 0000 with jp 0000.

Sure, I'll send it to you when I'm done. The only problem is that you have only and exactly 182 t-states to get a byte. I'm not exactly sure how you'd do that with usb. But if you pull it off, that'd be nice.

Actually, the playing part is finished, compression's all I'm working on. You'll have to modify it a bit to fit your needs, but here's how it works. You have to figure out exactly how many t-states you have to work with. You do this by taking your processor speed and dividing it by your sample frequency. Mine is 15,800,000 / 22,050 = 716 t-states. Then you have to subtract the length of the subroutine, which is 516 delay + 41 = 557. You also have to subtract the code that makes the jump, 51. This leaves you with 716 - 557 - 51 = 108. But your not finished, you also have to exx out your code. So 108 - 4 - 4= 100. 100 t-states for 22,050. Going to 20,000 hz will give you an extra 74. So 174 is the magic number to work with.

As far as the source, you can delete all of the _44100: data. I just keep it because it took so long to make. You should also delete the _0: _1: stuff as that is my Huffman decompressor.

Memory wise. The whole thing runs in C000-FFFF. Which means that 4000-BFFF are free to use.

I don't know how big your loop is, but I would say that the problem is that you aren't pressing both keys at exactly the same time. Remember, the calculator runs at 6 MHz. That means that a relatively big loop, say 5,000 clock cycles runs 1,200 times per second. Which also means that you have to press the keys within 1/1,200 of a second because if one is pressed first, just that one is counted and your code says don't look for another.

Here is what I would suggest to fix the problem. When a key is pressed, a count down is started, when that countdown reaches 0, it really does the key scan and then jumps.

;pressed is my counter and my pressed flag
;saves space that way


ld a, $BF
out (01), a
ld a, (de) ;this is 7 t-states, but 1 byte
in a, (01)
ld b, a
ld a, (pressed)
or a
jr z, initialScan
jp m, countDown

inc b ;if no keys are pressed, b = $FF
jr nz, buttonDone
xor a
ld (pressed), a
jr buttonDone
initialScan:
inc b
jr z, buttonDone
ld a, -15 ;adjust this delay for responsiveness / window for two presses
ld (pressed), a
jr buttonDone
countDown:
inc a
ld (pressed), a
jr nz, buttonDone

inc a
ld (pressed), a ;putting a one to show its pressed

;do all your two button cp's here
;always use jr instead of jp, jr is 3 t-states faster on fail and 1 byte smaller

;for your singles, I have some optimization

rrca
jr nc, presGraph
rrca
jr nc, presTrace
rrca
jr nc, presZoom
rrca
jr nc, presWindow
rrca
jr nc, presYEqu

;cp is two bytes and 7 t-states
;rrca is 1 bytes and 4 t-states

buttonDone:
This one puts a set delay in between press and go which allows for the second to be pressed.

There is also another option where you wait for the keys to be released and then check what was pressed.

;this time pressed holds the last pressed keyscan


ld a, $BF
out (01), a
ld a, (de)
in a, (01)

ld b, a
ld a, (pressed)
or a
jr nz, checkForRelease

ld a, b
inc b
jr z, buttonDone

ld (pressed), a
jr buttonDone

checkForRelease:
inc b
jr nz, buttonDone

ld b, a
xor a
ld (pressed), a
ld a, b



;do your checks here
;don't forget what I said in the first one



buttonDone:

I like writing little optimized routines. After writing both, I kind of like the second one better. But it's up to you, release or delay.

Yes.

My program used to jump to 0000 when it was done, it doesn't now.

A lot of frustration has occurred since my last post. Although no one really cares, here is what happened.

1. I got 22khz working.
2. Ti-connect refused to send the 1250k app via usb.
3. After 30 minutes via silverlink, my batteries died.
4. I got compression with LZ77 working, (uses past 16k as a reference for copying)
5. .wav files compress .5% via LZ77.
6. New compression algorithm cuts 5%-10%
7. New batteries, sent via silverlink in 30 min, invalid
8. Installed tilp, spent lots of time working it out.
9. Tilp crashes on 1250k but sends smaller ones.
10. Those smaller ones are invalid.
11. Got wabbitsign instead of wappsign and signing works.
12. Tilp stops working all together.
13. Reinstall Ti-Connect, and send the new 1 minute sample.

Here is the video I promised.


After my complete failure with LZ77, I looked at the hex of the .wav files to see what I could do. I noticed that there were lots of numbers in the $70's and $80's. So my compressor writes numbers between 79 and 87 as nibbles to save space. So instead of 79 7A 7B 7C 7D 7E 7F 80 81 82. It writes 00 12 34 56 78 9A 00. The 00's are flags telling when compression starts and stops. This works decently, especially with quiet sections.

If anyone has any suggestions to compression techniques I'd love to hear them. The only problem is that they have to be able to get the next byte in exactly 108 t-states. But I do have a whole 16k ram page to work with.