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 ... 45 46 [47] 48 49 ... 135
691
« on: November 24, 2010, 02:01:14 am »
In Axe, what precisely does DiagnosticOff and DiagnosticOn do? The documentation states that it turns off the run indicator, plus prevents 'Done' from displaying, but the run indicator is never on normally (I think). The User's Guide states that it leaves your code cleaner: in what way?
The run indicator crawls the ants every time you use an OS bcall in your program. There are a lot of Axe commands that rely on these bcalls like for instance getkey (without parenthesis) or archiving/unarchiving. Commands like these will indeed show the run indicator. For(X,0,9)
Lbl EX1
End
Goto EX1
It would go to the next cycle of the for loop. Whatever value X is at the moment will be the value it compares against to see if it should go to the next iteration. Lbl EX2
Repeat...
While...
If...
Goto EX2
End
End
End
It will restart the loop from the beginning, similar to what "continue" does in C. Goto EX3
Repeat...
While...
If...
Lbl EX3
End
End
End
It will jump to the middle of the loop. But probably the conditional statements for the Repeat, While, and If will be using variables you need to make sure are all initialized correctly if you want to just jump in and expect things to work. The only potential memory leak is if you try to jump out of a subroutine. So be very careful if you attempt some weird optimization with that.
692
« on: November 23, 2010, 09:44:13 pm »
You should call this game "Maxwell's Demon" 
693
« on: November 23, 2010, 09:41:35 pm »
I've writen a Scheme interpreter in Scheme before. 
694
« on: November 23, 2010, 03:04:40 pm »
The reason Sin and Cos are -128 to 127 instead of -256 to 255 is because that way, you can fit the result in a single byte. Also its only 1 byte more to multiply by two whereas it would be 4 bytes to signed divide by two.
695
« on: November 22, 2010, 05:45:23 pm »
Yeah, that would not work. It would select L2 and then L3 so by the end of that command, it would be at L3.
I might tack on a hash to the front of the token to indicate it is a compiler instruction rather than a language one to make it less confusing. When I get to adding custom icons, I can also do it the same way:
#Select()
#Icon[]
696
« on: November 22, 2010, 05:36:52 pm »
Okay, I think I can do it: Select(CONST) will be able to set where you want the variables in an Axe program from that point on in the program. You can use it multiple times in the same program to swap back and forth between different buffers to effectively increase the number of variables available to the programmer. The command is a compiler instruction and thus takes no memory in the executable so there is never a penalty to using it. Also, the variables will from now on be at the end of L1 by default instead of the beginning. That way, if you do move the variables, you will be able to use the full 768 byte L1 buffer by simply using L1 instead of having to use L1-56. Future optimizations might also be possible in the future if the variables are kept within that range.
YES! That is awesome! And I assume we can do something like Select(GDB0) as well? This is really convenient for me 
Yes, anything that can be evaluated as a constant (something that was defined already in the program) can be used. Also things like L2, or1 or E8000 can also be acceptable. Just be VERY VERY careful. You need to make sure you actually have 56 bytes to work with and you need to be absolutely sure you aren't accidentally sharing the same variable space with some other memory that needs it. Also, using dereferencing like oA will automatically adapt to the current space you are working with. EDIT: Good idea calc84maniac! I might do that.
697
« on: November 22, 2010, 05:24:38 pm »
Okay, I think I can do it: Select(CONST) will be able to set where you want the variables in an Axe program from that point on in the program. You can use it multiple times in the same program to swap back and forth between different buffers to effectively increase the number of variables available to the programmer. The command is a compiler instruction and thus takes no memory in the executable so there is never a penalty to using it. Also, the variables will from now on be at the end of L1 by default instead of the beginning. That way, if you do move the variables, you will be able to use the full 768 byte L1 buffer by simply using L1 instead of having to use L1-56. Future optimizations might also be possible in the future if the variables are kept within that range. EDIT: 1337th post! 
698
« on: November 22, 2010, 03:01:54 am »
can't you just press the B button to make an auto backup?
Not anymore. The B button now is going to be used to scroll in the program list to the first program starting with a 'B'. The new button will be 'Alpha' most likely. And yes, you can still use that to exploit BASIC programs for backup
699
« on: November 22, 2010, 02:18:28 am »
Did Today:Fixed Elseif bug Added new auto-optimizations Static data storable to variable pointer Backup only after finishing compile with no errors Compiling to apps always attempts a defragmentation App signature improved and resignable on-calc with external program Doing Tomorrow:Get started on absolute jumping/calling from Axioms/Internal commands Fix program menu bug Pressing alpha-character jumps to program in menu (some backup control keys will have to change) Fix sector boundary reading bug when reading from archive. Things are coming along great!
700
« on: November 21, 2010, 09:21:42 pm »
By the way, I fixed the bug with the signed division auto-optimization. It actually was doing the optimizations correctly, but it was still adding the signed division routine to the code anyway, even if it didn't use it.
701
« on: November 21, 2010, 07:06:49 pm »
I could make a counter for the app writing if you don't mind it taking about 20% longer, but I can't for the defragmenting because that's done by the OS.
702
« on: November 21, 2010, 02:39:09 pm »
Defragmenting and garbage collecting are the same thing, but in different regions in the ROM. Garbage collecting happens in the general archive where you keep programs and stuff, but defragmenting happens on the app space and swaps entire pages at a time.
Right now, I only force a defragmentation when overwriting an existing app. But now that I've got a few of these reports, it might be better to always defragment, just in case. I know it takes a while sometimes, but writing to flash is scary so I'd rather be safe than sorry.
703
« on: November 21, 2010, 02:06:45 am »
Coding marathon starting now!
I'll be coding every day for one week so that I can release Axe 0.4.6 by next Sunday. Every day, I will post the new features I have added so far and the ones I am planning to add the following day.
Did Today:
Fixed Comment Bug
Added New Axiom Tokens
OnKey support for getKey(41)
Doing Tomorrow:
Fix Elseif bug
Add new auto-optimizations
Static data storable to variable pointer.
Backup only after finishing compile with no errors.
704
« on: November 20, 2010, 10:58:01 pm »
Someone should write a quadratic solver. Maybe I'll do it if I have time.
Off topic, but Qwerty.55, your sig is bringing back horrible memories of quantum physics, having to solve for the energy levels of multi-electron atoms. The DE's got really really ugly...
705
« on: November 20, 2010, 04:10:31 am »
So you have a 3rd and 4th buffer in addition to the primary and back buffers L6 and L3? In that case, it would definately be difficult and maybe a bit slow. The easiest way is to get a 16 byte block of free ram, and then for each 8x8 subset of the new buffer copy the region there and then draw them with Pt-Mask().
Pages: 1 ... 45 46 [47] 48 49 ... 135
|
Show Posts