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 ... 15 16 [17] 18 19 ... 135
241
« on: September 25, 2011, 04:59:09 am »
It should be fast enough to generate PWM sine waves if you use pregenerated look-up tables for the pulse times and delays instead of doing it on the fly. You might want to check this out too, this was made from a very old version of Axe before the optimized For(const) loops: http://ourl.ca/6372
242
« on: September 25, 2011, 04:04:56 am »
How did we get on the topic of #Realloc()? That has to do with changing where in memory the A-θ variables reference, not strings or MemKit. I meant you should use a different pointer argument for Print() that will result in the string being copied to RAM, since Str1 is a part of your application and cannot be written to. For example: Print(L₁).
Regarding appvars, unless you want data to persist between runs (like settings or high scores), I would try to use scratch RAM to hold your data whenever possible. As far as I know, you don't need this string to persist between runs and it's pretty small, at most 9 bytes, so it's probably easiest to use scratch RAM to hold it.
Oh... I was under the assumption that #Realloc() would cause the variables to be located in L₁ for modification. 
So wait, if I do use Print(L₁), will I still be able to use regular variables?
(Or maybe I just don't get where the variables are/how do variables work/etc. )
The variables are stored at the END of L1, not the beginning. Using the first 714 bytes of L1 is perfectly fine and encouraged. Its only the last 54 bytes that are freed during #Realloc() to expand the L1 buffer to the full 768 bytes so it can be used as a screen buffer. Hope that clears up your confusion. Also, no, there is no such command as ->nib{}r since you cannot write to ROM pages. The nib{}r command is ONLY for reading data from the app itself (your strings, sprites, data, etc). If you are reading nibbles from appvars, free ram, or other ram variables, you STILL use the regular nib{} command even in an app. As of 1.0.4, all apps generated by Axe Parser are non-trial 
243
« on: September 25, 2011, 02:20:55 am »
I could not replicate the "Bad Flash" bug no matter what I did or how hard I tried, but I did change it to an unknown error which can tell me more useful information about where the error occurred if you can post the error code.
I also could not replicate the random 'r' bug, but I did change around the string reading routine a little bit so that might fix it, although I don't have hope it will.
I suspect that both of these errors are related to other apps you have installed since I am not able to reproduce it on a clean calculator. DCS, zStart, and Omnicalc in particular create a ton of hooks and are the highest on my possibility list, but please tell me ALL of the apps you have installed when reporting one of these 2 bugs.
By the way, any major or minor bugs found in the next 24 hours I can patch up by Sunday. But after that, I won't have a lot of time for a while.
244
« on: September 25, 2011, 02:09:18 am »
Axe Parser
Omega 1.0.4
New Features:- Axe apps no longer delete themselves after 15 runs (thanks thepenguin77!)
- Horizontal and Vertical commands work on any buffer.
- Create buffers filled with any value.
- New pt-Get() routines for cloning sprites. (thanks calcmaniac84!)
Changed:- Fixed and optimized all multiplication.
- Fixed small bug with 4 level grayscale.
- Fixed returnr for apps.
- Zeros() token changed to Buff()
- Pointer calls now keep the accumulator preserved during the call.
- Lots of new optimizations! (thanks Runer112!)
245
« on: September 24, 2011, 09:45:34 pm »
I refuse to lose bytes and de-optimize!  Found an alternative the same size as the original: ld a,%11011011
or a
ld hl,flags+asm_flag2
inc (hl)
jr z,__Disp4LvlSkip
rra
ld b,(hl)
djnz __Disp4LvlSkip
rra
ld (hl),-2
__Disp4LvlSkip: | ld a,%10110110
ld hl,flags+asm_flag2
cp (hl)
jr z,__Disp4LvlSkip1
jr c,__Disp4LvlSkip2
ld a,%01101101
__Disp4LvlSkip1:
scf
rla
__Disp4LvlSkip2:
rla
ld (hl),a |
Its a pretty cool optimization. Instead of the mapping (-2:-1) (-1:0) (0:-2) the new mapping is now (equal:larger) (larger:smaller) (smaller:equal) with respect to the number %10110110.
246
« on: September 23, 2011, 09:26:55 pm »
Axe backs-up programs after compiling and not before due to the error scrolling bug corrupting very large programs. You don't want the corrupted version to overwrite your working one. Plus it wastes less time.
I added a new poll. The dilemma is that the freq command is affected by the mode of the program. So the command freq(200,4000) in 15MHz mode will be 2.5 times higher pitched and pause for 2.5 times less time. This can easily be fixed by just multiplying the numbers by 2.5: freq(500,10000) however then you need to write different code for each mode. The extra code would be about 7 bytes more and would include temporary interrupt disabling (another feature that I think should be added to it). One negative is backwards compatibility issues; tones in programs currently in 15MHz mode would be over an octave lower than before. Any thoughts/complaints?
247
« on: September 21, 2011, 05:37:51 am »
Sorry for being so busy, I will plan to have the next version out this weekend.
248
« on: September 04, 2011, 06:03:37 pm »
You're creating a new object (a thread) inside your class and calling one of its methods. I'm pretty sure you can't do that, you can only have code there to initialize variables. You can instead do "Thread myThread = new Thread(..);" and then in your constructor do "myThread.start();" Or just move it all to the constructor since you don't need the object after that.
249
« on: September 01, 2011, 05:23:53 pm »
That's a good idea Runer, I think I'll make that change. Shell calls are for the most part useless. Axe's routines are faster, more optimized and even smaller despite the fact that the actual routines are in the program itself due to the amount of extra register parameter juggling each call to the routine would have to include. The only time I could see this being useful is for calling code that is shell specific, like the DCS GUI functions. And even then, its much better to make shell calls Axioms because: - It can automatically choose the right routine based on the shell compiling for.
- It adds an input-output layer above the assembly for Axe compatibility.
- You don't have to memorize weird hex values or use asm in the source.
250
« on: September 01, 2011, 01:54:19 pm »
There is a subtle difference between (LFoo)() and Foo(). First of all, the second is more optimized, but more importantly, the 2nd one has the last expression in the accumulator whereas the first has LFoo. If Foo was like this:
:Lbl Foo
:+1->B
:Disp B>Dec
:Return
Then calling 5Foo() will print 6, but calling 5(LFoo)() will display the pointer of Foo plus one. Even when there's arguments, it will still keep the pointer in the accumulator when called that way.
There are only a handful of OS calls in the early address space. Most of these are either useless to game making or already implemented by Axe. Anyway, you wouldn't ever want to call them in an ugly way like that.
251
« on: September 01, 2011, 04:12:50 am »
That PDF was intended just for the pre-release guinea pig testers and was quickly written in just a few hours. I planned to rewrite it for the actual release but got lazy and released it as-is without proofing it again. Redundant statements are redundant This file will be removed in all versions after 1.0.4 anyway (stable), its just for those transitioning from 0.x versions to 1.x versions.
252
« on: August 31, 2011, 07:47:59 pm »
This thread is really out of date. Axe now comes with the Memkit Axiom (z80 source included, you should check that out) which handles all this stuff for you.
As far as your assembly; ld (de),(hl) is not a real instruction. You're going to have to use the 'a' register as an intermediate; ld a,(hl) \ ld (de),a which means your loop counter will have to change as well, you can use b for that which gives a you the djnz optimization as well. But yeah, here's the current routine for copying the name in Memkit:
;Input: hl = Pointer to vat entry
; de = Pointer to string buffer
GetName:
ld bc,-6
add hl,bc
ld b,(hl)
ex de,hl
Loop:
dec de
ld a,(de)
ld (hl),a
inc hl
djnz Loop
ld (hl),b
ret
253
« on: August 31, 2011, 01:40:31 pm »
Ah I see what you mean, so add a new command type bit that implies the token expects a parenthesis, that could work. Alternatively, and probably better, I could enforce these rules automatically by getting the string for each token at compile time and checking if it ends with a parenthesis. If it doesn't end in one, require one in the code if arguments are required. If it does end in one, throw an axiom error if using it in a 0 argument case.
254
« on: August 31, 2011, 01:19:57 pm »
How would you ever have 2 versions of a command that are 1 and 0 arguments respectively? That means it would be valid syntax to both end with a parenthesis or not end with one. If the token itself had an open parenthesis, it would be counter-intuitive that the parenthesis could never be closed in the 0 argument case, and if the token did not have an open parenthesis, it wouldn't make sense that you had to add one to close the expression in the 1 argument case. In other words, if you find yourself in this situation, you're violating the rules of the language.
255
« on: August 31, 2011, 04:23:37 am »
EDIT: Just wondering, will this work on the back buffer too? The one I posted is only a routine for the front buffer, but I can add a 5 argument version if you need that functionality.
Pages: 1 ... 15 16 [17] 18 19 ... 135
|
Show Posts