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 - Runer112
Pages: 1 ... 120 121 [122] 123 124 ... 153
1816
« on: November 01, 2010, 06:39:37 pm »
Well it took like three hours of stepping through the instructions one-by-one in wabbitemu's debugger, but I think I isolated and solved all the problems. 
1817
« on: November 01, 2010, 01:34:16 pm »
Yeah, that's a known issue with Mimas. You have to write "LD D, (IX+0)" instead.
Ah, thanks. I should develope on PC while Mimas' early Alpha phase.
5) How compare I the HL register by using something like CP?
This seems like the logical method to me: or a
push hl
sbc hl,reg16
pop hlEDIT: Don't do that, do this
1818
« on: October 31, 2010, 07:30:34 pm »
Yeah, sound's been on calcs for quite a while. You need a 2.5 mm headphone, but you gotta find the right one. I don't know where to find ones that will work, though.
The easiest thing to do is use normal headphones with a 2.5mm male to 3.5mm female converter. The converter should only be a few dollars, and you can probably find one at a Radio Shack (that's where I got mine) or a similar store. You can buy one online too. A warning though: make sure it will actually fit into your calculator! The one I got just barely fits into the link port of my TI-84 Plus SE. If it were any larger I'm sure it would not have fit.
1819
« on: October 31, 2010, 07:18:00 pm »
Could you add some sort of system that would allow users to choose what tokens result from characters or character combinations that could represent more than one thing? I was recently using your program, which is great by the way, to edit an Axe source file that someone sent me. However, when I opened the file and then recompiled it without making any changes, the output file wasn't the same and resulted in errors when compiled with Axe parser. After writing another program in Axe to search through the two programs on-calc byte-by-byte to find any differences, I found two culprits. An apostrophe character was being converted into BBD0 instead of the expected AE, and "<<" (the signed less than or equal comparison for Axe source files) was being converted into BBEB instead of the expected 6B6B. SourceCoder handles this problem by using characters or character combinations enclosed in curly brackets (like "{L1}") to define some special tokens, and characters not found on a keyboard (like "≠") to define others. TI's Program Editor that was bundled with older versions of TI Connect handles this problem by using a custom font that replaces unused characters (namely accented letters) with the symbols needed to form the tokens (like "▸"). Both of these require a selector to pick these special tokens, which may be the way to go. Personally, I would use a custom font and form special characters out of the same character combinations you already defined, but let the user undo the combination. For instance, if I wanted the L1 token, I would type "L1" which would be changed to "L 1" as soon as I type the one (the small 1 would replace an unused ASCII value in the custom font). However, if the user wanted the literal string "L1" they could use ctrl+z to undo the combinaton. In this manner, the whole file couldn't be updated each time the user typed a new character, or it would keep changing user overrides back into special characters. I don't know how difficult it would be to do this, but the fix would probably be to only try to form special characters out of text the user just typed or pasted.
EDIT:I'm planning to write a program that will compile Axe source to z80 assembly code. That way it could be optimized, edited, etc.
Wouldn't you just be rewriting Axe parser? That wouldn't be very fair to Quigibo. If you want to hand-optimize compiled Axe programs, I guess you could compile source files with Axe in an emulator like wabbitemu and then transfer the compiled programs back to your computer and disassemble them there. I personally think that would undermine the spirit of using Axe, but you may feel differently.
1821
« on: October 31, 2010, 05:13:57 pm »
Okay, I am looking for a PROGRAM (not online converter), that will convert 8xp files back into text. If I have to I will make one myself but I don't want to.
I don't think that exists/is possible.
I believe a few exist. Tokens for example is a project currently being developed by merthsoft right here at omnimaga. EDIT: Didn't you just post in that thread a few days ago ScoutDavid? Lol 
1822
« on: October 31, 2010, 12:13:53 pm »
This one has AI It's not very good, but it beats playing yourself lol.
1823
« on: October 30, 2010, 08:11:33 pm »
I think it's been long enough that I can safely double post Bit routine optimizations! Please tell me if any of these wouldn't work correctly, as I wrote them myself and I'm not a terribly experienced assembly programmer so that's a definite possibility. p_GetBit0:
.db 5 ;5 bytes, 36 T-states
add hl,hl
ccf
sbc hl,hl
inc hl
p_GetBit1:
.db 6 ;6 bytes, 47 T-states
add hl,hl
add hl,hl
ccf
sbc hl,hl
inc hl
p_GetBit2:
.db 7 ;7 bytes, 58 T-states
add hl,hl
add hl,hl
add hl,hl
ccf
sbc hl,hl
inc hl
p_GetBit6:
.db 7 ;7 bytes, 37 T-states
ld a,h
rra
rra
ccf
sbc hl,hl
inc hl
p_GetBit7:
.db 6 ;6 bytes, 33 T-states
rr h
ccf
sbc hl,hl
inc hl
p_GetBit8:
.db 6 ;6 bytes, 33 T-states
rl l
ccf
sbc hl,hl
inc hl
p_GetBit9:
.db 7 ;7 bytes, 37 T-states
ld a,l
rla
rla
ccf
sbc hl,hl
inc hl
p_GetBit10:
.db 8 ;8 bytes, 30/29 T-states
bit 5,l
ld hl,0
jr z,$+3
inc l
p_GetBit14:
.db 7 ;7 bytes, 37 T-states
ld a,l
rra
rra
ccf
sbc hl,hl
inc hl
p_GetBit15:
.db 6 ;6 bytes, 33 T-states
rr l
ccf
sbc hl,hl
inc hl
| | p_GetBit0:
.db 5 ;5 bytes, 27 T-states
xor a
add hl,hl
ld h,a
rla
ld l,a
p_GetBit1:
.db 6 ;6 bytes, 38 T-states
xor a
add hl,hl
add hl,hl
ld h,a
rla
ld l,a
p_GetBit2:
.db 7 ;7 bytes, 49 T-states
xor a
add hl,hl
add hl,hl
add hl,hl
ld h,a
rla
ld l,a
p_GetBit6:
.db 7 ;7 bytes, 26 T-states
ld a,%00000010
and h
rrca
ld h,0
ld l,a
p_GetBit7:
.db 6 ;6 bytes, 22 T-states
ld a,%00000001
and h
ld h,0
ld l,a
p_GetBit8:
.db 5 ;5 bytes, 27 T-states
xor a
ld h,a
add hl,hl
ld l,h
ld h,a
p_GetBit9:
.db 6 ;6 bytes, 38 T-states
xor a
add hl,hl
ld h,a
add hl,hl
ld l,h
ld h,a
p_GetBit10:
.db 7 ;7 bytes, 49 T-states
xor a
add hl,hl
add hl,hl
ld h,a
add hl,hl
ld l,h
ld h,a
p_GetBit14:
.db 7 ;7 bytes, 26 T-states
ld a,%00000010
and l
rrca
ld h,0
ld l,a
p_GetBit15:
.db 5 ;5 bytes, 20 T-states
xor a
ld h,a
inc a
and l
ld l,a
|
Other optimizations: - The signed less than zero comparison (p_SLT0) can be optimized to the optimized p_GetBit0 above.
1824
« on: October 30, 2010, 12:35:30 pm »
By the way, if you're worried about this overwriting variables that you use for other things, which it most probably will, you should back up all your variables and then restore them after this is done. You can do this by copying all the variables (which occupy 54 bytes starting at E86EC) to another place in RAM before running this and then copying them back after it's done. Just don't copy them to the end of L1 because I use the last 8 bytes of it for temporary sprite data. You can always move my temporary sprite data somewhere else if you want though, just replace the two references to E89EC-8 (the last 8 bytes of L1) with some other location. EDIT: I just remembered that I was using a fairly complicated sprite-drawing loop to draw the center line because it used to be drawn as a white line on a black background, but it's now drawn black on white and just inverted later. I couldn't use the Line() routine before, but now I can. If this program is compiled as a part of one that already uses the Line() routine, the attached file will be more optimized.
1825
« on: October 30, 2010, 12:31:24 pm »
On a related but not related note, how large are the Rect(), RectI(), Rect()r, and RectI()r routines?
Rect(): 114 bytes RectI(): 114 bytes Rect()r and RectI()r are just modified calls to the Rect() and RectI() routines, respectively. ...How big are the sprite routines?
Pt-On: 126 bytes Pt-Off: 134 bytes Pt-Change: 126 bytes Like with the rectangle routines, back buffer calls are just modified calls to these routines.
1826
« on: October 30, 2010, 12:39:02 am »
Enjoy Subtract the header and the size of the Pt-On() routine and it's only slightly larger than 2 pictures!
1827
« on: October 29, 2010, 08:41:01 pm »
Lbl 22
Return *22
Wow...didn't know you could do that. Thanks!
And also; what if I didn't need the r? Would it make a difference?
Yeah, in Axe commands don't need to be directly linked. Evaluating <exp> would put it's value into what you could call the "Ans of Axe" (the hl register), and you can act upon that value whenever you want. It doesn't have to be in a command on the same line, or in this case, even in the same general area of the program. You can do some pretty crazy stuff using this. The most basic example would be something like this: 0→A→BYou're not actually saying 0→B, but because storing variables doesn't overwrite the "Ans of Axe," the value will remain and can be put in B. If you want to see a more advanced use of this, take this code for example, which I'm using in what I'm working on now: Vsub(DM3)
...
Lbl DM3
abs()-{r₁}
ReturnThe absolute value command doesn't even have an argument! But it doesn't care, it will operate on whatever is in "Ans." Entering an expression or value inside the parentheses would be a more logical way to put a value in "Ans" for the command to operate on, but if you don't enter anything there, "Ans" will simply stay as it was before the command was reached (in this case, with the value of V) and the absolute value of that will be calculated. Also, adding the r to subroutine calls bloats the call a fairly large amount. Calling a subroutine always costs a base of 3, but without the r modifier, each argument takes 6 bytes, whereas calling a subroutine with the r modifier costs 15 bytes for each argument.
1828
« on: October 29, 2010, 07:28:20 pm »
random question: is it worth it to put this code in a subroutine?
<exp>*22+GDB0+<constant>..... so it looks like sub(0r,<exp>,<const>).....lbl 0 : r1*22+GDB0+r2
I would almost always need the r when calling this routine, and I suspect that the size of calling sub(lblr) with two arguments to be loaded might be bigger than just typing it out every time. Can anyone confirm? Also, I will be using this snippet of code only around 15 times throughout
If you use a line with that format only once or twice, it would be optimal to just to type it all out in those instances. If you use it more than twice, the most optimized way would be as follows: <exp>sub(22)+GDB0+<constant>
Lbl 22
Return *22
EDIT: So as not to double post, I'll add this as an edit. It is, however, completely unrelated. For his purpose of parsing, during which key inputs aren't checked, it won't matter if he overwrites that. Although if he didn't want to overwrite it, I'm sure 1,093 bytes would be just as good. I've filled these 1,094 bytes of RAM with random data a few times before to see if it affects anything, and the calulator runs fine. I've actually been using the calculator to do other stuff since then, with this area of RAM having been filled with garbage, and no side affects have cropped up.
EDIT: Or, just to be safe, I remembered that Iambian mentioned something about this on IRC a while ago (here) when I was considering using this area as temporary storage:
[22:19:28] <Runer112> yeah, appdata is 8000h
[22:19:29] <Iambian> You're free to use that area regardless.
[22:19:44] <Runer112> appdata is completely safe for my purposes? whether or not i'm running an app?
[22:19:52] <Iambian> Thought you were talking about something that looks more important, like baseAppBrTab or something.
[22:20:21] <Iambian> Either way, this magic romcall that (I think) BrandonW found recovers most of it before you want to exit. bcall($5011) it is.
[22:20:52] <Iambian> It was noted in my source as "restores first 1087 bytes in RAM" If you don't have a solid understanding of what a RAM area is used for, when it's used, and what the consequences might be of modifying it, how can you say whether it's "safe" for your application?
(Experimenting and finding things that seem not to crash is really not a substitute for this level of understanding. To wit: I can infer from your comment above that either you have an 84+, or you never use Flash apps.)
"Restores first 1087 bytes in RAM" is cute, but wrong, and frankly, kind of a dangerous thing to go around telling people.
The term "safe" is meaningless without context: what is safe depends both on what type of program you're writing - i.e., the context in which it will be executed - and on what your program is going to do. By safe, we generally mean that
(1) a RAM area is not going to be modified by any system or library calls we intend to perform, or by the system interrupt routine, and
(2) the RAM are is not already in use at the time our program runs (so altering the data there will not have any effect on the system), or more specifically, it won't be expected to contain valid data at the time our program exits.
In some cases we may also want to consider areas where the RAM is already in use, but
(a) it can be easily reset to its default settings,
(b) we can reliably ensure the reset routine does get called, regardless of when or how our program terminates, and
(c) the user won't mind us trashing his or her data.
In brief: the RAM areas between 8000h and 843Dh (I'm going to go ahead and assume you didn't mean to include kbdScanCode and friends) are used by a lot of different system routines under a lot of different circumstances. As far as I know, all of this memory except for baseAppBrTab is scratch memory (it satisfies condition 2 for most execution environments), but whether it satisfies condition 1 is dependent on what system routines you're using, what hooks those routines might call, whether APD is possible, and whether silent linking is possible.
As for baseAppBrTab, it does not satisfy condition 2 at all, and it is absolutely essential that the table be correctly populated when your program exits. Realize that the primary purpose of the table is for performing application B_CALLs - so really, it ought to be correctly populated at any time when a hook might be called, or in a shell program, at any time when a shell library might be called. In practice, using that area is so dicey that I would not feel comfortable doing so at any time when any code outside my control might be executed.
You were right, I did accidentally look over the fact that baseAppBrTab is present in this area of RAM. That's why I later searched for Iambian's reference to bcall($5011). I know it does not "Restores first 1087 bytes in RAM," and I'm sure Iambian does too. But it restores the data in baseAppBrTab. As long as this bcall was called after use of this RAM area and hooks/interrupts didn't try to use it while you were (which I believe should be relatively easy to ensure), it should be okay to use it. I also did know that a lot of the other data areas in there were used by system routines, but for the purpose of parsing, during which I would assume very few bcalls are used (key input bcalls are included in those not used), it would be okay to fill these areas with your own data. However, I did completely forget one very important thing: Axe is an application. So it probably shouldn't be using baseAppBrTab at all. Or ramCode for that matter, located at $8100. So you're right, now that I think about this again, this area of RAM isn't entirely safe to use. Although appData (256 bytes starting at $8000) and tempSwapArea (323 bytes starting at $82A5) are large blocks that should be safe to use.
1829
« on: October 29, 2010, 05:37:00 pm »
The hardest part is making a routine to draw horizontally and vertically symmetrical sprites of arbitrary size correctly, so you'll only need one quarter of the data you would otherwise need for the star and explosion images. But it's coming along.
EDIT: Now the hardest part is converting about 800 bytes of picture into 100 individual 8x8 sprites.
1830
« on: October 29, 2010, 04:44:22 pm »
In case you were wondering, I've been working on this for you FinaleTI. So far I have the first 9 frames done at only about 800 bytes. With things like the header and the Pt-On() ignored, as these would already exist if it were part of your larger program, it's more like 650 bytes.
Pages: 1 ... 120 121 [122] 123 124 ... 153
|
Show Posts