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 - Quigibo
Pages: 1 ... 42 43 [44] 45 46 ... 135
646
« on: December 22, 2010, 03:59:25 am »
Look-ahead parsing is used when looking at the getkey routine. So if the number inside the parenthesis is constant like getkey(15) it converts the key code into the correct "DKey code" as it compiles. On the other hand, if the number is not a constant, like getkey({L1+3}) then it evaluates the inside and performs the conversion at runtime using the slower routine. By the way, between my last post and this post, I finished the routine and tested it out; it works great!  8-level grayscale would be awesome, but I'm skeptical how good it would look on the calculator. Is that routine available online anywhere? Also, the programmer would have to fill the buffer with sprites themselves since the normal sprite routines don't use that buffer.
647
« on: December 22, 2010, 03:09:03 am »
@DJ, yes. You will be able to move them where-ever you want (including as part of the program itself). The only limitation is that this can't be decided at run-time, it has to be a constant address.
Another feature I forgot to mention that I'm working on now is getkey(X) with a variable argument. The routine is a little large (about 20 bytes) but I can see some useful application with this for things like customized keys in games, a piano keyboard, or a trackpad by dragging your fingers along the entire key pad which is something I've done before in BASIC.
648
« on: December 21, 2010, 10:51:50 pm »
Yeah, I don't remember when that was, but it optimizes better that way. When storing stuff to a constant pointer, it returns the stuff you stored. If storing to a variable pointer, it returns the pointer itself, or the pointer plus 1 if you're storing 2 bytes at a time.
649
« on: December 21, 2010, 10:45:40 pm »
The problem with a compile setting for size/speed is that generally, you want part of your code to be optimized for size and another part to be optimized for speed. This could be done with "speed-op" and "size-op" commands or perhaps a prefix for labels like "Lbl +LBL" indicates everything until the next label is optimized for speed and everything else by default is optimized for size. Any shared subroutines like multiplication are added in the second pass so if multiplication was flagged to be fast in one place, it would be fast everywhere else too since it has to add the huge routine to your code anyway, all the other calls should share it.
It would make the parser a lot bigger, but it has room. I'm almost full on the first page, but I still have about 10KB of extra room on the second page. Commands are data in the Axe app so they would go on that page anyway.
650
« on: December 21, 2010, 10:33:27 pm »
Yeah, I've been making a lot of progress. I fixed all the bugs that were present last version, and added a ton more auto-optimizations. Most programs are decreasing in size by about 1% which is actually pretty significant for not having to do anything at all to your existing programs. The new optimizations are mostly with comparisons (both signed and unsigned) and equalities. Also, I've been working on adding some new commands. One of which is the not() command which will finally be usable to invert the lower 8 bits and not()r will invert the full 16 bit number. Right now, I am working on variable reallocation. There should be a lot of new progress over the next few weeks since I'm on break. Axe 0.4.7 will be the last of the betas and after that, the final stable release will be complete with full Axiom support.
651
« on: December 21, 2010, 12:35:08 am »
By the way, in case anyone wanted to know, my current high scores from my calculator on each mode are:
Mode 1: 56800
Mode 2: 79490
Mode 3: 64600
652
« on: December 20, 2010, 06:39:20 pm »
I don't think push and pop are that good of an idea because of the stack thing. And all of those are only 2 hex characters of the Asm() command anyway. The exchange I am still thinking about, I'm trying to see how practical it would be and how many commands are actually safe to use and I could change some commands to use bc instead.
Thanks again for the optimizations of the equalities, those are very widely used in programs so its great to see those optimized. I extended your optimizations to equality comparisons against variables too which actually reduces the number of auto-optimizations I need to do since the general cases are smaller.
653
« on: December 20, 2010, 06:33:40 pm »
I actually have been working on an on-computer compiler for a while, but progress on that will remain secret until the calculator version 1.0.0 finally comes out because I don't want to delay that for a side project.
654
« on: December 20, 2010, 02:14:56 am »
Its identical to ldir, but from page 2 of the app.
655
« on: December 19, 2010, 06:15:30 am »
Sorry this is late, but I wrote a converter a while ago. http://ourl.ca/6263
656
« on: December 19, 2010, 05:02:16 am »
This is all of it I think. It won't compile because its missing some variable declarations, and it isn't used in context, but if anyone can write pseudo-code or something that would be enough. This is pretty complicated stuff.
657
« on: December 17, 2010, 08:48:44 pm »
The routine Axe uses does a 32b=16b*16b operation if you want to use that. HL contains the lower 16 bits of the result and DE contains the upper 16 bits if I'm not mistaken.
EDIT: Wait nevermind, its unsigned.
658
« on: December 17, 2010, 12:09:28 am »
Be very careful with the stack though because the "push" and "pop" commands use the same stack as the "call" and "ret" instructions. So if you call a routine, push something, and then return, you will crash the calculator since the ret is now returning to the address you pushed instead of the return address. Same thing can happen with pop. Make sure you match the number of pushes with the number of pops until you feel advanced enough to exploit some of those tricks. This was my biggest source of bugs when I first started learning z80. ___Stack___
| Main:
call Routine
MainReturn:
pop hl
ret
Routine:
push hl
ret
| ___Stack___
MainReturn
| Main:
call Routine
MainReturn:
pop hl
ret
Routine:
push hl
ret
| ___Stack___
MainReturn
HL
| Main:
call Routine
MainReturn:
pop hl
ret
Routine:
push hl
ret
| ___Stack___
MainReturn
HL
|
The error here is that when it gets to the return, its returning to the address HL instead of the place right after the call like it should. So whatever random address HL holds will be jumped to and likely crash the calculator. So you CANNOT write subroutines that push or pop arguments. There actually is a way to do this though using a callback in case you're curious. This one uses the ix register. Main:
call PushStuff
ret
PushStuff:
pop ix
;Do any pushing or popping you need here:
push hl
push bc
push de
;Then use this instead of a return:
jp (ix)
659
« on: December 16, 2010, 10:50:26 pm »
The best way to have multi-paged code is page calls. On the main page, you write all your normal code. But subroutines can be called off-page by special routines so perhaps they could be put on the other pages with the data. The reason I can't do this though is that the parser simply doesn't have enough memory left to keep track of all the multi-page functionality. The all data idea that calc84maniac is talking about seems like the only practical way at the moment. And just for the record, the reason I haven't implemented this yet is actually because its difficult for the compiler. Writing things to multiple pages of flash, additional parsing passes, creating new syntax, checking for errors, all while being compatible for all versions of calcs (which have different starting points for the app tables) is challenging and time consuming. If there are any assembly programmers who want to help me with it, I can post the app writing code if you're up for it, but I can hardly understand it myself since about a third of it is written by TI.
This is why I think a computer version would be much more efficient. But I think if I do end up doing that, it will look a lot more like C than Axe since the computer is fast enough and has enough memory to that I can automatically optimize the code so that you don't have to do all those weird syntax tricks like calling things with missing arguments or storing things after each other.
660
« on: December 11, 2010, 11:20:26 pm »
Maybe add music? That way you don't have to listen to it from youtube, you can just plug in headphones. Nice game by the way
Pages: 1 ... 42 43 [44] 45 46 ... 135
|
Show Posts