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 ... 72 73 [74] 75 76 ... 153
1096
« on: July 24, 2011, 12:10:29 pm »
Well leafiness0 supplied the image data, but I ended up supplying a lot of code. Everything you can see here in red was done by me, everything in green was done by leafiness0. 
1097
« on: July 24, 2011, 09:11:00 am »
It should eventually allow you to write code in a more natural way and then automatically convert it to code that is more "Runer Style" as I like to call it 
And I'll still find ways to optimize it.  But cool nonetheless. Although a lot of the optimizations I perform now are somewhat natural to me, it would be nice if Axe could perform a few of them itself. Even my own optimized code confuses me sometimes. Will this system be able to look over code that wouldn't affect the value in the registers? By that, I mean will it be able to optimize something like: 0→A
1→B
Into: ld hl,0
ld (A),hl
ld l,1 ;or even inc l if you can pull it off
ld (B),hl
1098
« on: July 24, 2011, 09:08:15 am »
I ended up helping writing some (read: most ) of the code for leafiness0 to make this awesomeness happen. So a lot of the code is probably my typical mess.
1099
« on: July 21, 2011, 12:49:27 am »
You might want to hold off for a bit longer until some bugs are fixed. Axe 1.0.0 and 1.0.1 have a nasty ability to sometimes muck up flash. I've heard of effects ranging from losing data in some sectors of flash memory, to having to resend the OS, to having to clear all memory altogether.
1100
« on: July 20, 2011, 08:15:04 pm »
The DS<( command can be useful for running an interrupt at a low frequency. On non-83+BE calcs, enclosing all the code in a subroutine running on a 512Hz interrupt with DS<(I,512) can be used to execute a block of code exactly once per second:
512→I
fnInt(I,0)
.Main program goes here
Lbl I
DS<(I,512)
.1Hz interrupt code goes here
End
Return
However, on the 83+BE, the timers aren't exact, so don't expect to be able to pull off perfect timing on it. If you're not using the timer for precise timing, you can use the following code. This solution should create an ~1Hz interrupt on any model:
fnInt(I,6→I)
.Main program goes here
Lbl I
DS<(I,{Full+1+Data(108,118)})
.1Hz interrupt code goes here
End
Return
1101
« on: July 20, 2011, 08:03:25 pm »
Although you can specify whatever number you want for the second argument, fnInt()'s second argument is always ANDed with 6. This means that the only meaningful second argument values are 0, 2, 4, and 6. The interrupts will then run at a frequency according to the chart below: | Freq argument | 83+BE Freq | All Else Freq | | 0 | 560Hz | 512Hz | | 2 | 248Hz | 227.55Hz | | 4 | 170Hz | 146.29Hz | | 6 | 118Hz | 107.79Hz |
1102
« on: July 20, 2011, 06:51:55 pm »
Some more bugs: - Axe doesn't recognize 00h as an invalid token when parsing.
- Zeros(0) should add zero bytes of data, not 65536.
- This has been brought up before, but apparently not dealt with yet. getKeyr should perform res appRetKeyOff,(iy+APIFlg) (that's res 7,(iy+28h)) after grabbing a keycode so this doesn't happen:
getKeyr has a slight problem, not sure whether or not it's worth fixing. The bit that is set to prevent 2nd + ON from turning off the calculator is still set when the program exits. If the program is simply run from the homescreen, when it returns, 2nd + ON does nothing. Although this effect can be reversed by doing something like opening a menu, it's still a slight problem.
- When listing Axe source programs and Axe backups, it doesn't appear that Axe ANDs the variable type of located variables with %00011111. This can result in backups being treated like source programs, having compile and back up options instead of a leading hash mark and a restore option.
1103
« on: July 20, 2011, 04:32:27 pm »
I know a maximum variable name length of 5 works out well for you because that makes each entry 8 bytes large, but in my experience so far 5 just isn't enough. I think 8 or 13 would be nice. Also, bumping two old feature requests: Can we have a feature like "Zeros()," but for any data. For instance, something like this:
Command(1,12) would be the same as [010101010101010101010101]
Command([56],4) would be the same as [56565656]
Command(127,6) would be the same as Data(127,127,127,127,127,127)
Potentially, this command could even be used for repeating sets of data. For instance:
Command([010203],12) would be the same as [010203010203010203010203]
Command("Text"[00],15) would be the same as "Text"[00]"Text"[00]"Text"[00]
So, what do you think? Could this be a command? I think it's a good idea, to avoid situations like this. 
I really like that idea. What about changing Zeros( (det() to something more universal?
I would suggest changing the token replacement to Block(). Feeding 1 argument would create a block of the specified size filled with zeroes. Feeding 2 arguments would create a block of the specified size filled with a specified value. Maybe you could even add a Block()r command for creating a block filled with a specified word while you're at it, although this probably isn't as necessary as a normal byte-filling block command.
Quigibo, perhaps implement B_CALL(_DelRes) somehow? It would probably have to be manually called by the user at their discretion, but it would be useful for people who want to use L2. And for that matter, B_CALL(_DelRes) should probably be a part of the interrupt setup, which it currently is not.
1104
« on: July 20, 2011, 01:33:58 pm »
1105
« on: July 20, 2011, 01:30:41 am »
Although it's easy enough to do manually, I (and probably others) would like to see randInt(). It would be especially cool if you could optimize it for constant arguments.
1106
« on: July 20, 2011, 01:10:28 am »
Yay, another bug involving a routine dealing with OS variables. In p_GetArc, it's possible that the VAT entry inside of the archived variable can span two pages, which isn't accounted for. It's unfortunate to have to add 9 bytes to account for a one in a thousand error, but it must be done. It doesn't have to be done after B_CALL(_LoadDEIndPaged) though, because Axe's archive access routines account for page overflows on their own. EDIT: An even worse bug, the routine doesn't even verify that the variable being searched for is archived in the first place! This has been fixed too in the second code block. p_GetArc:
.db __GetArcEnd-1-$
push de
MOV9TOOP1()
B_CALL(_ChkFindSym)
jr c,__GetArcFail
B_CALL(_IsFixedName)
ld hl,9
jr z,__GetArcName
__GetArcStatic:
ld l,12
and %00011111
jr z,__GetArcDone
cp l
jr z,__GetArcDone
ld l,14
jr __GetArcDone
__GetArcName:
add hl,de
B_CALL(_LoadDEIndPaged)
ld d,0
inc e
inc e
__GetArcDone:
add hl,de
ex de,hl
pop hl
ld (hl),e
inc hl
ld (hl),d
inc hl
ld (hl),b
ex de,hl
ret
__GetArcFail:
ld hl,0
pop de
ret
__GetArcEnd:
| | p_GetArc:
.db __GetArcEnd-1-$
push de
MOV9TOOP1()
B_CALL(_ChkFindSym)
jr c,__GetArcFail
dec b
inc b
jr z,__GetArcFail
B_CALL(_IsFixedName)
ld hl,9
jr z,__GetArcName
__GetArcStatic:
ld l,12
and %00011111
jr z,__GetArcDone
cp l
jr z,__GetArcDone
ld l,14
jr __GetArcDone
__GetArcName:
add hl,de
bit 7,h
jr z,$+7
res 7,h
set 6,h
inc b
B_CALL(_LoadDEIndPaged)
ld d,0
inc e
inc e
__GetArcDone:
add hl,de
ex de,hl
pop hl
ld (hl),e
inc hl
ld (hl),d
inc hl
ld (hl),b
ex de,hl
ret
__GetArcFail:
ld hl,0
pop de
ret
__GetArcEnd:
|
1107
« on: July 18, 2011, 03:04:37 pm »
If Deep Thought has interest in this project, he can continue it if he likes, at his own pace. If he doesn't want to continue it, that's his rightful choice. If you're intent on seeing it finished, instead of commanding him to finish it may I suggest asking him (nicely) if you can have the source and pick it up where he left off?
1108
« on: July 18, 2011, 02:22:03 pm »
In Axe, the logical operators are binary operators. 4 and 2 equals 0 in Axe.
1109
« on: July 17, 2011, 02:49:16 pm »
Actually the problem is that you can have labels and constants with the same name. The following is perfectly valid code:
Zeros(128)→°Map
Lbl Map
The address of the 128-byte map would be °Map while the address of the label would be ʟMap.
1110
« on: July 17, 2011, 12:23:36 pm »
Drawing text to the back buffer isn't possible with TI's text routines. Axe programs and just about every sane coder use TI's built-in text routines instead of writing their own to save a large amount of effort and size.
To write text to the back buffer with routines that only draw to the front buffer, you can do something fancy like back up 6 rows of the front buffer, draw the text into those 6 rows, copy those 6 rows into the back buffer, and then restore the rows on the front buffer. But that's a really roundabout way to draw text to the back buffer.
The alternative is to write your own text routine. Whether you do it in Axe or assembly, it will probably take up a lot of space, but if you absolutely must be able to draw text easily to the back buffer, this is the way to go.
Pages: 1 ... 72 73 [74] 75 76 ... 153
|
Show Posts