This post is an exploration of the 30-pin connector that connects the swappable keypads to the Nspire.
The connector has 30 pins, and the pcb on the pads conveniently told me which was 1 and which was 30 so I can be confident about the numbering scheme.
I figured I'd start a topic to keep track of my findings in, so I don't lose any notes.
Spoiler For pinout so far:
Spoiler For 84+ pad in OS 1.4 non-cas:
Unless otherwise noted, this is with the calc ON in 84+ mode. OS 1.4 atm. Also, I'll be referencing keys based on the BASIC 84+ getkey codes. so 101 is ON, 15 is graph, etc
1 - Ground 2 - Held High (Could be GPIO, could be Vcc, could be a fixed signal pin) 3 - Held High, turns to square wave when you press and hold any 10* key EXCEPT On (?) as well as down and Graph 4 - some form of square wave (my scope is crap, so I can't tell much. It can't actually sync to the wave. It IS a tube-based one, so I'm not surprised) 5 - Held High, turns to square wave when you press and hold any 9* key as well as left and trace 6 - Square Wave 7 - Held High turns to square wave when you press and hold any 8* key as well as right, zoom 8 - Square Wave 9 - Held High turns to square wave when you press and hold any 7* key as well as up, window 10 - Square Wave 11 - Held High turns to square wave when you press and hold any 6* key 12 - Square Wave 13 - Held High, turns to square wave when you press and hold any 5* key 14 - Square Wave 15 - Held High, turns to square wave when you press and hold any 4* key 16 - Square Wave 17 - Held High, turns to square wave when you press and hold Alpha, X-Var, Stat or Del 18 - Square Wave 19 - Held High 20 - Held High 21 - Held Low 22 - Held Low 23 - Held High, Link port wire 24 - Square Wave 25 - Held High, Link port wire 26 - Held High 27 - Held Low 28 - Held Low 29 - Held Low 30 - Held Low
Observations: All Square waves change to Solid ON when the calc is in Standby.
The key layout for the pins is identical to the way they are layed out in memory, so bonus! That also means it'll be easier to get I/O Going.
since the key layout is the same, that means there are 3 bytes of input completely available for use, asssuming they aren't already used for that for the link port.
Thoughts so far: 3-17 are the pins for detecting the majority of the keys, at least for the rows. I bet 19, 21 and 23 do the same, but since the 84+ doesn't use them they are unresponsive to any testing, and wouldn't show the square waves either.
Spoiler For 84+ Pad in 2.0 CAS (results in normal boot):
I have a CAS and I modified the pad so it can fit, so this should closely replicate a touchpad, minus the touch module.
Spoiler For WARNING: Huge Pics of the connector I made:
and for the commands I simply draw to those instead of L3 and L6.
However, once it's finished updating, I need a way to dump FB into L6 (that's front, right?) and BB into L3.
The only way I can figure to do it is BB->DispGraph:StoreGDB:StorePic (BB->screen->L6->L3) and then FB->Dispgraph:StoreGDB but that's two whole frames of semi-garbage I don't want. Any help?
And, it's not conway's, it has 4 cell states so I need the greyscale.
Edit: BTW, BB->L6 gives a bad symbol error, and it would only do the first byte anyways, right?
Each OS, if I'm not mistaken, has its own include file, but there are also some that do not. Is there a list of libraries that can be used on any calc, CAS or nonCAS, OS 1.1 or 2.1?
If I could find this out, I don't need to set up a 1.4 dev environment 2.0 sets up much easier, but 1.4's 84+ emu, which I use heavily, is much more stable (and doesn't use MathPrint )
How hard would it be to implement the font switching of correlation in an Axe prog? I think you could do it thru BASIC, have a BASIC prog run correlation's font switch, then have the axe prog run, but that assumes Axe uses the TIOS text writing routines. The reason I ask is because it's an easy way to get smaller sprites than 8x8, like 6x8 or 4x6 (small text) it also assumes axe doesn't overwrite anything correlation uses.
Also, would it be eligible for the contest? If not, I guess I could use my own routine.
On that note, are axioms disallowed from the contest?
from what I can see, we make up a community of programmers that work on our own personal projects, with the occasional helping hand from each other. Other than that, we essentially show off our end results to everyone else, and work mostly alone.
Nothing wrong with that
However, what if we all had one HUGE project that we all worked together on? It would be something that would be fairly unfeasible for only one person, but should reach the capabilities of most everyone. It should interest everyone, so I'm not going to suggest a project, I'm sure you won't have any trouble with that.
What do you think? I think it would be cool.
Spoiler For to avoid too many tl;drs:
One thing we would need: Multiple files. You can't work as a group on a program based on one code file. We should have many, many of them.
Another thing we'd need, but this is more opinion, is some organization: Newcomers to the project would be assigned a file, but their changes, for a while, would be checked and submitted by someone else, before they got added to the official archives. More experienced people would get direct archive access to at least their own stuff, maybe everything, depending on the setup.
Here's some suggestions, but feel free to ignore all of them if you wish.
A sweet RPG with awesome graphics, gameplay, and storyline, with 50+ hours of playtime, and a lot of side quests
An Axe IDE for the calc with a built in parser, and the official code documentation, and various goodies, like pics of 8x8 sprites instead of their hex.
A hardware driver that makes the calc communicate with other calcs, like, say, Prizm to 84+ to nspire
I'm not 100% sure it doesn't clear archive on some OSes, but it only gives RAM clears on OS 1.4 and I think OS 1.7.
When your calc crashes in an infinite loop, pull out the keypad, and insert it like the CAS/touch ndless 1>1 method used to do. Turn on the calc, and remove a battery while it's on. I personally guarantee it won't be in the loop anymore, but it might still clear your archive on some OSes, I think 2.0 does. Still, it's a handy way to not lose a big project!
As part of a project I'm presenting at a science fair, I made a 16x16 LED array in software (hardware comes next year) and I was hoping for some pics to show off on it. There are 0 specifications, except 16x16 and 4 level gray. Well, 4 lvl red is how it will show up
Anything works. The cooler looking the better
Edit: Posted a pic of what the screen, and the three colors, look like.
The 8000-byte limit in asm-based prgs is a pain, and the only way I've heard so far to get around it is to make an app. However, there are certain things you can't do inside of apps. An easy way to make a program that gets around this would be basic + a hex code to allow Archiving/Unarchiving, but the cool way would be to have your program run inside of another asm program, that copies the code to and from, say, an appvar, as you run it.
Example: asm(prgmGAME [Begin Pseudocode] Copy 1-8000 bytes AppvGAME To an asm PRGM Run asm prgm (AsmPrgm throws an interrupt back at line 7999) Copy lines 7999~15999 over 1-8000 repeat until return statement, when it quits
This would theoretically allow for 1.5 MB apps outside of Apps, just archived, variable size, read/write, anything you want. Of course, the BASIC one is much easier but you can't share variables across the prgms unless you copy them to TIOS, which would be slower than just using one asm brick.
I had a thought: 32 MB is not very much storage space. however, the nspire does have an SD slot. What if we made an ndless prgm that loaded a linux image off of the sd card, as the OS, that used all of the nspire's Ram as jst that: RAM, not storage.
Basically, I need to make a program that takes a word and a 4 digit argument, and turns it into a 6 digit argument with the first two digits corresponding to the word. Ideally this would occur in 2 txt files, reading from one and writing to another.
Example (not definite #s) If 0103 would be 210103
One way I was thinking was python, since it has the so very lovely dictionaries. However, I'm not so good at python, and it's pretty much a choice between that, C, and maybe C++. No .net (sorry sir ) since I am on linux and mono is being a pain.
BTW this is for a processor I'm making, so don't expect to recognize anything.
Show Posts
2.0 sets up much easier, but 1.4's 84+ emu, which I use heavily, is much more stable (and doesn't use MathPrint 
If not, I guess I could use my own routine.
Still, it's a handy way to not lose a big project!