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 ... 4 5 [6] 7 8 ... 153
76
« on: January 10, 2016, 06:44:16 pm »
The problem he's having is that Gemini is ridiculously large. On a completely wiped calc, there's only a few hundred bytes of wiggle room of RAM. If you have just a few dozen archived variables, their VAT entries consume these few hundred bytes and you can no longer run Gemini. I remember that I had this problem too, back when I was in school. So, now that I know how, I decided to do something about it. I dove into the source of Gemini and made a couple of optimizations. Namely, I reduced two trig tables from five quadrants each to just one quadrant each and wrote code to implement the mirroring. But this slowed the program down a bit, so I also took some time to optimize the speed of some core routines until it ran as fast as it used to. Hopefully I didn't introduce any bugs. I barely tested it, so it's entirely possible. But since you're eager to play the game, you can test it for me! 
77
« on: January 06, 2016, 06:48:54 pm »
Unfortunately, many of the "best" Game Boy games (ex. Pokemon, Link's Awakening) are too large to fit on a TI-84+. You'd really just have to use trial and error, finding ROMs for games that interest you and checking that they're 256KB or smaller. Metroid II and Super Mario Land are possibilities.
As for freeing up RAM: archive all the things, and use a shell such as DoorsCS or zStart to run archived programs. If everything is archived and you don't have any random stuff hanging around in RAM (might want to RAM clear after archiving everything you want to save), you should have enough RAM for just about any game.
78
« on: January 06, 2016, 06:40:13 pm »
79
« on: December 15, 2015, 10:30:41 am »
80
« on: December 15, 2015, 12:17:54 am »
Since this thread has seen a resurgence in popularity and I've actually watched a dozen or so animes now (don't judge me, baka), I may as well pipe in. I'm still fairly new to anime, so I've been starting with the more popular ones. Sorry if you've already seen this! My most highly rated anime so far is Spice and Wolf (Ookami to Koushinryou). For me, it was the perfect combination of economics, history, fantasy, romance, and thrill. Perhaps this is just because I'm particularly nerdy, but I found that the economics and trading provided more drama and thrill than any fighting. The characterization and the dub were amazing, and I imagine the sub is, too. The leading female role is a beautiful fox godess, but this is not a furry or ecchi anime, so that's just a pleasant bonus. My only gripe was that it ends so soon, after two seasons, without a satisfying ending that wraps things up. I guess that's because there was no wrap-up at that point in the source material, which could've probably gone for another four seasons or so.
81
« on: December 13, 2015, 06:02:27 pm »
Is there any useful uses of it?
I am assuming that the OS has a flag for whether the enter key is pressed on the home screen.
It there a way I can "activate the flag" and execute anything it has.
I am looking for a way to implement floating point math (It doesn't have to be fast) into my editor as a feature.
Basically I am tired of quitting my program to do a math operation on the home screen. (and I don't want to do long math in my head)
Thanks!
(the whole home screen is a program thing BLEW MY MIND)
However you'd end up doing such a thing, you'd need some things beyond the capabilities of pure Axe. My inclination would be to let the user select a line, or some more specific selection, and then press a button to request that it be replaced with its evaluation. I've never done anything like this before, but it might work something like this (DISCLAIMER: COMPLETELY UNTESTED): - (Optional) Save the value of Ans. This gets rather tricky for lists and matrices.
- Create a temporary equation with the same size as the selection. The clean way to do this in assembly would be to use B_CALL(_CreateTempEqu). But a pure Axe solution would be to use a fixed temporary equation name, like [03FFFF00], and create it with GetCalc(<name>,size).
- Copy the selection into the temporary equation.
- Install an error handler around the next step in case an error occurs while parsing the equation. DrDnar's axiom meant for running assembly programs seems to provide this functionality.
- Execute the temporary equation by putting its name in OP1 and using B_CALL(_ParseInp) (in Axe: <name>Asm(E7EF9B4A)).
- If an error occurred, handle it as you wish. Perhaps append "=ERROR" to the selection.
- If no error occurred, convert the result to a string representation. Thankfully, Mateo recently demonstrated how this could be done. In Axe (returns a pointer to the variable's size word): Asm(210000EF2443D5EF6949EF524BEFAB49EF6C49E1).
- If no error occurred, delete the selection and insert the result's string representation into the program at that location.
- (Not sure if necessary) Clean up temporary variables with B_CALL(_CleanAll) (in Axe: Asm(EF5041)).
- (Optional) Restore the original value of Ans.
82
« on: December 13, 2015, 02:58:38 pm »
While debugging my program editor I opened a weird file (it uses the VAT to select a file) and it contained my last entry.
After experimenting with it I found that I could access it with a Getcalc([0523]) -> var and that modifying it did indeed modify the OS's last entry. (It seems to use tokens to store data.)
Is there a way to execute this modified entry so I can use the OS's math or run a program? (or just reset my ram)
I love poking into places that I shouldn't! 
As it seems you have discovered, the home screen entry is implemented as a specially named program that you edit directly on the home screen, and it is executed when you press enter. But outside of this program's special connection to the home screen, there's really nothing special about it. You can do anything with it that you can do with any other program. However, I'm not aware of any way to execute BASIC programs (which is more or less what the home screen entry is) from Axe.
83
« on: December 09, 2015, 07:10:32 pm »
Hrm... Relloc(A) gives an error.
You're redefining the base pointer for the letter variables, which should be a constant, and A is not a constant. Is there a way to access the OS's unused spaces?
When I downgraded from 2.55 the new os took up 200k less space.
Is there a way to access this unused space (my available archive didn't go up when I downgraded)
I'm not sure where you got the 200KB number from; if you're referring to the fact that the 8xu file is larger, those files are roughly twice as large as they would be on an actual calcluator and they contain varying amounts of filler blank data, so don't trust their file size differences to tell you much. Regardless, you didn't see your available archive space change because there's a fixed size allocated for the OS for simplicity and compatibility reasons. A "larger" OS will simply take up more of this space. It won't eat into archived variable and application storage. Theoretically, you could store data in the unused space allocated for the OS, but not in any way that the OS would be able to recognize variables or applications. You'd essentially be patching the OS. And unless you've got a really good reason to be doing so, you probably shouldn't be patching the OS.
84
« on: December 09, 2015, 05:49:17 pm »
I was just curious if there was a way to reuse letter variables.
Reallocating the letter variables does give you a full new set of variables backed by different memory (provided you used a location that doesn't overlap with the default). But if you want extra variables, I would suggest instead making use of named constants/variables. You can define a constant like L1→°MyVar, and then for the rest of the program, MyVar will be a variable stored at L1. You can do anything with it that you can do with a letter variable.
85
« on: December 09, 2015, 04:51:59 pm »
In what context might a "modular program" be useful? Note that you'd also lose the ability to call functions, including all of Axe's built-in functions, which would really restrict what useful things one could do. You could possibly do more useful things with assembly, which seems to me like the more appropriate langauge in which to do tricky things like this anyways.
86
« on: December 09, 2015, 11:32:15 am »
Is there an equivalent of pop and push for axe?
In general, there isn't. And this is for a number of reasons. To name a few: it's too low level of a concept to belong in a compiled language; checking if pushes match pops could prove tricky; the compiler uses the stack for its own purposes and would often interfere with the user trying to use the stack; and, although Axe isn't currently good enough, a good optimizing compiler would use the stack like you're imagining anyways. However, when posed with requests like this long ago, Quigibo thought of a great implementation for simpler cases that avoids all these problems. Select(A,B) is a command that simply returns A. Each arguments to a built-in Axe command/function except the last is saved by being pushed onto the stack, so A is pushed onto the stack after being evaluated. You can then perform any single expression in B, the result of which is kept in hl. Finally the body of the command is executed, which simply performs pop hl to restore the value of the first argument. Realloc( doesn't seem to do anything.
If you mean it doesn't correspond to any compiled code, that's correct. It redefines the pointers to the letter variables, and changing these compile-time values doesn't result in any runtime code. If you mean it literally doesn't do anything, then that's a bug. But it seems to work for me in both Axe 1.2.2 and 1.3.0.
87
« on: December 09, 2015, 10:17:45 am »
[8:31:56 AM] c4ooo @runer do you think it will be possible to add #org() command specifying the call ofset?
[8:34:17 AM] c4ooo #org() - change org to default #org(int) - change org to int #rel(0/1) to force relative addresses to be used (1) / not used (0)[and give an error if needed]
It may be possible to allow changing of the code origin. Out of curiosity, what did you want this feature for? However, I don't think a position-independent mode would be feasible. The CPU doesn't provide any instructions to support relative calls or memory accesses, and the only instructions that support relative jumps have a limited distance. For the 2nd options page one option should to have zoom compile as default.
(Although 1.3.0's compile time is awesome anyways)
Also compile to archive would be cool also.
(so I don't have to archive a program after I compile it)
The ability to see hidden programs' names correctly would also be nice.
(Having my program's name start with some random character can make it sort of hard to tell them apart)
Although I am certainly looking for useful options to fill out the options menu in Axe 1.3.0, I'm not sure how I stand on a default zoom compile option. It doesn't save you any keypresses when compiling, you just have to press a different button to start compilation. I do somewhat like the idea of an option to archive compiled programs. But I say "somewhat" because having your programs always archived does naturally feel more secure, but then I realize that if your program is buggy and crashes, do you really care about preserving it? Presumably, your next step will be to modify the source, either to attempt to fix the bug or add debug statements, and recompile anyways. Regarding hidden programs, they're not a feature of the OS, just a hack of modifying the name to start with a strange character. And why would you want to hide an Axe source program, anyways? I can't see much benefit to having hidden Axe source programs, and without that, I don't see any reason to bother properly handling them. Please feel free to try to add extra information to any of these ideas to sway me more towards supporting them. Despite how I may sound, I am open to additions, but I'd like to be fairly convinced that they will be worth it.
88
« on: December 06, 2015, 04:06:45 pm »
It works!
I finally understand why each of the free ram variables have a name under them!
Since L5 (textShadow) is 128 bytes each one should holds a value for each number on the screen!
And it is corrupted by ClearHome because ClearHome is the same as Fill(L5,128,0) and the same is true for L6 and ClearDraw
(My life has meaning now)
Is all of my information correct (I posted as soon as I saw this because I was excited)
Thanks SO much! 
(increases karma)
Yes, all your information is correct. I always thought the wording in the command list about how certain things "corrupt" was rather strange, but you've got it.
89
« on: December 06, 2015, 02:37:32 pm »
To continue my long string of questions I can't seem to find the memory address of the BASIC graph.
I assume I can treat it as just another buffer.
It isn't really important I am just curious how some asm programs edit the graph.
The graph screen buffer used by BASIC and the OS is called plotSScreen in the equate file, which is equivalent to Axe's L6, and is found at $9340. Because many OS drawing routines operate (exclusively) on this buffer, most notably text drawing, assembly programmers generally use this as their graphics buffer. And if an assembly program doesn't explicitly mark the graph as dirty by setting the graphDraw flag, then the OS will happily retain and display whatever was in plotSScreen the next time you view the graph screen. However, it seems that the effect of this flag was not known to most assembly programmers, so most assembly programs that don't leave an image intended to be preserved in plotSScreen still don't set this flag. And seeing garbage or the last frame of whatever assembly program ran last the next time you use the graph screen is somewhat annoying. So modern shells (at least, DoorsCS and zStart) step in and set this flag themselves, expecting that most programs run through them would have done so had their programmers known about it. But if you run an assembly program from the home screen without any shell's home screen hook enabled, you can still preserve an image. In conclusion, an assembly program can put its own image in the graph buffer and simply not set the graphDraw flag to "request" that the OS preserve the image, but due to many programs historically doing this unintentionally, modern shells set the flag themselves to request that the OS clear the image.
90
« on: December 04, 2015, 12:55:41 pm »
If compile any axe program with Axe 1.3, the calculator freeze 
Could you provide more information? The following questions come to mind: - Does pressing VARS or ON do anything?
- Does archiving/unarchiving the source change anything?
- Have you ever successfully compiled something with Axe 1.3.0, or has this only just started happening?
- Precisely when does it freeze? Does this seem to be the same in every program?
- What are Axe's options set to? Particuarly, are you compiling as an applcation or is auto backup enabled?
- What model calculator are you using? If you also use an emulator with that calculator's ROM image, does the freeze also occur on the emulated calculator?
Pages: 1 ... 4 5 [6] 7 8 ... 153
|
Show Posts