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 - blue_bear_94
Pages: 1 ... 33 34 [35] 36 37 ... 68
511
« on: December 26, 2012, 12:34:45 pm »
3877: You take pride in posting right before and after DJ_O
512
« on: December 26, 2012, 12:26:13 pm »
1. The dialog boxes are supposed to be in black-and-white, not some shade of gray. Does it matter whether I kill gray mode before allocating data or after?
2. Sure.
3. ...
4. Maybe I've used a lot of stack space for, maybe, function calling?
Edit: I changed canUndo and isUndone to regular char types, and the repeatable pattern no longer occurs.
513
« on: December 26, 2012, 12:14:51 pm »
3876: We don't care. At all.
514
« on: December 25, 2012, 09:39:25 pm »
You can declare a pointer variable, then assign the return value from malloc to that variable.
int* inventory=malloc(70*sizeof(int));
515
« on: December 25, 2012, 06:08:25 pm »
Whenever I call enableUndo for this program (from a menu), I get light gray vertical lines as on the image attached. I think I did everything right, so here is the excerpt I am having trouble with:
typedef struct {
void* prevl,*prevd;
char canUndo:1,isUndone:1;
} UndoInfo;
void* allocBUB(void)
{
void* buffer=NULL;
if (!(buffer=calloc(LCD_SIZE,1)))
{
dlgError(DMA_ERROR,MEMALLOC_FAIL);
return NULL;
}
return buffer;
}
int allocGBUB(void** lbuff,void** dbuff)
{
if (!(*lbuff=allocBUB()))
{
return 0;
}
if (!(*dbuff=allocBUB()))
{
free(*lbuff);
return 0;
}
return 1;
}
void enableUndo(UndoInfo* p) {
GrayOff();
SetIntVec(AUTO_INT_1,I1);
SetIntVec(AUTO_INT_5,I5);
//*v: this may be the cause of the gray bars
p->canUndo=allocGBUB((void**)p,(void**)((char*)p+4));
SetIntVec(AUTO_INT_1,DUMMY_HANDLER);
SetIntVec(AUTO_INT_5,DUMMY_HANDLER);
GrayOn();
}I would appreciate any assistance given!
516
« on: December 25, 2012, 10:16:22 am »
The question is:
Which member was on its final day on Omnimaga yesterday as a direct result from his received gift?  (especially if someone got WoW, LoL or Minecraft)
Someone was banned? 
Probably someone went inactive on Omni (stopped programming and reading the forums) because he/she was obsessed with his/her gift.
517
« on: December 23, 2012, 06:10:18 am »
I should have been more clear. I know the processor is z80, (though they could list it) the thing I'm curious about is the clock speed.
According to Wikipedia, it will be at least 15 MHz. * several alternative high-level languages are available, though none of them is very popular: GFA-Basic, Newprog (probably one of the programs closest in spirit to Axe), etc.
Never heard of those
What calculators are those for?
NewProg is for the 68k series. I'm not sure about GFA-Basic.
518
« on: December 21, 2012, 12:05:57 pm »
Well, if it's not in popularity, then I think it's safe to say that the 68k series is crippled in the speed and difficulty of its programming language. Not sure what you're talking about, especially since you're a TI-68k programmer as well 
* the TI-68k series' BASIC isn't significantly better or worse than the TI-Z80 series' BASIC (both being much better than the wimpy Nspire BASIC), and its functionality can be extended through external assembly programs programmed in C and/or ASM;
I said that editing and executing 68k-Basic programs were a pain, due to the editor and the inconvenient location of all of the drawing functions. (That's why I program mostly in C for the 68k series.) I agree with your post; the 68k variant of BASIC has more functionality, but at the cost of performance (one notable example being lists). I reaaly wish TI would have mentioned what kind of processor this thing has on the specs page. 
It's z80.
519
« on: December 20, 2012, 09:21:14 pm »
When multiple different people work together on code, it quickly becomes a mess. Especially when it's a whole bunch of people on something as big as an OS.
Of course, TI is an exception. But maybe they're more organized. Organization might be what we need.
520
« on: December 20, 2012, 09:16:29 pm »
What would happen if we worked as a community?
Or we could just using models with more RAM...
521
« on: December 20, 2012, 09:14:39 pm »
Or we can just develop our own calc.
522
« on: December 20, 2012, 09:11:53 pm »
That was for using extra graphscreens. We're talking about using the extra RAM for things we use the 24k given to us for.
523
« on: December 20, 2012, 09:10:05 pm »
I think the OS uses 8k, but I don't think using the other 8k for Basic would be possible. Trying to do so would require modifying a lot of memory locations, and then assembly programs written for the unpatched calc would not work with the patch.
524
« on: December 20, 2012, 09:02:02 pm »
that's because TI is crazy and the os also needs some ram
Why not put more RAM in the first place, then?
525
« on: December 20, 2012, 08:58:50 pm »
However, you can still access only 24K for your programming/math purposes. So the only use for the extra 80k is the programs that happen to need a LOT of RAM.
Pages: 1 ... 33 34 [35] 36 37 ... 68
|
Show Posts
