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 ... 8 9 [10] 11 12 ... 20
136
« on: March 29, 2011, 03:49:08 pm »
I'm not sure I see the point in running OSes this way.
It could be nice to be able to run significantly different versions, like have 2.x installed for Ndless but run 3.0 for the additional math features (e.g. 3d graphing), but this doesn't work too well because you get mixed-up text that basically makes everything incomprehensible (see below for an example - 2.1 running on a 2.0.1 installation).
If you want to run your own code, just make it its own Ndless program. No reason to make extra work for yourself by putting it in .tno format.
137
« on: March 28, 2011, 06:40:59 pm »
How does the calculator even detect that code is running in the "illegal" area? The only explanation that I can think of is that the last two bits on the address bus (the ones that must be on if code above C000 is being executed) are wired into a trigger that causes the processor to jump to the boot code. In other words, the detection is in the hardware itself.
Most likely it is. Remember that we are talking about all of this being in the processor. So the processor knows immediately if the pc is C000h or above.
The original TI-83+ just had a stock Z84C00 processor. The detection there must have been done by outside hardware, probably checking the address and the M1 signal (which is active only on instruction fetches).
138
« on: March 28, 2011, 03:24:16 pm »
Goplat, the TouchPad arrows aren't very reactive sometimes...
Could you also test for numeric key presses, letting the user choose the best keys?
It seems pretty responsive on my calc. Make sure you never have two fingers in contact with the pad at the same time: it usually moves in the direction where the first finger that touched the pad is, regardless of which finger is pressing down. Right now the number keys are already used to control the framerate...
139
« on: March 28, 2011, 12:26:48 pm »
I use the 900D0000 timer, which the OS sets to 100Hz (well, actually more like 99.3Hz). Running 3 frames every 5 timer ticks gives a speed close to the NES's 60.1Hz.
I suspect some program is changing the timer speed and not putting it back.
EDIT: Yep, it's gbc4nspire. Use this program to restore the timer speed after running it.
140
« on: March 28, 2011, 02:55:13 am »
It seems to run at the correct speed for me. What OS version are you using? Does the problem still happen if you reboot and don't run any other Ndless programs before running the game?
141
« on: March 26, 2011, 07:07:35 pm »
Here's a harder one: Find natural numbers a, b, and c where a3+b3=c3 
0 3 + 0 3 = 0 3And yes, 0 is a natural number. The standard way to define the natural numbers in modern mathematics is to represent 0 with the empty set, 1 as the set {0}, 2 as the set {0,1}, etc.
142
« on: March 26, 2011, 02:32:25 pm »
Are you completely sure of what policy.dat does? I don't think we should risk the possibility that the OS won't boot without it. This is the only known copy of this OS in the world.
143
« on: March 25, 2011, 06:59:31 pm »
There are actually two solutions (four if you allow a > b), so I'm going to be a smartass and give the unintended one:
144
« on: March 25, 2011, 04:05:34 pm »
As I feared, looks like the command shell code is different (and unlike the later version, the address of RelDclVPrintf doesn't show up in uninitialized space in the TYPE command's stack frame). Without knowing the addresses of any useful functions we can't exploit the buffer overflow safely yet.  We had better wait for another CAS+ OS to be dumped, so we can see the older command shell code, and come back to this then.
145
« on: March 24, 2011, 08:02:26 pm »
I've found a buffer overflow vulnerability in the command shell's printf routine, which could potentially allow executing code by TYPEing a file. We may not be able to exploit it at this time because
- the code may have changed (the CAS+ has Reliance v2.00.0451/FlashFX v2.0, instead of Reliance v2.10.1150/FlashFX v3.00).
- the WRITE command can't create a file with 00, 08, 0A, or 0D bytes in it (this could be insurmountable, or not a problem at all, depending on what the addresses of the relevant functions and stack items turn out to be)
but I think it might be worth a try.
First step is to dump the stack to get some addresses... Try this (in whatever directory you're comfortable creating files in):
write stackdump 192
%8x%8x%8x%8x%8x%8x%8x%8x%8x%8x%8x%8x%8x%8x%8x%8x%8x%8x%8x%8x%8x%8x%8x%8x%8x%8x%8x%8x%8x%8x%8x%8x%8x%8x%8x%8x%8x%8x%8x%8x%8x%8x%8x%8x%8x%8x%8x%8x%8x%8x%8x%8x%8x%8x%8x%8x%8x%8x%8x%8x%8x%8x%8x%8x
type stackdump
146
« on: March 23, 2011, 11:49:52 pm »
The two requirements are enforced in boot2's validation of an OS image. (Actually, the 8010 field requirement is also enforced in boot1's validation of a boot2 image. However, so far every version of boot2 has had two 8010 fields, one for CAS and one for non-CAS, so the possibility of a boot2 that works on only one of them is only theoretical so far.)
147
« on: March 23, 2011, 10:52:54 pm »
Yes, the two are signed with different keys.
Actually, they are signed with the same key. The reason you cannot use a TI-Nspire CAS OS on the TI-Nspire or vice versa is because for an OS to validate: - There must be an 8010 field present which matches the first two characters of the Product ID, which are stored in NAND flash (but don't bother trying to change it, because of the other protection described next)
- The 80E0 field must contain a byte matching a part of the value read from address 0x900A0028/0x900A002C (presumably, this is an 8 byte ROM inside the ASIC and cannot be changed)
Changing these fields in the OS image will mean the signature isn't valid and the OS won't load.
148
« on: March 23, 2011, 04:30:27 pm »
Unfortunately, as someone who enjoys taking things apart to learn how they work, I am still somewhat interested in the CAS+. Does anyone know if the OS is encrypted (on the NAND Flash)? Has anyone tried to directly dump the OS from it? If the CAS+ is anything like the released TI-Nspire/TI-Nspire CAS, then the OS is encrypted but the encryption key is present in the second-stage boot loader, which is merely compressed (and we can easily decompress it). However, I don't think anybody has tried to dump the NAND flash by means of hardware hacking; I didn't know that was even feasible.
149
« on: March 23, 2011, 03:45:39 am »
Just wondering, but how many Hz does the nspire emulator get. My current version of the Prizm emulator achieves about 8MHz now on the average computer (I released the first test version yesterday), but I still have many more optimizations to do including multi threading.
On my computer, it typically runs around 100-200 million instructions per second. It depends heavily on the code being executed - plain arithmetic is fast, branches and memory accesses are slower, accesses to memory-mapped I/O ports are very slow. The main reason it's so fast otherwise is that I translate sequences of ARM instructions into the x86 code needed to emulate them, and execute that directly, so the overhead of figuring out what an instruction does is only incurred the first time it's executed. Without this feature, it's about 10x slower. I have to ask: what hardware does the Prizm have whose emulation can be sped up with multi-threading?
150
« on: March 22, 2011, 11:18:50 pm »
Why not just use .g3a format?
Pages: 1 ... 8 9 [10] 11 12 ... 20
|
Show Posts
