Omnimaga
Calculator Community => TI Calculators => Calculator C => Topic started by: SirCmpwn on October 28, 2010, 07:03:20 pm
-
Hello,
How do I access the link port on the Nspire? It's documented here: http://hackspire.unsads.com/wiki/index.php/Memory-mapped_I/O_ports#90100000_-_TI-84_Plus_link_port (http://hackspire.unsads.com/wiki/index.php/Memory-mapped_I/O_ports#90100000_-_TI-84_Plus_link_port), but this doesn't seem to work.
-
*bump*
-
I suppose currently only calc84maniac or Goplat have any knowledge on this.
-
I think even Calc84maniac doesn't, but again, I could be wrong. Maybe you might have more luck with Goplat.
-
I guess it would mean you read/write those memory locations to control the port, like it said. INitilaize a pointer to it, and then modify the value. Haven't tried anything with it, though.
-
Well, at that point, I didn't know how to access the TI-84+ link port through ARM assembly. Now I do, but I no longer have the source code for the TI-83+ emulator.
Now I'm just hoping he notices :P
-
Oh, I thought he kinda moved on from the idea for a while or was still working on it. I knew about his lost source code, though.
-
Calc84maniac and I were chatting last knight about how to fix this, and this is how you do both of our issues:
Access the link port:
To enable the link port, OR the value at 0x900A0000 with 0x20.
To disable, AND the same value with ~0x20.
Change the first two bits of 0x90100000 to reflect the state of the ring and tip, respectively.
Interrupts:
Back up the value at 0x38 first.
Load your own interrupt function into 0x38 by using &functionname to get a pointer to it.
Restore 0x38 upon leaving.
-
Access the link port:
To enable the link port, OR the value at 0x900A0000 with 0x20.
To disable, AND the same value with ~0x20.
Actually, that should be 0x900A0004. That could explain why nothing was happening.
-
That would be a great explanation :P
-
This is to use the I/O link port when in Nspire mode, after swapping the keypads, right? Has anyone gotten any success with the USB?
-
I haven't tried USB, and this is intended to use the I/O port on an 84+ keypad.
okay...
Sounds weird but I'll go with it.
I got sound to work now, it plays a tone, and pressing up and down on the keypad changes the tone.
The following code should play some sort of noise, but it only plays a high pitched tone:
int main(void) {
enableLink();
clearScreen();
FILE* wavFile = fopen("HBFS.wav", "r");
char currentSampleLeft, currentSampleRight;
while (!isKeyPressed(KEY_84_ENTER))
{
}
while (!isKeyPressed(KEY_NSPIRE_ESC) && !isKeyPressed(KEY_84_CLEAR))
{
fread(¤tSampleLeft, 1, 1, wavFile);
fread(¤tSampleRight, 1, 1, wavFile);
int count;
for (count = 0; count <= 0xFF; count++)
{
int value = 0;
if (count < currentSampleLeft)
{
value++;
}
if (count < currentSampleRight)
{
value += 2;
}
KEYPAD_84_IO = value;
}
}
fclose(wavFile);
disableLink();
return 0;
}
void enableLink()
{
MISC_PORTS |= 0x20;
}
void disableLink()
{
MISC_PORTS &= ~0x20;
}Any ideas?
-
Oh wow you're trying to get sound to work? O.o
I hope you can get it figured out. Hopefully someone will be able to help soon.
-
Well, right now what I have is static with the faintest inklings of the occasional tone, so I have a long way to go.
-
Yeah I know. I hope you can eventually manipulate sound and stuff, even if it's just to produce sound like this ;D :
-
I'm confident that much, much better quality is possible, akin to what you'd find on an mp3 player.
-
The sound I got on TI-68k with TI-Vibe (http://www.ticalc.org/archives/files/fileinfo/386/38629.html) was already pretty good, I suppose we could get something even better with the TI-Nspire CPU.
-
Nice I didn't knew about that program. I'll have to try it on my 89T one day
-
12 MHz TI-68k, 90 MHz TI-Nspire... :P
-
Yeah true, and it's possible to set the Nspire to 150 MHz, according to Calc84maniac. Just don't go overboard, though, because it would suck if a Mario game, for example, grew by 8 MB in size just because of sound :P
-
No way, 150 MHz? I want to know how O.O
-
Put this at the beginning of your code:
*(volatile unsigned*) 0x900B0000=0x00000002;
*(volatile unsigned*) 0x900B000C=4;
And at the end, put this to set it back to 90:
*(volatile unsigned*) 0x900B0000=0x00141002;
*(volatile unsigned*) 0x900B000C=4;
-
That's awesome. Want to try.
-
Yup. I am curious how quick this drains battery power, though...
-
I don't know if this is just my Nspire, but, in its life, it as gone through at least 10 Ndless 1.1 installs, countless Ndless 1.7 installs (it fails a lot :(), at least 7-8 hours of usage of gbc4nspire, a lot of hours of use with other Ndless programs, and quite a few hours of usage in school, and I have only had to replace my batteries once. I don't know if that is just my Nspire (as I know they are notorious for draining batteries), but I find that this thing never needs new batteries.
-
Wow. I wonder under which circumstances battery power is really drained fast... maybe it just takes good batteries?
-
We could try to run a program at the 2 frequencies which write regularly its uptime to a file, and see the difference.
-
Put this at the beginning of your code:
*(volatile unsigned*) 0x900B0000=0x00000002;
*(volatile unsigned*) 0x900B000C=4;
And at the end, put this to set it back to 90:
*(volatile unsigned*) 0x900B0000=0x00141002;
*(volatile unsigned*) 0x900B000C=4;
If you neglected to reset the CPU to 90mhz, would the OS still run at 150mhz?