This code works perfectly in Wabbitemu, but it fails on actual hardware.  By looking at the calculator's display, it seems that the interrupt isn't even triggered at all.  What am I doing wrong?

#include "ti83plus.inc"
.org $9d93
.db t2ByteTok, tAsmCmp

#define dwait in a,($10) \ rla \ jr c,$-3

start:
bcall(_delres)
di

dwait
ld a, 1
out ($10), a

dwait
ld a, 5
out ($10), a
dwait
ld a, $20
out ($10), a
dwait
ld a, $80
out ($10), a


im 2
ld a, $8B
ld i, a

ld hl, $8B00
ld (hl), $8A
ld de, $8B01
ld bc, $FF
ldir

ld hl, intRoutine
ld de, $8A8A
ld bc, intRoutine_End - intRoutine
ldir

ld a, %00001000
out ($03), a

ld a, $44
out ($30), a
ld a, 3
out ($31), a
ld a, 1
out ($32), a
ei

loop:
ld a, $FE
out ($01), a
ld hl, (soundNum) ;do something
nop
nop
in a, ($01)
bit 0, a
jr z, keyDownPress
bit 3, a
jr z, keyUpPress

ld a, $FD
out ($01), a
nop
nop
nop ;how much delay are you supposed to have?
nop
nop
nop
nop
in a, ($01)
bit 6, a
jr z, keyClearPress

jr loop

keyDownPress:
inc hl ;counterintuitive.  I know.
ld (soundNum), hl
jr loop

keyUpPress:
dec hl
ld (soundNum), hl
jr loop

keyClearPress:
di
xor a
out ($31), a
out ($30), a

im 1
ld a, %00001011
out ($03), a
ei
ret ;bye bye


intSound:
ld a, $44
out ($30), a
ld a, 3
out ($31), a
ld a, 1
out ($32), a
call fillScreen

push bc
push hl

.db $21 ;ld hl,**
soundStore:
.dw $0100
dec h
jr nz, intSound_ret
.db $01 ;ld bc,**
soundNum:
.dw $1600
add hl, bc
.db $3E ;ld a,*
intSound_aSave:
.db $00
xor %00000011
ld (intSound_aSave), a
out ($00), a
intSound_ret:
ld (soundStore), hl
pop hl
pop bc
pop af
ei
ret

intRoutine:
push af
;int handling
;jump if port 30 interrupt
jp intSound
intRoutine_End:

fillScreen:
push af
push hl
ld hl, fillScreen_rowCount
inc (hl)
ld a, $C0
cp (hl)
jr nz, fillScreen_Draw
ld a, $80
ld (hl), a
out ($11), a
dwait
fillScreen_Draw
ld a, r
cpl
rlca
ld r, a
out ($11), a
pop hl
pop af
ret
fillScreen_rowCount:
.db 80

Thanks for your help!

---

EDIT1: I need to read port ($04) to acknowledge the interrupt timer.  One would normally do this in a program, so most would not encounter the problem.  it just seems like an odd hardware quirk to me.

---

EDIT2: Okay.  I have now idea what is going on.  I thought the above was a solution, but stuff is still acting weird.

Hi, everyone.

I'm pretty confused about programming the Casio Prizm.  

I successfully compiled the Hello World test program, but I can't really do more than that.  I'm pretty much a noob at pointers in C.  

How exactly do I plot a pixel to the screen?  I know that vram is at 0xA8000000.  How do I make a pointer to it and copy a color
What is the format of the 16-bit colors?

Thank you so much for helping me.  

EDIT: Alright.  I managed to plot pixels on the screen.  Is there a way of disabling the annoying border?

The ASM board hasn't been as active as it should be, so I'm starting a weekly discussion called "ASM Command of the Week."  Basically, we will discuss hacks, routines, optimizations, or alternatives to the command.  

It's basically going to be like these topics, except this one is going to be weekly.
DJNZ:
http://ourl.ca/13569
RLD and RRD:
http://ourl.ca/12758
IX and IY:
http://ourl.ca/12633

We'll start with a really easy one.  This week's command is:
XOR

Hello, all!

Recently, I have gained more interest in the TI-84 Plus SE's USB port.  Unfortunately, information on the ports seems sparse and incomplete.
I have taken a look at http://wikiti.brandonw.net/index.php?title=Category:83Plus:Ports:By_Address and http://wikiti.brandonw.net/index.php?title=83Plus:OS:84_Plus_USB_Information, but I have no idea where to start.

The USB port seems very complex in contrast to port $00.  Can anyone provide sample test routines for the USB interface?  More specifically, I am interested in using the calculator as a device (as opposed to a host).

One of my biggest gripes of electronics is the implication that electricity flows from positive charge to negative charge.  This is of course incorrect, because electrons move from atom to atom. 
Positive charge can move in a liquid, but electricity is used more frequently in solid state electronics (as stated above).

Which convention do you think is the most practical. 
I personally think that someone should rewrite the books and make everything more consistent. 

Wow, this has to be one of the most WTF song I've ever heard.  It's not that funny in context, but I can imagine sending this video to an unsuspecting victim.  



EDIT: This one is even more over top. 

I'm currently working on a 7 - level grayscale routine.

Why not 8?  With 7 level grayscale, each color pattern is equally spaced.  This is one of the reasons why 4 and 3 level can look so perfect (as opposed to 8 level).  (Another culprit is the hideously slow lcd refresh rate, but that is a different story.)

111010 - Not equally spaced (Notice the last 010 and how it makes it look lopsided.)
110110 - Equally spaced (You can chop this in half and get the same 3 bits.)

000000
100000
100100
101010
110110
011111
111111Of course, these bits can be in different rotations.

Currently, I only have a 6 - level grayscale routine because I can't figure out a mask.  
Here is what I currently have:
Masks:
011011
101010
100100

Patterns:
000000
100100
101010
101110 (bad)
011011
111111 (duplicate)
111011
111111
Can someone please help me find a mask for 7 level grayscale?
Thanks.  

I saw the topic "Constructive and Creative uses of IX and IY," and I liked the idea of brainstorming creative uses for commands. 

Two commands that always perplex me are RLD and RRD.  I cannot think of many practical uses of them.