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 - calc84maniac
Pages: 1 ... 154 155 [156] 157 158 ... 197
2326
« on: March 05, 2010, 08:25:28 pm »
I believe I made a topic for it already. But, I'm entering a competition for a scholarship using xLib and BASIC. Lemonade Tycoon is my game.
Now, here's where it comes together.
I'm using a Presentation Link and a TI ViewScreen. I ran my program that uses xLib. It shows up fine on the calc... but it's got the wavy screen on the screen.
AND IT'S JUST THAT PROGRAM. Everything up to that point (the PRGM menu, the Home Screen, the Graph Screen) displayed fine.
Can Axe screw up xLib programs?
Where does Axe fit into all of this? And Axe does not install any OS hooks or anything like that.
2327
« on: March 05, 2010, 03:31:02 pm »
I kind of have to disagree with you a bit DJ, I think graphics is pretty important (although he really doesn't need to add too much, it's already amazing), but, at least from my point of view, Axe is a program that will let the most basic BASIC programmers make games at assembly level with equal graphics and speed, and I think that being able to do most of the graphic capabilities of actual ASM programs is important. But that's just my opinion, and I do agree that other things should also be focused on.
He's talking about graphical user interface for compiling programs
2328
« on: March 04, 2010, 07:47:15 pm »
well debugging would be possible on older 15MHz models with all that extra RAM...but of course that's cutting out all the other people...
Actually, I'd think debugging would be pretty darn hard to pull off. Unless, of course, you might be able to build executables that allow debugging, but have larger code size?
2329
« on: March 04, 2010, 03:54:58 pm »
Maybe. But I think that since they provide us with the entire OS, I suppose we can do what we want with it, except for distributing it. Even though putting CAS on the non-CAS one might be considered stealing, I don't think TI can do much about it.
They can do things to the people who release such a hack, I think.
2330
« on: March 04, 2010, 01:46:42 pm »
Also, remember that these are not the real A and Pic1 variables from Basic. That's just what we're calling them.
2331
« on: March 04, 2010, 01:13:03 pm »
What I think is that if they sent DMCA notices, the EFF would fight back again and TI would end up epic failing again, like what happened with the keys.
TI might have some ground on this one though -- this would be stealing software that actually costs something (I know the .tnc upgrades are free, but they require the upfront cost of a more expensive calculator)
2332
« on: March 04, 2010, 07:56:10 am »
Well, I figured the main use for it would be to skip long cutscenes and text dialogs and stuff. But I guess I'll add the toggle.
2333
« on: March 03, 2010, 09:56:18 am »
So if it is on a 15MHZ calc it will compile certain code and on 6MHZ it will compile something else. That makes it easier to compile for timing and such.
Once there is timing support, it will probably be independent of clock speed anyway (using interrupts)
2334
« on: March 03, 2010, 12:17:37 am »
I remember that he was using the emulator to start making the GBC emulator, but now he can actually /run/ it on calculators, right?
(What does "ninja'd" mean?)
Yeah, we can run it oncalc now. And ninja'd is a forum term that is often used when two people post the same message at the same time and one gets theirs in first Edit: Ha, I got ninja'd! See?
2335
« on: March 02, 2010, 11:02:59 pm »
Well I would be ok with compiling smartly. We could just give out the source and people could compile it themselves. Unless we send it to ticalc then we would just make different versions. Running smartly would make it run slower.
How often are you going to have to check calc type though? It's not that slow anyway.
2336
« on: March 02, 2010, 10:26:17 pm »
That would be very useful as well. This made me thinking, since the LCD isn't memory mapped (right? ) swapping buffers would be as simple as changing a pointer in the safeCopy routine right? Or do I not know what I am talking about? 
You are quite correct. And it should only be 6 extra clock cycles per call when using a variable instead of a constant, which is not enough to make a difference.
2337
« on: March 02, 2010, 08:12:48 pm »
Hmm yeah, maybe instead of having plotSScreen always be the draw area, add a command to set a different buffer to draw to. You would only need to change immediate loads of plotSScreen to loads from a variable in memory. Heck, maybe you could use Theta for this purpose, and have it be accessible like a normal variable.
2338
« on: March 02, 2010, 06:41:09 pm »
also the option to leave the emu without saving would be nice, unless there is such an option and i was a silly willy and missed it when reading the readme :X
You can always pull a battery, lol
2339
« on: March 02, 2010, 02:37:50 pm »
Awesome
2340
« on: March 01, 2010, 11:42:59 pm »
I think NES and Gameboy display hardware had this limit too. Think retro!
Pages: 1 ... 154 155 [156] 157 158 ... 197
|