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 - thepenguin77
Pages: 1 ... 19 20 [21] 22 23 ... 108
301
« on: June 16, 2012, 02:05:50 pm »
I was once in your shoes, that's why I wrote a tutorial on TI-Connect. Try it out and see if it helps.
302
« on: June 15, 2012, 10:34:38 am »
Could I just try running it through IDA? (I need the 8xp)
That looks like a good disassembler, but one mistake can break the program.
303
« on: June 14, 2012, 12:30:07 pm »
I know what the problem is, there are a lot of pointers inside this program that are simply numbers now (they used to be labels). The problem is that now the code is executing from a different location (because of 83 reasons as well as adding/removing code). What you need is to have all your labels in line.
If you post the .8xp, I'll get you a disassembly with all the labels in the right spot. (I'm going to use IDA)
304
« on: June 13, 2012, 03:15:36 pm »
Yes, that is almost exactly what both zStart and DCS do.
If you are going to do this, be sure to temporarily change the name of the program that's in the archive so that you don't have two programs with the same name.
305
« on: June 13, 2012, 01:12:33 pm »
EDIT : can I use it in my Axe tutorial ?
Sure, though, you might want to wait a few days so that all of the errors have been fixed.
306
« on: June 12, 2012, 11:47:39 pm »
Hey everybody, Sorunome here. I converted this table into a more machine-readable format and made it way easier to search by address or by ID, so e.g. when searching for 8005 (or $8005 or 0x8005) it'll jump to appData. You can find it here: https://www.omnimaga.org/index.php?page=ramhere is some more information as to what all that search supports Persistence: ***** barring obscure situations, this memory won't be touched by outside forces **** some avoidable practices will overwrite this memory *** normal operation may occasionally overwrite this memory ** this memory location is not stable by any means, though, it's still memory * this is hardly memory, it's only listed because it was in the way Collateral damage: ***** changing this memory has absolutely no effect on anything **** there are some situations where changing this has an effect, though, you probably won't run into them *** this makes some rather rare events fail, but it could happen ** this makes some common tasks fail * honestly, the calculator basically crashed bcalls: bcall(_clrTxtShd) Asm(EF4C45) bcall(_delRes) Asm(EF204A) bcall(_fillBasePageTable) Asm(EF1150) bcall(_grReset) Asm(EF3148) bcall(_randInit) Asm(EF7F4B) bcall(_saveCmdShadow) Asm(EF7345) bcall(_zeroFinanceVars) Asm(EF2B51) [/size] [/font] [/td][/tr] [tr][td]  [/td][/tr] [/table] The collateral damage number is only correct if you follow my recommendations for cleanup. If you don't, then things might go very bad. What it breaks is what won't work when you are using that memory, it will work after you are done. And when you clean up, I recommend you first zero all the memory you used, copy back the manual backup locations, and then run all the necessary bcalls. Lastly, if you see any changes that need to be made to the list (like anything), be sure to tell me. Be sure to thank shmibs for hacking the width of this page.
307
« on: June 11, 2012, 09:58:55 pm »
EDIT: I opened up my notes and followed through some of my work and what I have found so far:
If there is a non-trivial solution for A2-B2=c, then it is of the form (A+2d)2-(B-4e)2 where d and e are integers. This will let me speed up my code as I can forget about half or 3/4 of the potential values. I am still working on cutting that down even more 
I don't think this is true. And I see two problems with it. 1. (A+2d), the new A can't be greater than the original A. The reason why is that you can't get the difference between A 2 and B 2 any smaller than c because if you pick the best case scenario where B is 1 smaller, you'll get a new c by definition. So I think it's supposed to be (A-2d) 2. (B-4e), I ran some tests, and some needed 2e Here's what I did: (A,B) First column is number, second column is the trivial solution, third is the special solution, 4th is difference from trivial 9 5,4 3,0 2,4
15 8,7 4,1 4,6
21 11,10 7,2 4,8
25 13,12 5,0 8,12
27 14,13 6,3 8,10
33 17,16 7,4 10,12
But, (A-2d) 2 - (B-2e) 2 still eliminates half the numbers. Edit: The table looks so much better in preview than in the actual forum, idk why. Edit2: e is always greater than d, so that's another half of the numbers
308
« on: June 11, 2012, 07:02:22 pm »
The amount of space used at appID cannot be more than 178 bytes. The reason for this is 178 bytes after appID is where the memory locations for getCSC are stored.
However, this program might not use all 178...
309
« on: June 10, 2012, 01:50:25 pm »
Just going to point out, this isn't actually a disassembler and it's not for axe. (I was really excited for a second)
An Axe decompiler would turn an executable program into it's original axe source code.
A disassembler would turn an executable program into z80 assembly. (i.e. bcall(_clrLCDFull) \ ld a, 5)
This is an unsquisher and simply takes the hex and returns an ASCII representation of it.
But, other than that, looks good. I like that it throws the AsmPrgm token out front.
310
« on: June 09, 2012, 10:01:03 pm »
Flash archive variable format:
[1:status flag] [2:archived variable total size] [1:prog type] [1:T2] [1:version] [1:page] [2:address] [1:chars in name] [name length:name] [2:size of program] [size of program:program data]
So, I have these mentally grouped. In this order, it's 3+3+3+1+nameLength+2 and then the last +2 is for BB 6D. Really, the archive is just a vat entry with those extra three bytes out front.
311
« on: June 09, 2012, 12:27:23 am »
If you want to be able to use all of ram without getting into annoying shell stuff, you'll need to keep the main program in flash and use bcall(_flashToRam). It's a little trickier to get right, but you could probably figure it out. Just kidding. Here it is: ld hl, *name*
rst 20h
bcall(_chkFindSym)
ret c
ld a, b
or a
ret z
ex de, hl
ld de, appBackUpScreen
ld bc, 2+2+*nameLength*+1+3+3+3
push af
bcall(_flashToRam)
pop af
ld bc, 2+2+*nameLength*+1+3+3+3+$4000
or a
sbc hl, bc
add hl, bc
adc a, 0
push af
ex de, hl
dec hl
dec hl
dec hl
ld a, (hl)
dec hl
ld l, (hl)
ld h, a
push hl
push de
ld de, $9D95
bcall(_insertMem)
pop hl
pop bc
pop af
bcall(_flashToRam)
jp $9D95
I realized you didn't know the structure of flash variables, so you wouldn't be able to write this.
312
« on: June 09, 2012, 12:05:32 am »
Cyano's correct, it's velocity.
One easy way to look at it is that integrals (area under the curve) are basically multiplication. I mean, when you write an integral for this, it's [itegral sign]a(t)*dt. So, it's really just acceleration * time which equals velocity.
On the other hand, derivatives are division. So the derivative of velocity with respect to time is velocity/time = acceleration. Again, dv/dt shows this pretty well.
313
« on: June 08, 2012, 08:52:54 pm »
- AppID is used when searching for apps. This program is either using it as temporary space or is doing some OS hack. - _saveDisp saves the screen to a 768 byte buffer pointed to by HL - I've never programmed for the 83, so I don't know if there is a better include, but there probably isn't. _bufClrbufClr:
ld d, h
ld e, l
inc de
ld (hl), 0
ld bc, 767
ldir
ret
appBackUpScreen and appID - these are probably just free ram areas appBackUpScreen is 768 bytes and appID is no more than 20 keyExtent - this is specific to _getKey, the 83 should have it's own version kdbGetKy - I ran a quick test and this appears to be the getCSC code for the most recent key scan (these happen every interrupt) _saveDisp#define DWAIT in a, ($10) \ or a \ jp m, $-3
saveDisp:
ld a, $80
out ($10), a
ld c, $20
saveColumn:
DWAIT
ld a, c
out ($10), a
cp $2C
ret z
ld b, 64
ld de, 12
DWAIT
in a, ($11)
saveByte:
DWAIT
in a, ($11)
ld (hl), a
add hl, de
djnz saveByte
ld de, -767
add hl, de
inc c
jr saveColumn
ramStart - this is for free ram, it offers up to like 1000 bytes, but most people use less than 100 Edit: For these routines, you're actually better off looking at TI's official docs. They can be found here and the two you want are TI-83 Plus Developer Guide and TI-83 Plus System Routines.
314
« on: June 08, 2012, 04:13:38 pm »
Except 2.71MP actually exists. (Kind of)
315
« on: June 07, 2012, 02:21:20 pm »
A shell's job is to run other program (especially ones that can't run themselves) and that is exactly what his program does. Although it only runs one program, it's still technically a shell.
I noticed it more from a code standpoint. "bcall(_insertMem)" and "call $9D95" are dead giveaways of a shell.
Pages: 1 ... 19 20 [21] 22 23 ... 108
|
Show Posts