1231
TI Z80 / Re: 8xp to txt Converter
« on: November 12, 2010, 04:16:51 pm »
Scoutdavid, I actually made one of these 4 days ago in c++. I could give you the source if you wanted.
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. 1231
TI Z80 / Re: 8xp to txt Converter« on: November 12, 2010, 04:16:51 pm »
Scoutdavid, I actually made one of these 4 days ago in c++. I could give you the source if you wanted.
1232
ASM / Re: The copying of ASM programs« on: November 12, 2010, 03:05:08 pm »
I'm not exactly sure what your are saying, but here is how it works. When you run a program, either a BASIC with prgm, and ASM with asm(, or even an asm with bcall(_executePrgm), it gets copied from where ever it is to $9D95. The program can be in flash, or it can be in ram, either way, space is allocated at $9D95 and the program is copied there. When it is done executing, the OS just deletes that memory and it is is gone, which is why smc doesn't change the program. Also, since memory must be allocated for the program to be run, if you don't have enough ram left, you will get an ERR:Memory.
1233
ASM / Re: Saving previous hook states« on: November 11, 2010, 06:37:19 pm »
SmallEditRam is my favorite ram location because nothing uses it. You can put a hook there and a week later, it will still be there. Appbackupscreen gets killed by almost every single asm program. Not to mention omnicalc uses it quite a bit for hook activities.
I am saying put your hook code in smallEditRam because you don't have to worry about it getting overwritten. 1234
ASM / Re: Saving previous hook states« on: November 11, 2010, 06:30:58 pm »
Use smallEditRam, it will persist through most Asm programs. It's only 117 bytes, but that's enough to find code in the archive and stream it to appBackUpScreen.
1235
ASM / Re: Saving previous hook states« on: November 11, 2010, 06:19:46 pm »
Get on wabbitemu, clear your ram. Then install an app and check the memory around $9BAC. You should see mostly 00's, but there should be a few 3 byte strings. Depending on which app page those strings give, you can tell which app sent out the hook. (You can use omnicalc to figure out which app is on which page.) Then use brandonW's ti83plus.inc to figure out which hook it is.
1236
Axe / Re: 8xp to text converter« on: November 11, 2010, 06:07:49 pm »
After talking with brandonW, you don't need to install them. Turns out as long as you have something newer than windows 98, you already have them. That prgmuISPLAY is strange. I'll have to look at that.
1237
ASM / Re: Saving previous hook states« on: November 11, 2010, 03:35:40 pm »
Restoring hooks is easy when you know how they work. For each hook, there is a 3 byte area of ram and a flag. The ram is 2 bytes of the address followed by the page byte. And the flag is as simple as on/off. Here's the wikiti page on the parser hook. As you can see, its ram is at $9BAC and its flag is 1, (iy + $36).
As far as backing up goes, that's pretty easy. Save the three bytes as $9BAC and that flag. Then when you are done, just restore them. But chaining is a little more difficult. First, you are going to have to get the information from those areas, but save them somewhere where you can find them later (this can be difficult sometimes.) Then install your hook. Now when your hook is called you do your thing, but when you are done, you need to put the calculator right back in the state you found it and jump to the address you just saved. If you have any differences in calculator state, the other hook won't know what to do and you'll run into problems. And of course, if you need to return a value to the OS, you won't be jumping to the other hook. 1238
ASM / Re: Swapping Pages during Program...« on: November 10, 2010, 05:26:22 pm »
That is super easy. What you'll be interested in is port (06), that controls what page is swapped in for the $4000-$7FFF range. So values 0 - $7F are flash and $80-$87 are ram.
Here's how you'd do it. Code: [Select] in a, (06) And just a few notes: The page you output to port (06) doesn't have to be the app page, you can output whatever you want, but just realize that whatever page you output is what you'll be looking at. And also, you can have the page swapped in for your entire program, Ti OS has no problem with what page is in port (06). Just be sure to put it back when you are done considering that your program returns to somewhere around $6000. 1239
ASM / Re: WikiTI« on: November 09, 2010, 09:39:34 pm »
I totally agree. Personally I have no idea how low level USB works. The only clues I've ever gotten are from looking at USB8X.
In addition, there is virtually no information on using hooks I remember the way I learned how to use them was actually by seeing examples posted in forums. Flash is also completely undocumented (but perhaps that's a good thing.) 1240
ASM / Re: WikiTI« on: November 09, 2010, 09:02:25 pm »
That information has been known for a long time. But I think this is the first time anyone has put it into formal writing. There is the old talk page but that is mostly just guesses. Really, the only place to get hard information about USB is to look at the source from USB8X, but even that is old (2005 I think).
I guess the only way to have up to date information is to be BrandonW. 1241
TI-BASIC / Re: TI-83+/84+ (SE) BASIC Tips, Tricks, and Routines« on: November 08, 2010, 10:40:45 pm »
Here is the complete testing code:
:startTmr :Repeat startTmr=Ans+1 ;this is to ensure that the test starts exactly on a second, not halfway through :End :startTmr->A :For(B,1,6000 :<Code goes here> :End :Disp checkTmr(A Here are the real times: :1 16 :1->N 19 :1->A 22 :Ans 19 :A 19 :N 16 And then the big one with 15,000 iterations: :1 :Ans 65 :1->N :N 67 1242
TI-BASIC / Re: TI-83+/84+ (SE) BASIC Tips, Tricks, and Routines« on: November 08, 2010, 10:09:22 pm »
I did a few tests today which broke some of my long held beliefs about speed.
The access time of Ans is the same as the access time for regular variables. So for instance both of these take the same time to execute: Ans+Ans/Ans = Ans A+A/A = A But, this is faster: (N refers to the finance N) N+N/N = N This second rule holds true for any system variable so Xmin, ZXmin, TblStart, etc. are all fair game. However, when it comes to store time: 1 is faster than 1->N which is faster than 1->A Which means that Ans can be just as fast as the system variables as long as it is the only variable used. These will execute in nearly the same speed: (The Ans version is like 2% faster) 1:Disp Ans |vs.| 1->N:Disp N This is only interesting news though if you don't care about program size. N is 2 bytes while Ans is only 1. Not to mention that your code becomes nearly unreadable if you start using the ZXmin and ZYmax variables. 1243
Axe / Re: 8xp to text converter« on: November 07, 2010, 04:09:50 pm »
It's just a one way converter. It can't take text back to 8xp. If you really want to do that, you might as well use SourceCoder. I made this mostly so you can blow up your calc files and look at them.
1244
Axe / Re: 8xp to text converter« on: November 07, 2010, 03:12:50 pm »
Ok, this took way longer than I expected it to, but I finished it.
Here is a 8xp to text converter. It can handle all available tokens on the calculator and appears in my testing to be error free. For tokens that I couldn't make work in C++, like theta, I did my best replace them with something logical. (theta = <theta>, sigma = E, √ = sqrt, etc.) I must say that my old basic programs look really cool in notepad And there are a lot of token in the TI OS... 1245
TI Z80 / Re: The World's Hardest Game« on: November 05, 2010, 11:37:50 pm »
Apps slow the calculator down any time it has to look through them. So for instance, pressing the apps button, or going to the memory menu are slow when you have a ton. Deleting them is also slow if there are a lot. I see this all the time because when I am giving people games, I usually delete the 30 or so useless apps on their calc and it is really slow.
|
|