I wanted to see how simple it would be to make a nice tool to improve the homescreen math capabilities slightly. This thread will be designated for me asking how to do things!
First hurdle: displaying custom answers using the a=0 case of the homescreen hook.
How do I "properly" return an answer such that it acts just like any other homescreen result? Simply pointing OP1 to the new answer makes it display correctly originally, but you can't interact with it at all like scrolling it left/right if it's wider than the screen.
EDIT: Testing seems to reveal that storing the custom answer to Ans allows for scrolling to work. However, I'm not sure if this is the ideal solution, or if it is, if it's the full ideal solution. Another interesting thing of note is that the scrolling works fine with MathPrint enabled, even without saving the custom answer to Ans.
Is it possible to return something that's not a number (a string, basically) and have it display right-aligned?
Foreword: the solution to this issue probably has to deal with something like OS flash modification procedures or the certificate, so expect to need to know about these things.
* Runer112 looks at BrandonW, DrDnar, and thepenguin77
Here's the issue I'm experiencing with Axe. I'll start with a high-level description. Since at least Axe 1.2.1, I have experienced a very peculiar bug. On the few occasions when I've sent a new development version of Axe to my calculator, the very first compile would result in a seemingly random compilation error occurring almost instantly. This error would never occur again for the same version of Axe, as far as I can tell. I've tried replacing it with the old version of Axe and re-upgrading it, I've tried clearing RAM, and I've tried sending new "dummy" upgraded versions of Axe that have one small thing changed to make the application slightly different. None of these seem to replicate the bug. The bug also doesn't seem to ever occur in wabbitemu.
I'm fairly certain this is not a fluke. This exact scenario of me making a ton of changes and sending the new version of Axe to my calculator months after the last build was sent has happened at least three times so far; once with an older version (perhaps 1.2.1, or an early 1.2.2 build?), and twice with sending the most recent 1.2.2 to two of my calculators. I have one calcultor left still with Axe 1.2.1 on it. I predict that sending Axe 1.2.2 to this calculator will replicate the bug one more time, but I'm saving it to add more debugging tools as necessary to a build of Axe 1.2.2 to hopefully pin down this bug.
Now, for some lower-level details. The error occurs due to a failed B_CALL(_WriteAByteSafe), oddly on what I believe is the second call to that routine with the fresh version of Axe. The write is to the first page of the swap sector, which should have been erased by a B_CALL(_FindSwapSector) \ B_CALL(_EraseFlashPage). In the register dump that follows, the swap sector perhaps unusually starts on page $0C, but I don't think that's part of the issue. From what little I remember of the dump I got from my first calculator, which I didn't save, I believe everything was the same except the swap sector started on page $08.
Anyways, here are the known input and output register values from B_CALL(_WriteAByteSafe) that I got from the existing debug dumper in Axe 1.2.2 when the error occurred on the second of the two calculators I sent it to:
INPUT: af=$0C80, bc=$4701, de=$4011, hl=$8686 (note: the value of b is not officially known, but that's what it ideally should have been)
OUTPUT: af=$1F08, bc=$0000, de=$4011, hl=$8478
If anyone already has any ideas as to what the problem is, or ideas of what to add to a debug version of Axe to hopefully replicate and better debug the issue on my third calculator or your calculator, I would appreciate them. If not and I can't solve the issue myself, I'll just write this off as a minor bug since it only happens once per Axe upgrade anyways.
The latest version is attached at the bottom of this post.
GrayLib v1.0
== BASICS ==
What is GrayLib? GrayLib is an Axe library, designed for Axe 1.2.1, to provide nearly perfect grayscale and tons of useful related functions to Axe programmers with extensive customizability.
== FEATURES ==
Tunable crystal timer-based grayscale for non-83+ calculators. Nearly perfect!
Tunable slower hardware-timer based grayscale as a fallback for 83+ calculators. Still looks very good!
Supports either 3-level or 4-level grayscale.
A buffered approach to avoid any frame mixing when rendering new frames.
Automatic setting loading and saving from/to an archived variable.
Includes a default contrast and grayscale timing tuner which can automatically start on the first run.
Masked sprite drawing for both 3- and 4-level grayscale. (Axe's built-in Pt-Mask() command can only draw to a set buffer pair, which is no good for a buffered approach)
Text routines to print integers, tokens, strings, and characters in any foreground/background grayscale color combination.
Support for hooks in the grayscale update interrupt, which can optionally replace the default grayscale update command.
Support for using getKey like normal, despite the OS interrupt not running.
== EXAMPLE PROGRAMS ==
To get a basic idea for how to use GrayLib, I have created a few example programs. One is a very basic wrapper for the default tuner, one is a screensaver-style bouncing text program, and one is a fairly complicated recreation of the movement engine from the first-generation Pokemon games, set in Pallet Town. Every example program comes in two forms: a smaller version, which contains just the code, and a larger "Commented" version. The commented versions contain detailed comments explaining exactly how each piece of the code works, and can be good resources for both learning how to use GrayLib and simply learning Axe coding approaches and tricks.
Spoiler For Animated screenshots!:
83+
84+
GRAYTUNE
GRAYTUNE
GRAYTEXT
GRAYTEXT
GRAYPKMN
GRAYPKMN
They look less flickery on real calculators, although more blurry.
== LEARNING TO USE GRAYLIB ==
GrayLib itself also comes in a small version and a commented version. The small version is good to store on your calculator if you don't need a reference on your calculator about how to use the library. Whether or not you want to store the commented version on your calculator, THE COMMENTED VERSION IS CRUCIAL TO LEARNING THE MYRIAD OPTIONS AND COMMANDS IN GRAYLIB.
== FEEDBACK ==
If you have any questions, comments, concerns, feature requests, or bug reports, make a post here and I (or somebody else who knows the library) will try to reply as soon as possible!
What's a foolproof (and preferably not exceedingly large) method to determine the first free application page on an 83+ or 84+? Importantly, such a method also needs to determine if there are no free application pages left.
So Builderboy has requested that the vector table for im 2 interrupts in Axe be moved, because right now it occupies an area of safe RAM that Axe users often want to use to store data (statVars). And I agree that this is probably a good idea. The question is, where's a good, safe spot to put it in static RAM that Axe doesn't expose to users? Axe exposes the following RAM areas, so they are off limits:
saveSScreen
statVars
appBackUpScreen
plotSScreen (duh)
Also off limits are any areas of RAM that are needed by B_CALLs in any Axe command; for example, all of $8000-$8400 is off limits because of possible archive operations.
So far the best idea seems to be $9200, which is in the middle of where table data is stored. Destroying table data seems like it could be an acceptable side effect, but are there any better options?
Is it possible to store a value to an arbitrary real number variable? I tried expr("1"+Str0+"A") as a test (where Str0 contains a store arrow), but it throws an error. I suspect it may not be possible, but if you can think of any hackish way to do it, that would be great. I don't want to have to resort to a 27-branch conditional.
What the title says would be nice. I always struggle to make my IRC bot's output look proper in OmnomIRC because of a lack of support for some IRC control characters. Here is what I've noticed omnomIRC is still missing, listed in order of decreasing importance to me:
[0x0F] Strip: any alterations applied by previous control characters are removed
White background color
More accurate colors
[0x02] Bold: Is a toggle
[0x1F] Underline: Is a toggle
[0x1D] Italic: Is a toggle
[0x16] Reverse: Acts like color 0,01 except it's actually a toggle that overrides, but does not cancel, color
I've been planning this project for a long time, and with the recent release of Axe 1.1.2, I can finally begin to make it a reality!
YAAM
YAAM? How is a vegetable going to help me develop Axe projects?
YAAM is no vegetable! It stands for Yet Another Axe Mapper, my friend! It is an Axe library designed to make smoothscrolling tilemapping in Axe both fast and easy by providing all the necessary routines for you in an easy to use manner! Instead of having to write your own tilemapping engine to your custom specifications, select the options you want from the built-in variety of options in YAAM and your tilemapper is done! (This will be more true in later versions as I add more features)
But drawing a whole unaligned tilemap every frame is slow! I don't want my game to be slow!
Au contraire, YAAM makes scrolling tilemaps very quick by shifting the previous frame's tilemap and redrawing only the tiles shifted in, which is quite fast. If the tilemap doesn't shift between frames, you don't need to redraw it at all!
That sounds cool! What other cool features does it have?
Here, let me draw you up a quick list:
Very fast tilemap shifting
Handles all drawing and shifting through a few easy to use routines
Works with any tile size up to 8x8
Works with any map width and height
But I want this feature! And fix this bug!
For any feature requests and bug reports, just post them in this thread. However, I am already planning many features for the future, so your feature request may actually already be on my to-do list:
Spoiler For To-Do List:
Allow many variables, like pointers and map size, to be defined as constants instead
Allow tile sizes larger than 8x8
Add support for grayscale
Implement optimized multi-pixel shifting
Add support for inflated coordinates (256 = 1 tile, instead of 1 = 1 pixel)
Easy there, one question at a time! The latest version of YAAM (v0.2) can be found attached to this post. It requires Axe 1.1.2. Download the zip file, send YAAM.8xp to your calculator, include it anywhere in your program, and you're good to go!
Full usage details can be found in the included readme. No they can't, because I haven't written one yet. However, I have included a sample program using YAAM that should detail the basics of using it. You can also learn more about YAAM's options and variables by looking at the options section in the library itself, which has small comments to generally explain what everything is. To set constants like tile width and height to your own values, redefine these values before including YAAM. To set everything else like tilemap size and pointers, store values to the variables listed after including YAAM.
The subject line mostly explains what I want to do. Inside of the OS program editor, I'm wondering what the easiest way is to "jump" to a point in the edit buffer. I don't want any scrolling, any adjusting of the cursor position on the screen, really any noticeable changes to the user. I just need the edit pointers to be adjusted and for the data in the edit buffer to be moved around properly. I probably explained that awfully, so let me sketch it out. I want to be able to start with a program in the edit buffer like it was just loaded:
I feel like there's some easy way to do this involving a bcall or two instead of having to do the copying and pointer updating myself, but I don't know what it is. Sort of like an instant goto, but without any actual displaying. If you can only think of a way to do it with the displaying, that might be acceptable as well, so feel free to suggest whatever comes to mind.
Well I was messing around with grayscale, and this happened. I have no idea what is going on here. Does the screen have some strange physical quality that is causing this? Left is supposed to be white, middle is supposed to be gray, right is supposed to be black. However, the middle appears to be cycling between dark gray and super-white. Also the center of the screen has more wild contrast changes than areas further away from the center.
EDIT: I have attached the program I used to observe this strange effect. It will only work on 15MHz calculators. Use +/- to tune the frequency, CLEAR to quit. Don't press - too much or it will probably crash! I can't easily give the source because it is part Axe, part Axiom, and part raw hex edited. But if you do look at the disassembly of it, please don't mind any unoptimized code or code that seems out of place, I never actually meant to release this.
Alternating pixels between black and white at the same speed as the LCD controller alternates between positive and negative voltages means that those pixels receive only the positive pulses or only the negative pulses, effectively creating direct current just like the controller is supposed to prevent. In summary: Don't use this effect unless you want to screw up your screen.
It's hard to keep track of bug reports, feature requests, and optimizations with the massive amount of posts in Axe threads. This is my attempt to compile all of them into one post in one thread. Hopefully this should make sure bug reports and good feature requests aren't lost and make it easier for Quigibo or any other coders who want to help to spend their time coming up with solutions instead of trying to find problems to solve.
If there are existing posts containing bug reports, feature requests, or optimizations that you don't see here, please try to direct me to the original post. If the post has some standing, I will add it to the list with ratings of importance and ease that I feel are appropriate. Please try not to debate much over the importance of items, the ratings I assign are just my rough opinions. Quigibo and any other coders can address items in any order they want.
Feel free to discuss any of these items either here or in their appropriate threads. I will try to merge good ideas and important points into the discussion section for each item.
Changelog
12/18/11: [Axe 1.1.1]
-3 bugs
Error thrown at empty hexadecimal data brackets
[Unconfirmed] Compiling from archive sometimes fails
Issues with lowercase in getKey?
-3 feature requests
Reporting name of source file upon compile error
More meaningful compilation progress information
Display size of the compiled program during compiling
~1 feature request
Switch statement
-4 optmization suggestions
Optimized general mutliplication
Optimized fixed-point multiplication
Optimized signed division and reciprocal commands
Peephole optimization of sbc hl,de \ ld a,h \ or l
12/18/11: [Axe 1.1.0]
+4 bugs
Error thrown at empty hexadecimal data brackets
Issues with lowercase in getKey?
Misdocumented EndIf and End!If
Duplication of commands referenced in Axioms
+5 feature requests
Automatic backup of included programs
Ability to execute programs upon compilation
Display size of the compiled program during compiling
Better sorting routines
Nested preprocessor conditionals
+5 optmization suggestions
Optimized general mutliplication
Optimized fixed-point multiplication
Optimized signed division and reciprocal commands
Peephole optimization of sbc hl,de \ ld a,h \ or l
Returning the full 32-bit result from the *^ operation
12/10/11: [Axe 1.1.0]
-15 bugs
operandNAME() parses NAME as a variable, not a function
Horizontal -(BUFF) does not properly adjust BUFF
High-order multiplication calls the wrong routine
Erroneously throwing errors for some pointer reads
Multiple bugs with peephole optimizer
Precedence issue with negating constant pointer reads
Occasional issue importing tilemaps
The Axe application doesn't disable G-T mode
The ? token lacks special meaning in strings
Address replacements fail in inline Axiom commands
Buff(CONST) accepts undefined constants
Lack of peephole optimizer control from API
? and ? don't throw an error, given bad/no digits
Incorrect key for float{ in command list
CONST? as last line in source
-5 feature requests
Pre-processor conditionals
Improved handling of lowercase by getKey?
Arbitrary-sized sprite drawing command(s)
For(EXPR) loop
Including any external variable as data
~1 feature request
Manual stack control for experienced users
-5 optmization suggestions
Optimized sort and reciprocal commands
Peephole optimization of inc hl \ dec hl
Optimized Bitmap() routine
Optimized input command
Optimized checksum routine
Spoiler For Old:
12/10/11: [Axe 1.0.5]
+9 bugs
Multiple bugs with peephole optimizer
High-order multiplication calls the wrong routine
Erroneously throwing errors for some pointer reads
Precedence issue with negating constant pointer reads
Occasional issue importing tilemaps
The ? token lacks special meaning in strings
Address replacements fail in inline Axiom commands
Lbl and Goto mishandle spaces and periods
Incorrect key for float{ in command list
+3 feature requests
Improved handling of lowercase by getKey?
More meaningful compilation progress information
Inclusion of token strings as data
+3 optmization suggestions
Optimized sort and reciprocal commands
Peephole optimization of inc hl \ dec hl
Optimized input command
10/18/11: [Axe 1.0.5]
+2 bugs
operandNAME() parses NAME as a variable, not a function
Lack of peephole optimizer control from API
+2 optmization suggestions
Optimized Bitmap() routine
Optimized checksum routine
10/07/11: [Axe 1.0.5]
+1 bug
[Unconfirmed] Compiling from archive sometimes fails
+1 feature request
Including any external variable as data
10/05/11: [Axe 1.0.5]
+1 feature request
Macros
10/03/11: [Axe 1.0.5]
+3 bugs
CONST? as last line in source
? and ? don't throw an error, given bad/no digits
[Unconfirmed] Use of bcalls not in old OSes
+1 optmization suggestion
Special comparisons for control structures
09/31/11: [Axe 1.0.5]
-1 bug
[Unconfirmed] Instant goto corrupts program names
09/31/11: [Axe 1.0.5]
+1 bug
Horizontal -(BUFF) does not properly adjust BUFF
+1 feature request
Proper inclusion of 2-byte tokens in strings
+3 optmization suggestions
Separating Vertical +/- variants from main routines
Loading a value before the jump in if statements
Short-circuit operators in if statements jump directly to destination
09/30/11: [Axe 1.0.5]
+8 bugs. +51 feature requests. +12 optmization suggestions. No discussion about any items. No solutions for any items. Some items already have solutions, but I'm exhausted. I'll try to fill in all the discussion/solution fields tomorrow.
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.
What's the minimum number of cycles at 6MHz that should exist between LCD outputs to be safe on just about any calculator? I think I recall someone in IRC suggesting 66, which is what Ion's routine uses, while routines used in Axe are closer to 70. And how exactly might things like the LCD delay port, bad LCD drivers, and ALCDFIX affect the timing that should be used in such a routine?
Simple question: how do you pronounce the z80 mnemonics? Don't feel compelled to mention every single instruction, but at least mention those you pronounce differently from me.
Capital letter means pronounce the letter, lowercase letters means pronounce the word. Ones in bold are ones I think I pronounce strangely!
Show Posts
