Question, what version of computer software do you have and what OS version does your calc run on? For example, from OS 3.0.2 to 3.1.0 some Lua functions stopped working and new ones got added. I do not know which ones, though.

They were both on 3.0.2, until I updated the computer software to 3.1.0 to see if something changed.

Also welcome here. This game also looks nice so far too.

Thank you.

Well then, your problem is that the leve1 table simply doesn't have what you're looking for in it.
So display the answer of the expression you're using (y * levelsize+x+1) and see if that looks wrong.
That value is simply not in the table, because the compare value is nil.

I'll try this out later.

- Don't use platform.gc(): as your standard GC context (only use the on passed in the on.paint(gc) event).
- Make sure you refresh the drawing buffer often enough. That might be the real problem of yours, here. Actually, the software refreshes constantly, contrary to the device, which refreshes only when needed or when it's asked. So make sure that when you want to draw something and update the screen consequently, call platform.window:invalidate().

I only use platform.gc() in functions that are called only during on.paint, though I use platform.gc() most of all because I've split my drawing functions into groups. I also refresh my screen every 0.1 seconds, and I believe that this should be enough.
Really, I believe that the first problem is caused by the second. It's like the table is totally gone after the level init function, and I have no idea why.
There's no color issues between platforms either; I forgot to mention that I develop this on for a CX with the CX student software. So if anything there'll be issues on a regular nspire which I'll have to solve later.
Here's some code where I think there are problems, with some comments.

startLevel
function startLevel(num, keepkeys, startx, starty) --Pass this function a level number, and it'll warp the player.
if layer0[num]==nil then --If the level doesn't exist, the player must have won.
pause=1 --However, I have no screen for this yet, so for now it
else --just pauses.
if keepkeys == 0 then --If I somehow want to start the level with keys from the
keys = {0, 0, 0, 0} --previous.
end
if startx > 0 then --Assuming that if you specify one starting coord, both are used.
playerx = startx
playery = starty
else
playerx = startpos[num][1] --If none specified, get them from a table.
playery = startpos[num][2]
end
levelsize = math.sqrt(#layer0[num]) --This works because levels are completely square.
local area = (levelsize*levelsize)
level1 = {} --Table where the first level layer will be contained.
level2 = {} --Table where the second level layer will be contained.
for i=1, area do
level1[i] = layer0[num][i] --Function that copies the original level data
level2[i] = layer1[num][i] --to the two layers for gameplay. Possible point
end --of interest.
backgroundcolor = {mapcolor[num][1],mapcolor[num][2],mapcolor[num][3]} --Each level can have a unique background color.
levelnum = num --
maxbluekeys = 0
for i=1, area do --Scans the level for blue key fragments and
if level2[i] == 6 then --totals them because all must be collected
maxbluekeys = maxbluekeys + 1 --to create a blue key.
end
end
camerax = 0
cameray = 0 --Reset the camera position
fixCamera() --and move it to the player.
end
end
collisionCheck
function collisionCheck(x, y)
local compare = level1[(y*levelsize)+(x+1)] --Object ID of this position in layer 1. <  What is said to be "nil" when game crashes
if compare > 0 then --If it's above 0, it's a flavor of normal solid block.
return true --Returning true says "Yes, there will be a collision."
elseif compare == 0 then --If nothing's there,
return false --there's no collision.
elseif compare == -1 then
if keys[1] > 0 then --Here is where we have negative block IDs,
keys[1] = keys[1]-1 --where blocks determine their solidity
level1[(y*levelsize)+(x+1)] = 0 --based on logic.
return true --This is a yellow key door.
else
return true
end
elseif compare == -2 then --Red key door.
if keys[2] > 0 then
keys[2] = keys[2]-1
level1[(y*levelsize)+(x+1)] = 0
return true
else
return true
end
elseif compare == -3 then --Green key door. Green keys last until level end.
if keys[3] > 0 then
level1[(y*levelsize)+(x+1)] = 0
return true
else
return true
end
elseif compare == -4 then --Blue key door. Found in pieces that can
if keys[4] > maxbluekeys-1 then --be put together, and will last until the
level1[(y*levelsize)+(x+1)] = 0 --end of the level.
return true
else
return true
end
else --If nothing else, assume it's false for no reason.
return false
end
end
EDIT: I disabled collision detection by always evaluating compare as "0". If I move around to the left side of the level, I can get some garbage tiles (tiles that don't draw in the right place) to draw in one row, and they disappear when I leave that row. This mystifies me.
Here's a screenshot of what it looks like when it's working on the PC:

Here's a picture of the odd occurence I just described on the calculator:

The red key value is actually a measure of the area of the level because I hacked up the drawing function for it to debug. The value on the calculator is actually one less than on the PC.