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 ... 43 44 [45] 46 47 ... 135
661
« on: December 11, 2010, 04:32:58 pm »
When you have a list of numbers, say you had {1,2,3,4,5,6} and you do Ans=3, it would test if each element is 3 so you would get {0,0,1,0,0,0}. 2(Ans=3) would give: {0,0,2,0,0,0} since every element gets multiplied by 2. 4(Ans=5) would similarly give: {0,0,0,0,4,0}. Adding each element together: {0,0,2,0,4,0} then doing a sum adds all the elements together so you'd end up with 6 as your answer.
Basically it is generating a random even number with a weird distribution where the average value is 6, minimum value is 0 and maximum value is 24.
662
« on: December 11, 2010, 08:05:43 am »
I think its 30,000 to unlock. Although the second one is harder, the fruit falls more slowly so you don't get completely overwhelmed. The last mode is my favorite one and wasn't in the original Pyoro, I invented it myself 
663
« on: December 11, 2010, 07:32:40 am »
The easiest way *not available until the next version* is to absorb them directly into the program.
Recall that when you have a title screen that takes up the whole screen, you don't want to have to type out the entire 1536 hex characters:
[123ABC...]
Instead, you can absorb an OS picture into the program simply by doing this:
[Pic1]
The same thing applies for tokens. If you want a string of tokens, then instead of doing:
Data(t1,t2,t3,tA,tB,tC,...)
You can do any of these:
[Ans]
[Str1]
[prgmABC]
[appvABC]
And the data will be directly absorbed into the program, depending on where you have your tokens stored (The one with Ans is kinda volatile, I wouldn't recommend that). To find the length of some data of unknown size, you can't use length() because its not necessarily zero terminated, and you shouldn't use it anyway since its a slow routine and you already know the pointers are static. Instead you can just subtract the start from the end of the data pointer.
:[Str1]->Str1
:[]->Str1E
:Copy(Str1,L1,Str1E-Str1)
664
« on: December 11, 2010, 07:12:46 am »
Yeah, variable reallocation will be available next release so it should be compatible with CALCnet.
Also, I think you mentioned on Cemetech that the On key detection was not working? I though the same thing initially because I was using wabbitemu which for some reason doesn't recognize the on key when pressed. But I've tried it on hardware and it seems to work correctly.
665
« on: December 11, 2010, 07:05:05 am »
Yeah, something like that. But I'm really only talking about for a 'public' release. The odds of having less than 15ish bytes left on your calculator is probably very rare. Any triple digit of bytes is rare for me at least. If you're just doing this to quickly test out the features or to generate a file like from a map editor then you really don't need the error checking since you're aware of the problem and know how to avoid it. Its only if other people use your program that you would want to check for errors.
666
« on: December 11, 2010, 06:37:31 am »
I wouldn't recommend using it that way because the routine can fail. If there were not enough memory to create the program, the pointer would be null and trying to copy data to the zero address would result in a crash.
667
« on: December 08, 2010, 03:40:41 pm »
Yeah, I'm going to have to add some auto optimizations for "and" "or" and "xor" and their 16-bit counter parts. I totally forgot about those.
668
« on: December 08, 2010, 03:37:23 pm »
The source code for all the commands is included with the download in the developers section.
669
« on: December 07, 2010, 03:04:27 am »
By the way, I should mention that I found some stupid bugs in the Axe app compiling that I'm in the process of fixing, it should make them finally signable on-calc without needing to flash a sector in the next version. I'm not sure if I would want to merge application signing into the Parser, but I would definitely like to include it in the tools section of the Axe suite with your permission once I get it working.
Also, I really don't want to mess with the certificate page. But if I understand correctly, couldn't that issue be averted by sending the app to the computer/another calculator and then sending it back? It seems like there would have to be some kind of mechanism to prevent that or the whole trial-run business would be pointless.
670
« on: December 06, 2010, 02:46:12 pm »
When you say "write to archive" you mean write to ram that the OS uses right? Because it is not possible to write to archive without some highly specialised and long inline assembly code. Axe itself can write to archive, but only when compiling applications and should not touch the archive section of the calculator.
It is definitely possible to screw up some operating system variables which can result in weird glitches and random freezes. Sometimes, these can go unnoticed for a while after you've already recompiled a new working version, so if you were experimenting with some memory code and it didn't work but didn't get a ram clear either, you might want to clear it yourself just in case.
EDIT: After reading your edit, this is definitely what happened. Also, DCS unarchives the source when you edit it and then re-archives when you're done, so it is likely that it got messed up while it was unarchived.
671
« on: December 05, 2010, 06:39:32 pm »
You have a for loop without a variable as the first argument. I haven't implemented external valued for loops yet.
672
« on: December 04, 2010, 11:53:52 pm »
I never saw anyone other than Quigibo use Delta or Gamma instead of Beta and Alpha before, though...
That's because its not standard practice, its kind of just an inside joke to extend the releases past beta.
673
« on: December 04, 2010, 07:08:11 pm »
I can help you write a routine if you can give me a better description of what exactly you need to do.
Here is a routine to add the first 2 arguments and store the result in the third. Each argument is a pointer to a little endian 4 byte number.
:Lbl ADD
:{r1}r+{r2}r->r4
:>{r1}r+{r1+2}r+{r2+2}r
:->{r4->{r3}r+1}
:Return
So This:
sub(ADD,oA,oC,oE)
Would do FE = BA + DC
674
« on: December 03, 2010, 05:48:58 am »
Now that I turned in my project and had it graded, I think I can upload it online. Here is the CPU I made. I spent a lot of time organizing it into subcircuits which is a really helpful technique. It's a 16-bit RISC processor with 4 registers and there's about 20 different instructions.
I also have a conway's game of life program that can be loaded into the rom. Its really slow since it has to go pixel by pixel so it takes about a minute for each generation at the fastest clock speed. The first 12 words of ram are the screen buffer. A good starting configuration to test is the first 4 bytes: 0x0000, 0x0040, 0x0050, 0x0060 which makes a glider. Feel free to use elements of this in your designs if you're having trouble with any part.
675
« on: December 03, 2010, 01:16:58 am »
But the problem is that I would need to keep a list of every program to backup while it compiles and I'm already just about out of memory without sipping into the extra pages. It would either have to be done in the middle of compiling or there would have to be a limit to how many sub programs could be backed up during a "full backup". I'm pretty sure I'm using the swap saferam area for parsing storage so the second option is more likely if I did decide to implement this.
Pages: 1 ... 43 44 [45] 46 47 ... 135
|
Show Posts