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 2 [3] 4 5 ... 135
31
« on: February 20, 2012, 07:42:47 pm »
By the way, Axe internally calculates sine by the following pseudo code:
Mod the argument X by 256 (Sine is cyclic) If X < 128 return X*(128-X)/32 (An approximation of a sine hump) If X > 128 return (256-X)*(128-X)/32 (An approximation of a negative sine hump)
Cosine is just sin(X+64) of course. Each of these use only a single multiplication so it's going to be fairly fast. If you want the result to be in the full range [-32768 to 32767] instead of [-128 to 127] multiply by 8 instead of dividing by 32 in your custom routine. Or for 8.8 format, just divide by 16 instead.
32
« on: February 20, 2012, 07:23:08 pm »
Well, one line acts as a "clock" and the other is the data bit being sent. The receiver never sends confirmation other than telling the sender to start and thus is necessarily delay based rather than confirmation based. This is because it is the fastest way to link and guarantees that neither calculator can freeze from dead-lock, interruption, or interference. However, I do want to overhaul the entire routine at some point because there are definitely cross-compatibility issues such as with 83+ to 83+fr.
33
« on: February 20, 2012, 04:59:55 am »
Oh, I see what you mean... I misunderstood. Although that could work, I can imagine somebody somewhere might want to read a nibble from the app page from a program and there could even be future uses with the Axe Fusion page. However, it probably benefits more people right now to change it, and it wouldn't have compatibility issues except in extremely rare cases. But even with a change like this, programs being ported to apps still need to make fundamental changes due to self-modifying code issues.
But I like the idea. I will probably make the change unless anyone needs to access a nibble in the $0000 - $7FFF address range from a ram program. Otherwise it'll be impossible to do without assembly so please let me know if you need to do this and object to the change.
34
« on: February 20, 2012, 02:28:39 am »
I have a suggestion that would make it a lot easier to make source code that compiles both to RAM and to Flash Apps. I think that nib{}r should be changed from a "read from flashapp" routine to a "read from executable" routine. That is, use the default nibble read routine when compiling to a RAM program, and the flash nibble read routine when compiling to an App.
I would do that, except what about reading nibbles from appvars etc. from an app? Those still need the other command and it would be way too complicated to auto-infer that during compile time.
35
« on: February 17, 2012, 05:03:03 am »
Was the problem of Pause 0 freezing the calc for 30-something seconds ever fixed, or does it still act like Pause 65536?
Thanks for bringing that up! I agree that its annoying, and so I have finally fixed the problem ![Smiley :)](https://www.omnimaga.org/Smileys/classic/smiley.gif) However, as a result, the timing of the pause has changed slightly. In the new pause, 0 is like the old 1, 1 is like the old 2, etc. Basically, it pauses one more unit longer than before, which is usually unnoticeable and so you won't have to change your code.
36
« on: February 16, 2012, 05:15:27 am »
A "do" without a "while" is a common way to infinite loop in a clean syntax: "do { ... }". I forgot if C supports this or not, but I have definitely seen it in some dialects of Basic. EDIT: Nevermind, I missed that you already suggested it
37
« on: February 13, 2012, 07:48:02 pm »
Hmm... it might be more convenient return the offset by default, considering that zStart is the only program really using the API right now anyway. Other programs would probably like to handle errors themselves too. The output will be something like the offset in hl and the name of that program in OP1, which might be a subprogram.
38
« on: February 12, 2012, 09:51:12 pm »
Yeah, that's because it's a "new" token and is sent to the token hook in a special manner that Axe doesn't handle. I didn't add handling for it because I wasn't entirely sure how to account for it without introducing other problems on calculators with older OSes, but I think I've found a way to fix it now. Do you mind explaining that a bit? I don't see anything in the code that would prevent new tokens from being used... Also you don't need to handle that case with Axiom names because Axioms are required to only contain the A-Z, a-z, and 0-9 characters anyway. This is just to ensure they are easily typeable, valid, and unambiguous.
39
« on: February 12, 2012, 09:38:09 pm »
o_PushPop5 is commented out because I currently don't have enough support in the optimizer to allow this optimization. It needs to be able to tell the difference between declared-static and unknown-static values to work. It should only optimize if they are both declared, or both unknown, but not a mix of the 2. Technically, this affects more than one of the optimizations, but this one in particular is easily found in practice while the other ones would not be (except in maybe extremely rare circumstances). This needs to fixed eventually, but I will need to rewrite the optimizer. For now, I leave it there to remind me. As for the o_PushPop9 and o_PushPop11 I had a mistake in the optimizer code that I forgot to update after I added value replacement peepholes. I fixed that error now. Runer, in case you're interested, it was adding the "P" to JRZ(4,WriteToAsmR2P) in WriteToAsmED. Thanks for the report
40
« on: February 11, 2012, 05:46:41 pm »
Yes, if its a static address. If its a pointer to data that your Axiom has added, you don't even need it at all since its done automatically with AXM_DATA.
Also, you probably aren't using this, but if you want it to return pointer to axiom code that you want the programmer to jump to, you'd have to use a replacement with REP_NEXT, but that's an advanced feature.
41
« on: February 11, 2012, 02:57:30 am »
If your axiom was for instance: ld hl,1 ret You would make that field "4" because the size of the command is 4 bytes long. The size includes replacement prefixes by the way if you use those. What most programmers do is add a .org 0 after the header, add a label to the end of the command, and then make this label the size field. At the end of the Axiom, you just add on $0000 to indicate there are no more commands. You might also want to check out MemKit.z80 in the Tools section of Axe for an example of how an Axiom should look. Good luck ![Smiley :)](https://www.omnimaga.org/Smileys/classic/smiley.gif) Also, L1 and L3? That seems excessive... I wonder why Kerm would need 1536 bytes of static Ram just to run calcnet, especially as these are the most common buffers assembly programmers use.
42
« on: February 08, 2012, 10:15:54 pm »
Maybe the problem is that you left Interrupts on? Interrupts should be off or custom when using the link port otherwise the OS might decide to alter the ports in the middle of the linking. Try adding an FnOff at the beginning of your program.
43
« on: February 07, 2012, 04:42:49 am »
Il ya une nouvelle commande pour cela, "stdDev()" (v1.1.2) ![Smiley :)](https://www.omnimaga.org/Smileys/classic/smiley.gif) :"Hello"[00]->Str1 :"Bonjour"[00] :"ABC"[00] :"123"[00] :For(A,0,3) : Disp stdDev(Str1,A),i :End
44
« on: February 06, 2012, 07:04:05 pm »
I have a fairly easy feature request to implement, and one that has been bugging me for a while but I can never remember to suggest it >.< Currently the Alpha toggle feature merely reads the current flag setting and allows you to change it. I propose it is treated like a preference and stored in the appvar, that way if we reset our RAM and reload Axe, it actually enables the lowercase instead of just leaving it off.
I thought programs like Mirage, Doors, and zStart already do that for you? I could add it though, it wouldn't be that difficult.
45
« on: February 06, 2012, 06:56:39 pm »
The problem with assembling to "Assembly" is that I would have to keep a list of the names of all the labels in the native subroutines somewhere, including the relative labels within each subroutine. This will involve thousands of bytes of data to keep a list of all the names, offsets, and code to process the new option somewhere in Axe, and I'm almost out of room as it is.
Pages: 1 2 [3] 4 5 ... 135
|