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 - Runer112
Pages: 1 ... 67 68 [69] 70 71 ... 153
1021
« on: September 24, 2011, 02:13:55 pm »
flipH(flipV(Pic1)) should work.
Axe says that these functions can't be used recursively  You would need to copy the data in between each flip
Look closer. 
1022
« on: September 23, 2011, 10:05:49 pm »
Moving buffer data around can already easily enough by copying 768 bytes of data. The main reason StorePic and RecallPic were added is because they produce more optimized code since they work with set buffers. If they allowed variable buffers, they would hardly be any more optimized than simply doing Copy(Buffer1,Buffer2,768). And in response to Darl181, having versions of StorePic and RecallPic that copy two buffers would actually be less optimized than two individual single-buffer copies.
A far more interesting request would be for routines like Copy() to be able to have 8 different versions of itself, for all the possible combinations of constant and non-constant arguments.
1023
« on: September 22, 2011, 08:16:07 pm »
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.
1024
« on: September 22, 2011, 06:40:18 pm »
alberthrocks: That is because you're trying to write data back to Str1, which is a part of the application. As I explained in my previous post, that isn't possible. You should instead write the data to RAM somewhere, in scratch RAM or in an appvar.
1025
« on: September 22, 2011, 05:18:19 pm »
Perhaps a better question Wellen: Are you using the correct copy of Axe 1.0.3? The official Axe 1.0.3 released by Quigibo has a big problem with multiplication that will undoubtedly break lots of calculations in Zedd. That is why I created this version to specifically address and fix this bug.
1026
« on: September 22, 2011, 05:15:01 pm »
When making applications in Axe, the only thing you can't do that you can do in programs is write data back to the application. Probably the two most common uses of writeback are to store data like options/high scores and to create an extra buffer with Zeros(768). Instead of storing such data inside of your application, you should create appvars in which to store the data.
1027
« on: September 21, 2011, 11:20:47 pm »
Now that there's a mode with interrupts, is perfect grayscale asking too much. 
I'd say perfect grayscale is a little out of reach. As it is, TI-Boy struggles on quite a few games just to attain a somewhat playable speed. Adding in a feature that would consume at least half of all CPU time would slow down emulation even further. It also wouldn't be compatible with sound, as that uses all the crystal timers. I guess for the few games that use very little processing power, if the user has sound disabled, perfect grayscale might be possible while attaining decent emulation speed. Granted I haven't tested many games, every game I've tested so far would not fall into this category.
1029
« on: September 21, 2011, 09:14:03 pm »
I know you can make an Axiom to control crystal timer-based interrupts, because I've done it before. But how fast do you need the timer to be? Because the hardware timers on the 15MHz calculators are actually based off the crystal timers and run at extremely precise speeds. If you just need to keep accurate time over a long period rather than do something many times a second with precise intervals in between, you should be just fine with the hardware timers. The exact speeds the hardware timers run at can be found here: [wikiti]83Plus:Ports:04[/wikiti]. The most regular speed is with the hardware timer set at the fastest setting (0) on a 15MHz calculator, which will run at (almost) exactly 512Hz.
1030
« on: September 21, 2011, 06:40:19 pm »
Technically the calculators have an 8-bit processor, as they have an instruction word size of 8 bits and the general use registers are each 8 bits. But that's not really important.
Regarding reprogramming Flash memory: In normal operation, writing to Flash can only be done by the operating system. However, even if this protection is disabled, you can't really use Flash memory as RAM. This is because you can't set bits in Flash by writing data normally, you can only reset bits. The only way to set bits is to order a sector erase, which destroys all data in a 64-kilobyte sector by setting all the bits in that sector. So if you wrote 0 to a byte in Flash memory, that byte could no longer hold anything except a 0 until you order a full sector erase.
1031
« on: September 21, 2011, 03:13:43 pm »
flipH(flipV(Pic1)) should work.
1032
« on: September 21, 2011, 11:11:42 am »
Freyaday, yes, that would be great.
But it should always backup BEFORE compiling
(sometimes it freezes while compiling apps!)
Axe doesn't back up before compiling because, if you made a lot of changes to a program and have introduced a number of bugs/compiling errors, you wouldn't want Axe to overwrite your old backup until all the errors have been dealt with and the program successfully compiles. Also, it is strange that Axe sometimes freezes for you when compiling apps. Does it actually freeze, or does it just appear to be doing nothing for 5-10 seconds? Because the step of producing the actual application can take a decent amount of time, during which Axe may appear to be frozen. But if Axe is really freezing, are you using the latest version (1.0.3)? If not, try upgrading your version of Axe. If you are already using the latest version of Axe and are encountering genuine freezes, not just slow performance, I suggest submitting a bug report with as much information as you can about what causes/caused a freeze. Axe should, after compiling an App, always check, if the new app exists, and if not, it should ask if it should try again, because axe made a mistake, or something like that!
Axe has never failed to create an application when I've tried to compile one. I don't think such an error handler is really necessary, since the error should never occur in the first place. If it does occur, you should try to give details about the situation as a bug report. And another thing is, that it should be possible to add a new line in a code
writing into the code of a program, a command like "newline(" is still missing
It should be possible to tell it "newline(20)" and it should add a new line after the 20th symbol in the code
I've been scratching my head for a bit in response to this feature request. Can you elaborate on what you are suggesting? A third thing:
A command like "GDB-grey("
It should be possible to show a GDB in greyscale, too. And it should be possible to controle, how dark every greyscale should be (like numbers from 1-10, 1 is white, 10 is black)
Because it's annoying if you have to try out, how often you must use DispGraph^r if you want to have a darker greyscale!!
Or if you neef one scrolling, and a non-scrolling greyscale-pic!!!
You can display any data you want as a grayscale image. In fact, it's now easier than ever to display grayscale images. This is done with DispGraph(image front buffer, image back buffer)r/rr. And regarding controlling the color of produced grays, remember that the calculator only has a black and white screen. It's pretty amazing that distinguishable grays can be produced at all.
1033
« on: September 20, 2011, 01:15:35 pm »
Can you elaborate on frozen scanlines? If it's grayscale but the diagonal scanlines aren't really moving, like this, that just means that the frequency of grayscale updates is near perfectly out of sync with the LCD's refresh rate, which isn't the fault of Axe. However, if you mean that the image shows up in black and white because the grayscale mask isn't being changed at all between frames, that would be a bug.
1034
« on: September 19, 2011, 03:24:57 pm »
Attached below is my patched version of Axe 1.0.3 with a corrected multiplication routine. As far as I know I didn't introduce any new bugs. I suggest that any Axe programmers who need fixed-point or high-order multiplication download and use this.
I know how much Builderboy has been aching to release Zedd, but he is held up because no version of Axe can safely/successfully compile it. 0.5.3 lacks a needed feature, 1.0.0 and 1.0.1 are too dangerous to use, 1.0.2 doesn't handle constants correctly, and 1.0.3 has broken fixed-point and high-order multiplication.
It's been about a month since the last release of Axe and I'm sure Quigibo has been very busy now that he's back in school. He's probably working on 1.0.4 in the background, but with his schoolwork I understand if progress is slow. I haven't heard any news about when 1.0.4 might be released, or even just a bugfixed version of 1.0.3. So I decided I'd try to help by fixing what I would consider the most major bug in 1.0.3, the broken multiplication. Long story short, I was able to locate the broken multiplication routine in the compiled application, edit the hex so it would properly work with fixed-point and high-order multiplication, and resign the application.
I realize that Axe is the work of Quigibo, not myself, so I don't plan on making releases like this a habit. But the multiplication bug was a somewhat big and unavoidable bug that was holding back a few coders' projects, and I wanted to give them the ability to continue their awesome work.
Attached below is my patched version of Axe 1.0.3 with a corrected multiplication routine. As far as I know I didn't introduce any new bugs. I suggest that any Axe programmers who need fixed-point or high-order multiplication download and use this.
1035
« on: September 18, 2011, 08:08:26 pm »
Don't count this project as down for the count yet. I'm sure it will be making a comeback eventually, and since I'm a much more skilled coder now than when I started this project, expect it to be faster/better.
Pages: 1 ... 67 68 [69] 70 71 ... 153
|
Show Posts
