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 - calcdude84se
Pages: 1 ... 51 52 [53] 54 55 ... 161
781
« on: November 29, 2010, 08:54:01 pm »
Good, because the original developers were very good, or at least better than those on 2.53 MP 
782
« on: November 29, 2010, 08:50:48 pm »
951: You personally know one of the original TI-OS developers
783
« on: November 29, 2010, 08:43:19 pm »
Ah, okay, that makes sense. Have you duplicated the font routines yet? 
784
« on: November 29, 2010, 08:41:06 pm »
Spray-painting him doesn't work
785
« on: November 29, 2010, 08:37:26 pm »
Something tells me that that program uses the OS bcall. If it did otherwise its author would most likely have stated. Xeda wants an OS-independent one for some unknown reason  Edit: ninja'd
786
« on: November 29, 2010, 08:35:22 pm »
I think multi-page apps have been on the list for a while  They're rather difficult, so it might be a while before we have them. Edit: We should probably get a new poll soon
787
« on: November 29, 2010, 08:34:15 pm »
Redrawing it (or backing up the entire buffer-pair (you'll need a 768*2-byte appvar)) is probably the easiest option But yes, screen data is at L6. The backbuffer is at L3, and is also used for displaying greyscale images.
788
« on: November 29, 2010, 08:29:42 pm »
No You can create a 2000-byte picvar. The OS won't complain, even if you use RecallPic with it. 756 and 768 are the two most common sizes because the OS uses 756 (63 rows) and 768 is the full screen (64 rows) Edit: ninja'd. maybe.
790
« on: November 29, 2010, 08:22:25 pm »
I have assembly You want bit 0 of port 2. It's set if batteries are good, reset if they are low. So: in a,($02)
rra
jr c,batt_good
batt_bad:I think you get the general idea 
791
« on: November 29, 2010, 08:16:23 pm »
Yeah Pic, picvar, or something to that effect.
The syntax to include the data of a picture into a compiled file is this:
[Pic1]->Pic0It inserts the data from TI-OS var Pic1 and makes it accessible through the Pic0 static pointer.
As for reading an arbitrary pic, do you mean in the sense of "a certain picvar I choose at compile time" or "a picvar chosen at runtime, perhaps by user input"?
The first is easy, and can be done like this:
If GetCalc("Pic1")->X
Copy(X,L6,756
EndThis code, if Pic1 exists, copies it to the main buffer.
Dealing with a variable one is a bit harder, and I forget the specifics, but it involves overwriting a byte in the name to change it.
Same situation for writing. Here is code that copies from the buffer to Pic1.
If GetCalc("Pic1",768)->X
Copy(L6,X,768
EndFor both reading and writing an arbitrary one in the second sense, you need the overwriting, but, after you change the name, the general process is the same.
Note what 756 and 768 mean. A picture of size 768 includes the bottom (63rd) row, but size 756 does not.
792
« on: November 29, 2010, 08:04:54 pm »
Yeah, you're only protected from infinite loops.
RAM corruption is impossible to prevent; the nature of the z80 processor is what causes that.
793
« on: November 29, 2010, 08:02:10 pm »
I think I should say something to the effect of "What kind of developer are you whose RAM hasn't been cleared in any given 2-day period?" And yes, the clock on my TI-84+SE is essentially a counter
794
« on: November 29, 2010, 07:57:11 pm »
I seemed to have missed the answering of this question, but I'm glad everything got resolved (Congrats Runer) Good luck on the rest of this project!
795
« on: November 28, 2010, 08:17:05 pm »
No, you have to copy data. So more like this:
Copy("TEST",GetCalc(Data,4,[sup]T[/sup],0,0),4
Pages: 1 ... 51 52 [53] 54 55 ... 161
|
Show Posts
