The curly bracket operator {addr} only returns the single byte at the address you want. Each element of the array ("list") is one byte large, so it can store numbers from 0 to 255.

Ah, you want to get the decimal digits out of a number
The modulo operator (^) does exactly that for you. It returns the remainder of a division. Say 27/10 is 2 remainder 7, so 27^10 returns 7. There you have the first digit (units), then you divide the number by ten and do it again for the tenths and so on.
125->M
Pt-On(10,I*6+2,M^10*8+Pic0)   //units
Pt-On(6,I*6+2,M/10->M^10*8+Pic0)  //tenths
Pt-On(2,I*6+2,M/10^10*8+Pic0)  //hundreds
The original value of M is corrupted, you might want to save that before the calculation

Yeah, interrupts are the way to go when you need to measure a time. The slowest setting should be fine for a game, since you don't need it accurate. Inside the Interrupt Service Routine you increment a variable. Since interrupt speed "6" corresponds to 118 Hz on a 83+ or to 108 Hz on a 84+, you divide by 118 or 108 to get the amount of seconds elapsed (or by 12 / 11 for tenths of a second). It is important to put the calc back to normal interrupt mode before exiting, otherwise crashes occur.
... // initializing stuff
fnInt(TMR,6)   //turn on the interrupt
0->T   //say T is our timer variable, reset it when the game starts.
game loop {
...// Stuff
}
T->S  //save the time after the game finished
S/118->S //get the seconds elapsed
...// win display stuff
LnReg  // back to normal interrupt mode, this is important
LnRegr   //repair any damage done by the custom interrupt
Return //Exit


Lbl TMR //the actual interrupt service routine
T++  // increment the counter variable
Return  //it's a subroutine so we return as usual


We don't need to make sure it doesn't overflow if you reset it everytime a nee game starts. Since the counter is incremented 118 a second and can only hold values up to 65535, it can run 555 seconds before it resets, that's about 9 minutes. So if a game takes longer than that, you need to use multiple variables, but I guess that shouldn't be a problem right now


Either way, good luck with your project - I'm looking forward to see it

so... funny enough - two weeks before Kerm posted this - I ordered GPS module from a Chinese ebay shop. Well, after the three weeks of shipping to Europe, I could play around a bit with it and decided to do the same (sort-of) myself.

However, I don't have a 84+ where this works, neither the program nor the USB power supply. Having no idea how Kerm pulled it off to make the serial interface that good, I started from scratch, using my TI-83+ and Axe. I faced several problems though, mostly with syncing the GPS module to the calc to do not miss the start of the protocol on the one hand, and keeping both serial interfaces in sync on the other hand - which turned out to be way more difficult than I expected for such long protocols (just less than a kB for my module). I guess it is easier on a 15 MHz calc where you have fast enough interrupts to handle it. The 500 Hz interrupt just isn't sufficient for a 9600 baud port.

Keep both devices in sync is a different problem. These are four ways I could think of:

• 1. Check the port in the main loop -> Bad for adding further functionality later
• 2. Check the port in an interrupt -> interrupts are also to slow for this (catching the start bit)
• 3. Request data when you need it -> I don't have a datasheet of the module so I don't know if this is possible at all
• 4. Use a hardware asynchronous serial interface with a buffer -> I'm quite sure the TI-83+ does not have such a thing.

Eventually, I used the two latter solutions, inserting an ATtiny2313 in the serial line. It features a hardware serial port and is pretty idle so it can watch it all the time. What I did:

• The AVR listens for any incoming GPS data on the asynchronous port and buffers the RMC string -> The data is stored so it can be called at any time
• At any time, the calc can pull the signal lines low to request the buffered data -> The calc knows where the packet starts
• The AVR transmits the RMC string using a synchronous (that means using two lines - clock and data - instead of one) interface -> save transmission
• The calc only manipulates the ASCII string and displays it -> it has plenty of time to do other stuff

Furthermore, I used a Nokia battery to power it (you probably know that one - I use it in plenty of my projects). That is in a manner useful since the module draws with ~80 mA at 3.7 V quite a lot of power and would suck the calc batteries empty in no time - having it to be rechargeable is a nice feature I guess.

Some drawbacks I will fix later:

• The AVR has only 128 bytes (!) of RAM, so it can only buffer the RMC string, not other information (such as altitude or # of satellites)
• The code is pretty messy at the moment - I'm too ashamed to upload it

The direction data only works when the ground speed is high enough.

Wow that looks indeed pretty fancy awesome!

Attack/Decay/Sustain/Release (short ADSR) are parameters defining the envelope curve of a note. Every basic synthesizer has 4 pots - one for each value.
Attack is the time the tone needs to go to full amplitude. Decay is the time the amplitude drops to a certain Sustain level, where the note rests until it is being released. After the note is released, the Release time specifies how long the tone needs to fade away.

This diagram (from Wikipedia) illustrates that quite nicely:

That sounds awesome! Great job Keoni

Did you mean x . 2^n-1 ?

No, I meant x . 2ⁿ-1

Hook chaining is done by calling the already existing hook within your own hook, I guess. Remember to put the right value in A though.

Seems doable, so you have to somehow get the address of the other existing hook and then call it.

Quote

Haha... Well... to be honest that was my initial intention which lead me to explore this whole thing....
Not just blocking it, but rather open up a menu that looks and behaves visually the same but doesn't do anything... ehhhrmmm I better stop talking now... 

That is pretty cool, good luck with that!

Actually that seems to be more than scratching the edge of legality in schools... "attempt to deceive" is what it's called when it gets busted.

I'm already doing some cool stuff with that code. I made it so that whenever enter is pressed it displayes "do it yourself". This is so going on my friends calculator

Nice!
Actually there might be another (maybe more convenient) way to achieve this: The hoomscreen hook. It is run when one of the following things happen, what happened is specified by the register A so you can check that in your routine:

• A = 0: Displaying a result - hack here to change the result. It is stored in OP1. When the Zeroflag is reset on return, then nothing is displayed.
• A = 1: Key press - keycode is in B, you can change that here. When the Zeroflag is reset on return, then the key press is ignored.
• A = 2: Expression is entered. When the Zeroflag is reset on return, the operation is cancelled.
• A = 3: Edit/changing context -last context value is in B. Return with zeroflag set!

Source

Interesting is A = 0. We can actually recycle almost the whole code from before, except the bcalls and "cp a"


; address in HL
 in a,(6)   ; current rom page
 _bcall(_EnableHomescreenHook)
 _bjump(_JForceCmdNoChar) ; Quit


 ;Hook itself:
 add a,e  ; 0x83 required to be identified as legal routine
 push HL
 push BC
 push DE
 push AF

 ld l,a     ; load a to l to make it usable in axe
 ld h,00

 ; function goes here

 pop AF   ; restore the registers we might have messed up
 pop DE
 pop BC
 pop HL
 cp a    ; set zeroflag



Disable:
 _bcall(_ClrHomescreenHook)


:LHOOK
:Asm(DB06EFAB4F)
:Asm(CD50002740)
:
:Lbl Hook
:Asm(83E5C5D5F56F2600)
:!If ->A
://Do some crazy stuff like _bcall(_Random) store some random stuff in OP1:
:Asm(EF794B)
://Disable the hook:
:Asm(EFAE4F)
:End
://restore and cp a
:Asm(F1D1C1E1BF)   //note the BF, otherwise things get messed up badly
:Return

Hope that helps