Show Posts

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 ... 48 49 [50] 51 52 ... 135
736
TI Z80 / Re: The World's Hardest Game
« on: October 21, 2010, 01:24:18 am »
The parenthesis is 2 ball sprites xored on top of each-other with one slightly shifted.  You likely initialized 2 sprites there by mistake instead of 1.  Cool game by the way :)

737
The Axe Parser Project / Re: Bug Reports
« on: October 20, 2010, 10:46:00 pm »
Before it always reenabled them for you by default, but I took that off for the case where you might have a dispgraph inside of an interrupt routine.  If the interrupts were to turn on automatically when they weren't supposed to for even just one instruction (before you have a chance to add the fnOff at the end) then horrible things can happen.

738
The Axe Parser Project / Re: Bug Reports
« on: October 20, 2010, 10:34:48 pm »
The dispgraph commands have an unfixable hardware bug that disables interrupts after a while when in im2.  You have to explicitly use an FnOn after dispgraph if you want custom interrupts to remain on.

739
Axe / Re: a couple questions
« on: October 20, 2010, 04:58:24 pm »
1. Files: They don't need to be closed.  They are always valid (if reading them succeeded) until garbage is collected/defragmenting.  This means that if you in order:

open an archived program to Y1
unarchive the program
modify the program
archive it again

Y1 is still pointing to the unmodified file since the new copy of the program is now copied to a different spot in rom.  For normal use though, if the file stays in archive its valid.

2. Axe doen't natively display token strings, it displays ascii.  The only time you might ever need tokens is reading and writing to programs.

3. Anything in ram is limited by the 8kb limit, but apps have a 16kb limit.

740
Axe / Re: Seeing Through Sprites
« on: October 20, 2010, 04:49:43 pm »
You can still have 4 level grayscale by using 4 level backgrounds and 3 level foreground sprites.  I think this is what the original game boy used for the same reason.  But be aware that when you use the Pt-Mask routine for monochrome, data will still be written to the back-buffer even when you're not displaying it.  So you can't use L3 to store additional variables and data structures since they can easily get corrupted.

741
Axe / Re: Lock programs with Axe?
« on: October 20, 2010, 04:35:41 pm »
It is redundant to get the NAME of the entry and then search the symbol table again to find the entry with that name using GetCalc()

The data pointer can be found at {entry-4}rr.  You can then add 2 to that pointer to skip over the size bytes in the data to mimic how the getcalc() works.

742
Axe / Re: Pong Bounce
« on: October 17, 2010, 10:07:20 pm »
If its full screen, its MUCH easier to just import the picture, no codes required.  Just put it in a picture variable and then do what nemo or ztrumpet suggested (depending on your needs).  The compiler will automatically convert the picture into data when it compiles as if you had the hex codes there.

743
The Axe Parser Project / Re: Axe Parser
« on: October 17, 2010, 05:29:21 pm »
Yes.  Y1 can only be used in a very narrow range of commands.  You can only reference them or copy them right now.  But in the future, any command which has the format command{} should work with files.

744
Axe / Re: Finding / listing programs
« on: October 17, 2010, 04:09:05 am »
What about pictures, strings, and lists?  Those have a E00-E09 byte built into their name and could incorrectly be read as a valid NL.  I'm not saying its impossible to do, I'm saying its impossible to do and have it work correctly in every possible situation.  I'm sure someone could have some kind of hacked variable or something that would break your system.

745
Axe / Re: Finding / listing programs
« on: October 16, 2010, 11:56:46 pm »
Like a linked list, it is impossible to transverse the list backwards.  You would have to start at the beginning again and then iterate through the list until you get to the N-1th item.  Generally this is pretty fast though unless you have over 9000 items on your list.  That's how the calculator "scrolls up" on your program list*.

*kind of becasue it also has to sort alphabetically.

746
The Axe Parser Project / Re: Axe Parser
« on: October 16, 2010, 09:16:16 pm »
Even smaller and more intuitive than this:
Code: [Select]
A xor B->A xor B->B xor A->A
Is this:
Code: [Select]
A-B->A+B->B-A->A
First, A' = A - B
Then, B' = A' + B = (A - B) + B = A
Then, A'' = B' - A' = (A) - (A - B) = A - A + B = B

So you've swapped the values without any extra variable usage, and the add and subtract operations are much less code since the 16 bit xor isn't built into the z80 instruction set.  But yeah, a temporary is still smaller and faster.  In the ARM architecture, they're actually the same amount of code and speed so you can do this with no penalty.

747
Axe / Re: Re-structuring Pictures
« on: October 16, 2010, 10:57:49 am »
That's not a bad idea actually.  It would be really useful in some situations to import data from entire programs or appvars like one of those Axe midi tracks for example.  And most of the code is already written, I would only have to remove the check for pictures and change it to a check for any valid object.  But I don't think anything else will use the r modifier for tilemap importing other than pictures because I can't think of a situation where that would be useful.

748
Axe / Re: Re-structuring Pictures
« on: October 16, 2010, 05:05:40 am »
Yes, but you will have to convert it to the other format yourself.  It takes 3 nested for loops to convert it which is what Axe does internally when you use the tile-map absorption option.

749
The Axe Parser Project / Re: On-calculator app signing
« on: October 15, 2010, 10:33:27 pm »
1. Yeah, you're probably right.  I wasn't really expecting to sign the app on-calc at the time I wrote that part so I agree, if app signing becomes feasible on-calc then of course I would have to fill it with FFs instead.  But yeah, it was mostly because I was trying to save one byte using an xor a instead of a load, not thinking about the consequences...  That's something I'll definitely change next version now that you mention it.

2. I was unaware of this.  I just looked it up on WikiTi I think and it seemed to work after that so I didn't think anything was wrong.  I guess I will also have to change that then.

3. No, I have never heard of that bug... do I have to add an extra byte to the executing code itself or can I tack it onto another field?  And is that size mod 64 including the signature and header?

4. Yeah, I used to have that bug in the compiler itself, but I fixed it one I realized that that was the problem.  But
Axe currently only allows single paged apps and so I don't have this situation when compiling.

750
The Axe Parser Project / Re: Axe Parser
« on: October 15, 2010, 07:15:06 pm »
The ex command is only 1 byte whereas loading a 16 bit register is 2 bytes.  And that statement could still be done like this:

Code: [Select]
:A->B->pi

Pages: 1 ... 48 49 [50] 51 52 ... 135