This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.
Messages - Goplat
Pages: 1 ... 10 11 [12] 13 14 ... 20
166
« on: March 19, 2011, 01:28:35 am »
First of all, this kind of code effectively byte-swaps the integer twice: int temp = int(memory[r_pointer]) * 0x1000000;
temp |= int(memory[r_pointer + 1]) * 0x10000;
temp |= int(memory[r_pointer + 2]) * 0x100;
temp |= int(memory[r_pointer + 3]);
return ntohl(temp);
If you read the integer byte-by-byte, with the multipliers being for big-endian, then it's already correct and you don't need to use ntohl. If you want to read the integer all at once, use a pointer cast: *(int *)&memory[r_pointer]. If you do this, then the integer will have its bytes in the wrong order (because x86 is little-endian), and then you would need something like ntohl to fix it: ntohl(*(int *)&memory[r_pointer]). As for your input loop: There are a couple of problems. First, prog_index needs to be initialized to some value (I assume you intended 0) - otherwise, you could be writing anywhere. Second, if the input file is in hex, then you need to parse the hex numbers. istream.read() just reads raw bytes, so if the file contains 70 01... then buffer will take on values of 0x37, 0x30, 0x20, 0x30, 0x31... In C++, you can instead use the >> operator. You'll have to set the stream to hex mode first though. You will also have to change buffer to be an int, not a char, because >> determines what to do based on the type of the variable on the right: if the variable is a char, >> just reads a character; if the variable is an int, >> reads a space-delimited number. Corrected input loop: program >> hex;
int buffer;
program >> buffer;
int prog_index = 0;
while(program.good())
{
writememory_byte(prog_index + 0xA4000000, buffer);
prog_index++;
program >> buffer;
}
167
« on: March 18, 2011, 04:28:30 pm »
I've tried to force 172.16.80.29 as an IP address.
TI-Nspire Computer Link 1.0 doesn't find any calculator, but is taking more time looking for them... What if you put in the IP address that appears in the rs232 log after "dhcp-ans"? Edit: Byte order: Big Endian
More evidence of the CAS+ hardware being different from the TI-Nspire and TI-Nspire CAS (which are little-endian)...
168
« on: March 17, 2011, 09:46:33 pm »
I just checked out the type command in the current boot2 - it reads 1023 bytes at at a time, and prints using printf, so if the file has any 00 bytes it'll lose data.  ! Stupid Datalight programmers. They didn't even do printf("%s", buffer), they did printf(buffer), so if there are %s's in the file it'll likely crash (this is not exploitable, unfortunately).
169
« on: March 17, 2011, 09:10:32 pm »
Actually, this is a command shell bug that shows up even on the production TI-Nspire - directories appear empty even when they're not.
Anyway, check if you can use the TYPE command to dump a file.
170
« on: March 17, 2011, 09:03:42 pm »
Looks promising, at least! You can type "?" or "help" for a list of commands. Maybe the current directory name has gotten corrupted (explaining the weird prompt), so try "cd A:\" to fix that.
171
« on: March 17, 2011, 08:39:29 pm »
Does the really old one allow you to enter commands into the command shell via RS232? It would be so awesome if it let you dump that OS to RS232 with "TYPE /phoenix/install/TI-Nspire.tnc" (or wherever it's located on the CAS+... some exploration using the DIR command might be necessary)
172
« on: March 17, 2011, 03:13:25 pm »
I really think the BOOT2 will not work, especially considering this "OMAP5912" business. The hardware is compmletely different between OMAPs and the Zevio... (and TI-Nspire CAS+ probably is an OMAP - I found an unused function in boot1 that appears to be left over from OMAP)
173
« on: March 17, 2011, 12:41:36 pm »
try: y=piecewise(2.5x,x>10,5x,x<=10
174
« on: March 16, 2011, 11:00:26 pm »
Jeorg posted a follow-up about the screen: I use an ordinary flatbed scanner for all my images in the Datamath Calculator Museum. Works perfect with traditional calculator displays but failed completely with the new backlit displays.
I shot this afternoon some pictures with a Digital Still Camera and put them on the web. They are not that crisp but show the colors of the screen much better. Just load www.datamath.org and follow the link in the headline. I think the new photos at Datamath should lay to rest any fears about the backlight being ineffective. 
175
« on: March 16, 2011, 01:51:21 pm »
Joerg said the screen looks much better in person: The first pictures of the CX looked nice, but holding this cutie in your own hands is something different. It is sleek, it looks and feels just perfect and both the screen and keyboards are outstanding. Believe it or not - the keys click exactly how we liked it about 35 years ago. Not too much travel, not to hard, simply perfect. Even the plastic material used for the keys, not too mushy, not too soft, not too hard. Feels like a good old SR-51! And the screen? I can't scan it right with my equipment - just believe me. You never saw a calculator screen that crisp and bright. Or was the post sarcastic? 
176
« on: March 15, 2011, 04:58:57 pm »
Did you really have to use the ABCDEF keyboard layout, TI? Really?
Yes they did, otherwise it would be prohibited on the SAT: Unacceptable calculators
You are not allowed to use any of the following items as a calculator:
* Laptop or a portable/handheld computer
* Calculator that has QWERTY (keyboard-like) keypad, uses an electrical outlet, makes noise or has a paper tape
* Electronic writing pad or pen-input/stylus-driven device
* Pocket organizer
* Cell phone calculator
177
« on: March 15, 2011, 04:55:08 pm »
If the switch was made to fat, would there be less fs overhead and more space for files?
Maybe. I don't know how much overhead is due to the FlashFX wear-leveling system and how much is due to the Reliance filesystem. Anyway, the FAT filesystem kind of sucks because it can't be implemented in a way that avoids getting it corrupted in the event of a crash. A simplified example: To create a file, you have to both write a directory entry for it that tells what the file's first cluster is, and write to the File Allocation Table to mark the clusters as used. If the OS crashes after you write the directory entry but before you write to the FAT, now the file exists but is located in space marked as free, so if that space ever gets allocated for a different file, the old file is corrupted. It's better to write to the FAT first, but then if the OS crashes you've got clusters marked as used that aren't really used (this is why in the DOS/Win9x days, free space would diminish over time and you had to run 'scandisk' to recover it). Modern filesystems - such as Windows NTFS, Linux ext3, and presumably Datalight Reliance - have their data structures set up so that if the OS crashes in the middle of an operation, it's possible to detect the partially-finished operation and "roll back" to the previous valid state.
178
« on: March 15, 2011, 02:44:01 pm »
Also I wonder if the new CX will support mass storage device mode for transfer? This is something that would be implemented in software, not in hardware, so the real question is if the new OS 3.0 will support it. I'd say unlikely: 1) they would have to switch from their currently used Datalight Reliance filesystem, to something that PC operating systems can recognize (i.e. FAT) - so anyone upgrading their calculator to the new OS would lose all their documents. 2) TI probably doesn't want us able to easily mess around with stuff outside /documents (remember how Ndless 1.1 worked?)
179
« on: March 15, 2011, 01:12:28 pm »
It's silly to celebrate 3/14 just because the ratio of a circle's circumference to diameter is '3.14...'. A circle is most naturally defined by its radius, not its diameter ((x - x 0) 2 + (y - y 0) 2 = r 2), so we should really be celebrating 6/28.
180
« on: March 15, 2011, 11:30:28 am »
I think ARM is supposed to handle frequency changes well. I do know that the OS frequently clocks the processor down while idle, then clocks it back up when it needs to do something.
It only changes the processor speed, though, keeping the bus speed constant. OS 1.1-2.01: 145002 when active (CPU=90MHz AHB=15MHz), 14000c when idle (CPU=15MHz AHB=15MHz) OS 2.1: 0a1002 when active (CPU=120MHz AHB=60MHz), 0a0004 when idle (CPU=60MHz AHB=60MHz)
Pages: 1 ... 10 11 [12] 13 14 ... 20
|
Show Posts