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 ... 13 14 [15] 16 17 ... 20
211
« on: February 24, 2011, 03:11:50 pm »
Don't use __builtin_vsprintf, that would end up trying to call an actual function called vsprintf (rather than the syscall). It looks like yagarto's gcc is annoyingly strict about how you can use a __builtin_va_list, but this still works:
vsprintf(buf,format,*(char **)&arglist);
212
« on: February 24, 2011, 02:47:20 pm »
Ndless's definition of va_start is not quite correct, it doesn't take into account that a 1-byte function parameter actually takes up 4 bytes on the stack.
For the time being, try using the gcc intrinsic __builtin_va_start instead.
213
« on: February 21, 2011, 12:33:59 am »
I like the chess game from Windows Entertainment Pack. It has a couple of very, um, creative ways of avoiding a loss:
Method 1: Cause a General Protection Fault.
Method 2: Just arbitrarily remove your opponent's pieces from the board, or switch them for a piece of your own color! In this game, I used to have a queen and rook (as you can see from the move list), but apparently my rook has gone AWOL (along with my king) and my queen has turned traitor.
214
« on: February 19, 2011, 10:41:38 pm »
TI probably just bought a color-compatible version of the OS from Nucleus Actually, Nucleus has nothing to do with anything that draws graphics on the TI-Nspire.
215
« on: February 19, 2011, 04:05:05 pm »
I notice that wiki claims that 0x0290-0x058F is garbage, but it's actually a small (64x24) black-and-white icon.
216
« on: February 18, 2011, 11:43:15 pm »
Casio and TI are teaming up to create a new graphing calc, with the most limited programming capabilities to date. It's going to be called the PrizN. Advertising will largely be targeted at educational institutions and will feature the slogan "Kids can't handle too much freedom. This semester, send them to a PrizN."
217
« on: February 18, 2011, 07:13:37 pm »
else if ( iSyscall == 0x1161 ) name = "MB_IsLead";
else if ( iSyscall == 0x1163 ) name = "MB_ElementCount";
else if ( iSyscall == 0x1164 ) name = "MB_ByteCount";
else if ( iSyscall == 0x1166 ) name = "MB_strcat";
else if ( iSyscall == 0x1167 ) name = "MB_strncat";
else if ( iSyscall == 0x1168 ) name = "MB_strcpy";
else if ( iSyscall == 0x116C ) name = "MB_GetSecondElemPtr";
else if ( iSyscall == 0x116D ) name = "MB_GetElement";
else if ( iSyscall == 0x116E ) name = "memcmp";
else if ( iSyscall == 0x116F ) name = "Disp_strcpy";
else if ( iSyscall == 0x1171 ) name = "char_to_upper";
else if ( iSyscall == 0x1172 ) name = "char_to_lower";
...
else if ( iSyscall == 0x1dd0 ) name = "memcpy";
else if ( iSyscall == 0x1dd1 ) name = "memcmp";
Are you sure the first one isn't some kind of strcmp? :p
218
« on: February 15, 2011, 02:46:37 am »
The importance with threads is that many parts of the Prizm run in parrellel(mainly the lcd, but also stuff like the serial port and clock) That's no reason to sacrifice determinism. You have no control over how Java schedules threads, so there is no way to have a separate thread do something every 10000 clock cycles or whatever. Thus, you cannot make the hardware's emulated timing even close to accurate. The usual way to write an emulator is to basically do your own scheduling, based on emulated time. Maintain a data structure that keeps track of what event is going to happen at what time - and dispatch an event when sufficiently many CPU cycles have been emulated. Here's a sketch of one possible way (not necessarily the best, just a way) to implement that: void mainloop() {
while (true) {
// Handle any hardware events that need to be done now
for (HWEvent ev : allHWEvents)
if (ev.time < curTime)
ev.doIt();
normalizeSchedule();
// Handle CPU
while (curTime < 0) {
int instruction = readWord(pc);
pc += 2;
// ...execute instruction and increase curTime appropriately...
}
}
}
// Adjust times so that the next the next event that will happen is at time 0
void normalizeSchedule() {
int next = Integer.MAX_VALUE;
for (HWEvent ev : allHWEvents)
if (ev.time < next)
next = ev.time;
for (HWEvent ev : allHWEvents)
ev.time -= next;
curTime -= next;
}
219
« on: February 14, 2011, 05:20:34 pm »
Two because my idea was to make each of the hardware devices its own thread so they can operate simultaneously. What hardware does the Prizm have that does a lot of computation, other than the CPU? It's probably OK to use a separate thread for graphics/GUI, but I would advise against using threads for anything that can affect the operation of the CPU (either by interrupting it or by writing to memory). That opens up a veritable Pandora's box of potentially extremely hard to find bugs, because you can no longer rely on two runs of the emulator giving the same result - you are likely to have bugs that only show up one out of 1000 times, or bugs that disappear whenever you add debugging statements (printing debug messages affects timing!), and so on.
220
« on: February 13, 2011, 04:41:11 pm »
The TI-80 is not fully dumped yet (let's say 97%), but the missing bytes are very hard to get.
Anyway, it is using a 16-bits proprietary cpu from Toshiba (T6M53A).
I thought you dumped the 8000-FFFF but were missing 0000-3FFF, so that's 32kB out of 48kB or 67%. How did you get another 30%?
221
« on: February 04, 2011, 07:05:51 pm »
It might be possible to use the exploit to patch boot2 in RAM and force it to accept a production OS. Much safer than trying to change boot1/boot2 in flash.
222
« on: February 04, 2011, 02:02:57 pm »
These are some of the files that are placed in Temp by the OS installer. The eActivities aren't interesting, but OSupdateDLL.dll might be...
I took a look at OSupdateDLL.dll. It contains two resources (type RCDATA, id 3063 and 3064) that are probably the compressed OS. It's the Microsoft LZ compression format, except most of the header isn't there, and just to be annoying they removed the single byte at offset 0x3000  Anyway, here's a program to extract both of them:
223
« on: February 04, 2011, 01:06:41 pm »
I e-mailed you the details.
224
« on: February 04, 2011, 12:59:08 am »
I recently found a boot code exploit that might be usable. No guarantee that it'll work on this older version, but it might... Are you interested?
225
« on: January 18, 2011, 04:20:08 pm »
Hello,
I've working on a portable cldc JVM for some months now, part time of course.
Thanks to goplat, it will support jazelle on the nspire, now I know how to do that thanks to him. This was a known unknown, and now its a known known (sorry  ).
I have no release date since it's a big project and I'm busy, but I will let you know my progress here.
FYI, I can load classes from memory or file. When classes are in memory, I will be able to do XIP, ie, classes will not use more RAM if they're available from flash. The goal is to support the TI68K platform.
There is no JAR support for the moment, that's useless. I may add it in the future.
I'm working on threads, which means the stack and bytecode execution is not far away.
Are you porting an existing VM or writing one from scratch? BTW, there's a bit more to using Jazelle than what I used in the little demo program. I'll post what I know on Hackspire soon.
Pages: 1 ... 13 14 [15] 16 17 ... 20
|
Show Posts