I have a question for Goplat: how difficult would nspire_emu be to port, especially to Android? I might do that if the project is feasible.

Porting to another x86 OS like Linux or Mac OS X would require rewriting the GUI, and replacing some of the funky memory management code (I think I do have an unreleased Linux port of the memory code somewhere, but I never ported the GUI)

Since Android runs on ARM instead of x86, porting to Android would also require rewriting all the x86-specific code (asmcode.s, translate.c, and anywhere where I may have used inline assembly). I don't think the fact that it's an ARM CPU being emulated would help much, unfortunately.

OK, it appears that keeping these features in beta has caused some drama (just so people know: the only real reasons behind the lack of public release are fear that I might have accidentally broken something, combined with a big dose of procrastination), so here's a new release.

• merged some debugging features from ExtendeD's Ncubate (most notably the "gdb stub" which allows attaching an external debugger) - thanks ldebroux
• fixed two-operand ADD instruction in thumb mode (should not change flags)
• implement correct behavior of unaligned memory access and jumps
• implement CAS+ emulation (just enough to get the OS to boot, so I could test dumpers before sending them to critor... this wasn't really intended as a public feature, but someone on the mailing list wanted to see it and now that word has gotten out I can't really remove it now :p)
• implemented sending files via XMODEM (mainly for CAS+ prototype OSes (1.0.3xx/4xx) - each one needs a different header so /PO= won't cut it - but works for any model)

That solution seems rather ambiguous. I prefer "Where would the other bird tell me to go?" (and go the opposite way)

No, the fishbowl effect is not natural. A straight line in 3D space should always be a straight line in a 2D perspective projection - look at a photograph of a building for example.

Fishbowl is caused by computing the ray vectors the wrong way. Right now you've got rays evenly spaced by angle, like the left side of the diagram below. There are two problems with this. The first, which has already been mentioned, is the since the rays are all the same length, the rays at more extreme angles take longer to get to the wall. The more subtle problem is that the rays don't hit the wall at evenly spaced points; the rays on the left and right sides hit the wall further apart than the rays in the center.

The right way to do raycasting is to imagine the game window as a literal window into your world: you want to make the player see what the in-game camera sees. Monitors are flat, not curved; as such the columns on the player's monitor are spaced a constant linear distance apart, not a constant angle apart, and the rays should be computed accordingly, like the right side of the diagram. (Edit: A simple way to compute each ray is to add the camera direction to a multiple of its perpendicular. Ranging the multiplier from -0.5 to +0.5 will produce a 60-degree field of view.)

This program actually has another problem: distance isn't translated to line height properly. The perceived height should be inversely proportional to the distance, i.e. a constant divided by the number of ray iterations, not subtracted.

nspire_emu.exe /1=boot1.img.tns /MXC /PO=os_cxcas.tcc

You also need to preload the boot2 (/PB=boot2.img.tns).

However, I found multiple occurences of code calling stuff with ip directly in the long format, and not the "normal" format, so I guess that's again de-compilation "mistakes" ?

Not a mistake - the actual TI_PN_fm_xfer function (10342018) is called with an integer representing the IP address as its first argument. The port-10002 shell just does not use exact C syntax in all cases - in this case it wants the IP address in dotted quad notation instead of a plain number.

TI-nspire computer Link 1.0 is using port 10001 to transfer tns files to and from the CAS+ documents folder.

But we've just discovered a 2nd shell on port 10002, which seems to be able to access the whole filesystem.

And this time, it's working on all CAS+. here is an example with a CAS+ running OS 1.0.529:

Code: [Select]

size("C:\phoenix/install/phoenix.img")
-> 5067229
But as you can see, the syntax is strange.
Could someone help us figuring the commands list and their syntax?

From what I can tell looking at the EVT2 OS, I think the fm_xfer command (syntax: fm_xfer(IP address, operation, destination filename, source filename, callback frequency, callback enabled, options)) initiates a file transfer (connecting to the IP address on port 10001 and requesting or sending a file). Maybe it could be possible to make it connect to the calc's own link handler with something like

fm_xfer(127.0.0.1, pn_fm_fput, "/phx/documents/ndless/phoenix.tns", "/phoenix/install/phoenix.img", 5000, 1, 0)

Or alternatively, maybe it would be possible to run a program on the PC to listen on that port for link commands and have it send the file to that.

The TI-Nspire CAS+ P1-EVT2 has a different boot screen than later Nspire: So it probably has different Boot2 and Diags flashing screens too.

I hope you're making sure there is no diags present before testing the diags reflashing combination, as it immediately erases diags before receiving any data (unlike the boot2 reflashing combination, which doesn't erase until the transfer is completed)