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 - DrDnar
Pages: 1 ... 17 18 [19] 20 21 ... 38
271
« on: October 09, 2012, 01:11:02 am »
Not sure running as admin is enough to give write permission.
I'm not sure if this is relevant, but in Windows Vista and above, programs run from an administrator account don't get administrator privileges by default. You need to use the Run as Administrator function. Or, use Run as Administrator to launch a command prompt, and then start the program from the elevated command prompt. Programs that always need Administrator privileges can use metadata in their header to request elevation whenever the user tries to run it; you can also request elevation via an API call. I just reuploaded the (working for me) jar file in a zip file. Sorry.
You know, jar files <i>are</i> Zip files. Seriously. Rename a .jar to .zip in Windows and you can extract the contents. It's how I got TI's official SVG mockups of several of their calculators---they were included in a JAR file. Silverlight xap files are also Zips. Resource hacking is fun! Referencing this and this, (linked from this  ) each calculator thing costs $40 
...and then the access point costs ~1200 
Cool, one of those stores is 20 minutes from my house. And they have much-less-horribly-expensive CR2032s.
272
« on: October 09, 2012, 12:24:58 am »
I understand, is there a way for the calculator to do it very fast with no limits?
not using the graph, just a formula to find each very fast
If there was, they'd teach it to you in school. Slow, numeric methods and symbolic calculus methods are the only ways of doing it. The symbolic calculus functionality you're looking for is called a CAS (Computer Algebraic System), and it's why you're probably not allowed to use a TI-89 or Nspire-CAS.
273
« on: October 09, 2012, 12:17:32 am »
Here's what happens, Mario uses the old naive fastcopy, this means that on calcs with bad screens, it's going to be garbled unless you use ALCDFIX. Now, what usually happens when you send commands too fast is that the LCD driver just can't keep up and doesn't perform all of them which is what causes the garbling.
That's what usually happens. But on rare occasion, the LCD driver will instead perform the wrong command. This is rare since 31/32 writes to the screen simply data rather than commands, but it happens. So what can happen is that the LCD driver executes the wrong command, and that command happens to be test mode.
I remember Mario crashing and causing a blue screen on a TI-83+SE. But your way sounds plausible, too.
274
« on: October 08, 2012, 11:43:59 pm »
That honestly stopped me from writing like 5 different examples he could use.
I was totally thinking of you when I wrote that. But also myself to a degree. Because I later had the idea that you could use Run Programs to load a program into RAM from an app, and have the app and program exchange pointers to sharable data and code using tables in scrap RAM. Of course, you'd have to jump back into the app from the RAM program, instead of returning normally; and, you'd have to use a bit of assembly (five or so bytes) to keep track of the app page. That introduces some ugliness, either requiring you to keep careful track of the stack, and making instant quit impossible without leaking memory; or, requiring some assembly code to fix up the stack and delete the RAM used, so that instant quit works right. Personally, I think the latter is the better solution, since keeping track of the order to use the code isn't too hard, I think. Does anybody want such an Axiom? You know, it's actually do-able. You could do it the reverse way, too, using an Axiom to search for the app, and jumping into it instead of calling it from the OS. Because, you know, otherwise there's ugliness arising from the context change and all. . . . EDIT: Right, so, to answer partially the previous post's question, PC is how the CPU keeps track of where it is in a program. Basically, each part of an Axe program is assigned an address in memory, which is just a simple number. The CPU just keeps incrementing that address, so it executes instructions in order (unless you ask it not to with a loop, conditional, or transfer). Programs are loaded into RAM at the address $9D95, whereas apps are loaded into the pageable space at $4000. Matrefeytontias's idea of making a jump table is probably sound, but I'm not clear on what he means about changing PC. Axe apps start with PC=$4080, because the first 128 bytes are the header.
275
« on: October 08, 2012, 01:32:19 am »
The Run Programs Axiom lets you call an external program (or a program typecast into an appvar) from an application. Axe variables aren't affected by the call. However, the transition in and out of the external code is pretty slow, an almost unavoidable * limitation of the OS. *Yes, assembly programmers can come up with dozens of ways to get around that. None of them will integrate cleanly with Axe.
276
« on: May 01, 2012, 05:08:35 pm »
Rechargeables just barely give enough voltage to make the calculator happy; try using primary cells.
277
« on: April 30, 2012, 06:29:19 pm »
For future reference, never read the error messages TI Connect gives. TI Connect's error messages often have nothing to do with what's actually wrong.
278
« on: April 29, 2012, 05:08:04 pm »
COuld someone make a 8xk compatible with normal USB clabes? I can't get zStart because "the version is compatible only with Silver Cable" and it's not my calc (I got it only for TI-Concours).
That sounds very strange. It shouldn't matter what type of cable you are using to send the app.
279
« on: April 12, 2012, 03:17:38 am »
Interesting. What does happen if you try exiting the program? Does it automatically returns to the original program or do you need to manually run the original program again from the nested one?
The Axiom is coded so that you always return from the subprogram to the caller, no matter what *. Instant quit, for example, will actually return back to the caller. This is necessary to prevent leaking memory (the memory used by caller would fail to be cleaned up), especially if you call the Axiom recursively. However, if anybody wants a version that chains to subprogram---that is, that deallocates the caller and never returns---I could make it fairly easily. Also, if anybody was wondering, you cannot use this to call an application. * Unless you do something really wacky.
280
« on: April 08, 2012, 11:20:32 pm »
Run Programs Axiomhttp://www.omnimaga.org/index.php?action=downloads;sa=view;down=786This Axiom lets you run other assembly/axe programs from any Axe program or application. The program can even be archived. This lets you break down your program or application into smaller parts that can live in the archive. Additionally, it also lets you catch errors that the OS may throw; that is, it lets you prevent that ERR: screen from showing up. See the readme for more details. Protip: Since the Axiom itself always has to check for error conditions like low-memory and the subprogram not existing, you don't have to check yourself. Just wrap the RunPrgm() call in an error handler, and the handler will only be called when there's an error.
281
« on: April 05, 2012, 08:29:12 pm »
Very nice! An interesting question is if it, like the 84+ Pocket, is unable to swap RAM into $4000-$7FFF via port $06. Unfortunately, I think that would be a yes. Can you test that? (It's pretty simple; I or various others could tell you how.) I take it that it has boot code version 1.03 and the OS is 2.55MP?
I really want to see this for myself. It's a change that just seems totally unjustifiable, for it seems that the money that TI paid to an engineer to make the change would be more than the money TI could ever hope to save. Anyway, it's almost certainly the case that the SE and non-SE have completely identical PCBs, except for the flash chip. On the non-pocket models, the boot code has to inform the ASIC which model calculator you are so the ASIC knows which sectors to block writes/erases to.
282
« on: March 18, 2012, 12:24:25 am »
Hmm. It might be better to make a z80 emulator for the Prizm instead that uses the same constants, bcalls, and such as the TI83/84. That way you could technically have Axe for the Prizm and ASM projects would also be able to work on the Prizm as well without having to emulate the entire calculator with redundant functions already provided by the Prizm.
I'm not sure why you think that. If your emulator is accurate enough to run assembly programs and apps, it will be accurate enough to run the regular OS.
283
« on: March 11, 2012, 12:50:57 am »
Can't we just bind a timer to the port so that the program doesn't freeze every time a note has to be played? Sure. The the calculator totally has a southbridge that can handle DMA. It even has a PCM wave buffer. OK, sarcasm aside, sound synthesis is difficult because it has to be done via pure bit banging. You could set up a crystal timer interrupt to handle changing the port status at a fixed rate, but it will sound terribly out of tune. The reason is that the maximum frequency that you can get interrupts to fire at is 32768 Hz. As a result, you have to quantize the period of each note to intervals of 1⁄ 16384 of a second. The human ear can hear frequency distortions of less than 1%. With such a synthesis technique, the error from the correct frequency will begin to exceed 1% around middle C. If you're wondering, the quantized frequency of a frequency f n quantized to a half-frequency of f s (here, 16384) is f q(f n, f s) = f s/round(f s/f n) The ideal frequency of piano key m is f m( m) = 440 * 2^(( m-49)/12) The percent distortion for a particular note n quantized to a half-frequency f s is f e( n, f s) = (f q(f m( n), f s) - f m( n)) / f m( n) Go ahead and graph this on your calculator and you'll see the graph cross the 1% line for the first time at G#3. Incidentally, this is why even simple delay-loop based music sounds slightly distorted. It's not the fact that the frequencies will differ from the ideal by a small percentage, it's the fact that those percentages are all different that makes the music sound out-of-tune. (Also, the square waves take some of the blame.)
284
« on: March 07, 2012, 09:53:30 pm »
 So I'm in 9th grade right now and i have a ti84se. I downloaded zoommath500, and palyed around with it, found that it's really useful while it's way toooooooooooo expensive. Does anybody have any idea about how to hack that software, or move the cas from ti89, or the one in ti92, to z80 calc as a app or into it's system? it'll be hecka awesome
It most certainly can be done, but that doesn't mean it's a good idea. In the time it takes you to learn enough about software engineering to understand how to crack ZoomMath 500, you could have legitimately learned how to do algebra---and probably everything up through differential equations---because reversing engineering is very tedious work. The last person I know who gave it a real try (a master of reverse engineering calculator software) spoke highly of the app's copy protection system, saying that the system was well designed and very difficult to crack. But I won't tell you who, because I'm not interesting in ruining IQ Joe's business. So just do your school work. However, I do encourage you to try writing your own software. Writing a program to perform a mathematical task forces you to formalize the concept in a way that may help you to understand it better. I, personally, have only shared one of my math programs online. But it has a note saying that it could sometimes fail to produce an answer when one exists, and to work out the problem by hand if that happens.
285
« on: March 06, 2012, 07:13:47 pm »
Ah, this would make a great Axiom, and would help out a lot with a project like XDE (If it wasn't dead )
What do you mean, "would"? It is an Axiom.
Pages: 1 ... 17 18 [19] 20 21 ... 38
|
Show Posts