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 - TravisE
Pages: 1 2 [3] 4 5 ... 14
31
« on: March 18, 2013, 09:16:56 pm »
My 50g seems to graph sin(x) at roughly the same speed as my 89t, when both are set to the same plotting resolution. Fast3D beats the 89's 3D hands-down, though, when it comes to interactive rotation framerate.  It's possible that older 49-series calcs might be slower, though; the old models with actual Saturn processors would be much slower, of course. It's also possible that various speed optimizations may have been made in the ROM code over time. I'd be interested in seeing some videos of the 39gII graphing equations for comparison purposes.
32
« on: March 18, 2013, 12:38:51 pm »
If they recoded the 39gII in C or in some language that compiles to ARM ASM, that would definitely explain why it seems so fast. The 50g is somewhat held back due to most of its OS being written in RPL, running in an interpreter written in Saturn ASM, running in a Saturn emulator written for the ARM. In many ways, it actually seems surprisingly fast despite the overhead (many operations are much faster than on the TI calculators with their native CPU OSes). Though, it is possible to write programs directly in Saturn ASM, ARM ASM, C, or whatever for the 50g—I haven't looked into that, and to be honest, I haven't really tried any games even though I've had this calc for several years already—always too busy coding my own stuff. 
33
« on: March 18, 2013, 06:39:48 am »
Interesting. I take it the 39gII is a recently released calc model? And it appears to support grayscale directly in the user programming language? That sounds pretty cool. The HP 50g is rather weird—there is SysRPL (no UserRPL) support for manipulating grayscale graphics, but none for actually displaying them—they apparently leave that up to third-party libraries. Go figure. Actually, though, there was a grayscale Easter egg on some ROM versions, and I sometimes see gray pixels when I crash it with bad SysRPL code… I've never really explored grayscale on the 50g yet, so I don't know.
34
« on: March 18, 2013, 06:18:50 am »
That does sound ridiculously fast. :O I'm not sure UserRPL code on the HP 50g would even come near that speed redrawing everything every frame (though scrolling the screen and redrawing new pixel columns each frame should work nicely in SysRPL, I think). Games on the 50g are tricky if you're using RPL due to the annoying garbage collection “pause” that occurs every so often; you have to force it to occur more often (“GARBAGE” in SysRPL or “MEM DROP” in User), but doing it every frame noticeably slows down the frame rate. If you get lucky, you can do it every few frames and get decent speed without the animation looking too jerky, but it seems to depend on exactly what you're doing.
I'm not familiar with the 39 series (I get the impression it has a significantly different internal software design from the 50g, but I have no idea). I can't imagine what would cause that program to take 9KB—even the untokenized text isn't even 1KB. I know the 39s have some kind of unusual “app” system or something like that; perhaps the 9KB includes all the configuration for the current app or something like that? (In case anyone's curious, the 50g compiles user programs into SysRPL code; each command word normally takes about 2.5 bytes (20 bits) each.)
36
« on: February 22, 2013, 12:32:35 pm »
There's nothing wrong with an emulator, if it doesn't include any code it doesn't have a license to include. It just mimics a particular set of hardware. You could write your own code for the emulator and run just that. Copyright law has nothing to do there.
I'm not a lawyer, but I don't really see how they could ban an emulator skin that someone created themselves and allowed everyone a license to use it. It's just a picture of the calculator. It'd be pretty ridiculous if the makers of any product could stop you from taking a picture just because it had that product in the background somewhere.
37
« on: February 03, 2013, 03:52:49 pm »
BTW, I can solve a 0x0x0 in -1.201e-75 seconds (note: figure may be subject to round-off and/or binary-to-decimal conversion errors)
38
« on: November 21, 2012, 12:48:19 am »
39
« on: October 25, 2012, 12:52:13 am »
Wow. I wasn't really expecting that, to be honest. 
40
« on: October 09, 2012, 02:09:46 pm »
The twinkie one is admittedly a whole quote I threw in there as a unit. It came from an old #tcpa log or maybe the quote database.
I weighted certain terms like “lamesauce”, “sucks”, “fails”, etc. more than others to try to make it sound more like Nikky, though this statistically makes it a bit less random.
I also have suspicions that the rand/random functions in stdlib.h leave a bit to be desired in terms of randomness. I may try implementing a different PRNG algorithm to see if the results are better. I went through a large number of sayings during development and ended up hitting a ton of duplicated or highly similar quotes—a lot more than it seems I should have.
41
« on: June 21, 2012, 12:23:22 pm »
That's pretty cool. If you were writing just TI-89(t) programs, you could probably use the extra space for debugging info or something, or hidden messages. That sort of reminds me of once when I was fooling around in Command Post Plus and poking in random bytes like my name in the off-screen area of the 89 LCD buffer. If you don't reset the calc or run ASM programs that use the full buffer, it can invisibly remain there for quite some time. It would be cool if someone found a way to make an inexpensive external display. Or even a large, bright LED display, hehe.
42
« on: June 21, 2012, 12:17:07 pm »
Someone will have to answer the other questions. But if you haven't already, you might also consider the optimization options available in TIGCC/GCC4TI, which may help with executable size. http://debrouxl.github.com/gcc4ti/httigcc.html#advanced There are especially things like FLINE calls/jumps, which trade off speed for size. And, of course, there are the compressed programs (the ones that use Super Start/ttstart/their own launcher), but I haven't made one myself yet, so I don't know much about making those.
43
« on: June 03, 2012, 04:02:45 pm »
Maybe you either need to push END_TAG before pushing your arguments or delete everything up to the END_TAG, or something like that. For instance, I had a very small program that returns the value of FiftyMsecTick (which I used for more precise timing in TI-BASIC programs) that looked like this: /* Program creation date: 2007/04/23
Compilation command used: tigcc -O3 -Wall tick.c
*/
#define MIN_AMS 200
#define RETURN_VALUE tmrval
#include <args.h>
#include <estack.h>
#include <system.h>
void _main(void) {
// Return result:
while (GetArgType (top_estack) != END_TAG) // Clean up arguments
top_estack = next_expression_index (top_estack);
top_estack--;
push_longint(FiftyMsecTick);
}
I don't remember where I got the “clean up arguments” code, but I'm sure I pasted it from somewhere rather than figure out how to write it myself. My other (very small test program) I could find like this added its own END_TAG, like this: // Test routine--returns the string "Hello, world!"
#define RETURN_VALUE ret
#define USE_TI89
#include <args.h>
#include <estack.h>
#include <vat.h>
void _main(void)
{
ESI argptr = top_estack;
push_END_TAG ();
push_zstr("Hello, world!");
}
A quick test in TIEmu seemed to show that this program works.
44
« on: June 03, 2012, 03:37:24 pm »
#define RETURN_VALUE nOh, it's not that simple: RETURN_VALUE is an argument-less macro
If you want to store data to a variable, you need to either use a high-level function such as VarStore, or do it the hard way, by building the variable yourself: HeapAlloc + SymAdd + etc. (lots of error checking), write the two size bytes, write the variable's contents (here, nine out of ten bytes from the float) and end tag (0x23 FLOAT_TAG).
The docs refer to using a variable name as an argument to RETURN_VALUE to automatically store the last value pushed to the expression stack to the variable, and I even seem to remember using this myself once. Has this changed?
45
« on: April 02, 2012, 08:10:19 pm »
I was hoping to mess with people's heads with the border color, maybe making them wonder if it might have actually been real. I wanted to have it that way longer, but there wasn't much time left before April 1 was over.
Another thing I'm not sure if anyone noticed was that I made the front page return a 403 error for a few seconds at about 20–30 second intervals. This only lasted a few hours up until midnight April 2 CEST, though.
Also, if anyone happened to watch the file upload page, you would notice the pending files constantly increasing throughout the day, eventually reaching a peak of about 1650 files before I shut down the prank.
Pages: 1 2 [3] 4 5 ... 14
|
Show Posts