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 ... 66 67 [68] 69 70 ... 153
1006
« on: October 03, 2011, 03:55:30 pm »
Bump to tell Quigibo that I have added some bugs, and to remind him that he should feel free to move any feature requests he doesn't plan on implementing either down to zero stars of importance or into the Axiom requests section as appropriate, possibly with explanation. Also if there are any bugs that you don't think are bugs, feel free to drop them to zero stars of importance as well, again possibly with explanation.
Also, reminding everybody to speak up if they know of old bugs/feature requests/optimization suggestions that aren't found on this list. I want this to be an exhaustive list of pretty much everything, and I might have missed some. And don't be shy with strange feature requests, because I'll also be trying to fill out the Axiom requests section soon, where many requests could go. I wasn't originally looking for feature requests that might be useful as Axioms, so I know I've missed some of those.
1007
« on: October 03, 2011, 03:37:49 pm »
Freyaday, I'm pretty sure loops work exactly like they're supposed to. Your problem might be key bouncing, meaning that for a small fraction of a second after depressing or letting go of a key, the key's state will bounce between pressed and not pressed. You probably don't see this when the loop contains code because the small amount of time it takes to execute that code is enough for the key's state to stop bouncing.
That is bizzare. Is it something physical that happens, or an electrical glitch?
I think it's just the nature of how metal contacts act when extremely close together, but not quite touching. I'm not 100% sure, but that's my best guess.
Anyway, here are some bugs that I think are actually the fault of Axe and not strange hardware quirks.  - If the last line of a program is CONST→, no error is thrown and no code is produced from it. (What's up with all the last line bugs anyway?)
- ᴇ and π don't throw errors if followed by no valid digits, they're just interpreted as zero. They should probably also throw an error if the digit field contains an invalid alphanumeric digit. For instance, no error is thrown at ᴇ86GC, which could cause great confusion to people who don't notice the invalid hexadecimal character G.
- I'm not 100% sure of this one, but I think Axe might use some bcalls that aren't present in older operating systems. In this case, Axe should either avoid those bcalls or check the OS version before running. This animated screenshot taken by ben_g is what lead me to believe this:
1008
« on: October 03, 2011, 03:12:00 pm »
Freyaday, I'm pretty sure loops work exactly like they're supposed to. Your problem might be key bouncing, meaning that for a small fraction of a second after depressing or letting go of a key, the key's state will bounce between pressed and not pressed. You probably don't see this when the loop contains code because the small amount of time it takes to execute that code is enough for the key's state to stop bouncing.
1009
« on: September 30, 2011, 06:21:06 pm »
That seems like a pretty good way to safely implement stack usage. But could there also be commands for more experienced coders that simply equate to push hl, pop hl, and ex (sp),hl? Because your idea is great for casual coders, but crazy people like me like to be able to squeeze every last byte out of code. Something like you suggested here seems to be a good idea for syntax, and calc84maniac suggested a good syntax for ex (sp),hl here. Of course you would want to warn users about the dangers of these commands in the command list, but I don't think it's too dangerous to warrant not adding. There are so many other ways a programmer can crash their calculator with Axe, adding a new one won't really change much.
1010
« on: September 30, 2011, 10:42:38 am »
Yeah, the feature request list is a bit crowded. For requests for commands that you don't plan on adding, I'll make a separate section for Axiom requests and you can move anything you want into that section. But for everything that isn't simply a command request, instead of deleting things you don't plan on implementing, I think it would be better if it just had its importance dropped down to zero stars. If you want, you can add a short note in the discussion box explaining why it isn't a bug/why you won't implement the feature/why you won't implement the optimization. If you provide a good reason for not implementing it then I'll delete the entry altogether. Otherwise, I might follow it up with a counter-argument.
1011
« on: September 30, 2011, 02:04:12 am »
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
- -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
- 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)
- 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 checksum routine
Bugs| Importance | | Ease | | Summary | | Author | | Discussion/Solution | | **** | | ***** | | Misdocumented EndIf and End!If | | jacobly | | | | **** | | **** | | Duplication of commands referenced in Axioms | | Runer112 | | | | **** | | ? | | [Unconfirmed] Use of bcalls not in old OSes | | Runer112 | | List of bcalls used | | *** | | ***** | | ClrHome does not obey split screen setting | | Runer112 | | | | *** | | *** | | Lbl and Goto mishandle spaces and periods | | Runer112 | | | | *** | | ? | | input clears existing homescreen text | | Hot_Dog | | | | ** | | *** | | Possible ERR:MEMORY when creating variables | | Runer112 | | | | ** | | *** | | Awkward signed division rounding | | Runer112 | | | | * | | *** | | Various problems involving token 0x00 | | Runer112 | | |
Feature Requests| Importance | | Ease | | Summary | | Author | | Discussion/Solution | | ***** | | ***** | | Higher maximum symbol length | | Runer112 | | | | ***** | | ***** | | Fixed-point division | | calc84maniac | | | | ***** | | **** | | White and inverted line drawing | | Builderboy | | | | ***** | | **** | | FUNC()? recursive calling | | Michael_Lee | | | | ***** | | **** | | Automatic backup of included programs | | epic7 | | Extra pass? | | ***** | | *** | | Disabling of port 2E delays | | Runer112 | | | | ***** | | *** | | Variable increment for loop | | Lord Coniupiter | | | | ***** | | *** | | Line clipping | | Builderboy | | | | ***** | | *** | | ON key to halt execution | | Builderboy | | | | ***** | | ** | | Token replacements for Axioms | | Ashbad | | | | **** | | ***** | | Break and Continue | | calc84maniac | | | | **** | | ***** | | Unclipped aligned sprite drawing | | Quigibo | | | | **** | | **** | | Random integer from A to B | | Builderboy | | | | **** | | **** | | White and outline rectangles | | Builderboy | | | | **** | | **** | | Horizontal and vertical line drawing | | Quigibo | | | | **** | | **** | | Custom interrupts that perform an rst 38h | | Runer112 | | | | **** | | *** | | On-calculator application signing | | Quigibo | | | | **** | | *** | | Compound assignment operators | | SirCmpwn | | | | **** | | *** | | Proper inclusion of 2-byte tokens in strings | | Runer112 | | | | **** | | *** | | Inclusion of token strings as data | | Runer112 | | | | **** | | *** | | Buffer display with bitwise logic | | Happybobjr | | | | **** | | *** | | Buffer combination with bitwise logic | | ztrumpet | | | | **** | | *** | | Improved Axiom header with version system | | Runer112 | | | | **** | | *** | | More intelligent parsing of similar Axiom commands | | Runer112 | | | | **** | | *** | | Arbitrary buffer support for all buffer/drawing commands | | Runer112 | | | | **** | | ** | | Macros | | Runer112 | | | | **** | | ** | | Optional Axiom priority over Axe commands | | Runer112 | | | | **** | | * | | Some degree of on-calculator documentation | | Ashbad | | | | **** | | * | | Authentic Axe libraries | | Quigibo | | | | **** | | * | | 8-bit/32-bit mode | | Runer112 | | | | *** | | ***** | | Native InsertMem and DelMem commands | | calc84maniac | | | | *** | | ***** | | APD control | | Runer112 | | | | *** | | ***** | | B_CALL(_DelRes) | | Runer112 | | | | *** | | ***** | | B_CALL(_ForceFullScreen) | | Runer112 | | | | *** | | **** | | Signed for loop | | Quigibo | | | | *** | | **** | | Ability to execute programs upon compilation | | thydowulays | | | | *** | | **** | | 16*16 sprite drawing command(s) | | trevmeister66 | | | | *** | | *** | | Switch statement | | calc84maniac | | Partially added in 1.1.1 | | *** | | *** | | Manual stack control for experienced users | | Quigibo | | Partially added in 1.1.0 | | *** | | *** | | Better sorting routines | | ztrumpet | | | | *** | | *** | | Safe copy display routines | | calc84maniac | | | | *** | | ** | | Bit set/reset/get, esp. with memory | | Runer112 | | | | ** | | ***** | | CRC-CCITT | | Runer112 | | | | ** | | **** | | Ability to call other assembly programs | | ACagliano | | | | ** | | **** | | 8*n sprite drawing comamnd(s) | | ztrumpet | | | | ** | | **** | | Accessing the loop counter in For(CONST) loops | | Runer112 | | | | ** | | *** | | Buffer shifting by more than one pixel | | guy6020665 | | | | ** | | *** | | Nested preprocessor conditionals | | jacobly | | | | ** | | *** | | Axe API support | | Broseph Radson | | | | ** | | ** | | Manual alteration of code origin | | ztrumpet | | | | ** | | ** | | Defining constants from Axioms | | Runer112 | | | | ** | | ** | | File-specific variable reallocation | | Qwerty.55 | | | | ** | | * | | USB support | | graphmastur | | | | * | | ** | | Inline TI-BASIC | | Quigibo | | |
Axiom Requests| Importance | | Ease | | Summary | | Author | | Discussion/Solution |
Optimization Suggestions| Importance | | Ease | | Summary | | Author | | Discussion/Solution | | ***** | | *** | | Conditional jumping and calling | | calcdude84se | | | | ***** | | ** | | Optimization of most/all commands for constant arguments | | Runer112 | | | | **** | | ***** | | Make p_Log, p_Exp, p_GetBit, and p_GetBit16 subroutines | | Runer112 | | | | **** | | ***** | | Removal of some port 6 interactions for interrupts in programs | | Runer112 | | | | **** | | ** | | Special comparisons for control structures | | calc84maniac | | | | **** | | ** | | Optimized constant storing | | calc84maniac | | | | *** | | **** | | Returning the full 32-bit result from the *^ operation | | Quigibo | | | | *** | | **** | | Separating Vertical +/- variants from main routines | | Runer112 | | | | *** | | **** | | Loading a value before the jump in if statements | | calc84maniac | | | | *** | | *** | | Short-circuit operators in if statements jump directly to destination | | calc84maniac | | | | *** | | *** | | Double-buffered drawing | | Freyaday | | | | *** | | *** | | Parsing {CONST}? in expressions as a variable | | Runer112 | | | | *** | | ** | | Optimized constant loading | | calc84maniac | | | | ** | | *** | | Optimized bitwise operations with set/res instructions | | calc84maniac | | | | ** | | *** | | Optimized DS<() structure | | Runer112 | | | | ** | | * | | Putting routines inline/in subroutines intelligently | | Runer112 | | |
1012
« on: September 30, 2011, 01:06:56 am »
How about being able to access the loop counter in single-argument for loops? This could be done especially easily if all loops used a simple 16-bit counter, but could also be done (albeit not so easily) with the other counter formats as well. It would be especially cool if you could access the loop counter for the loop that the current loop is nested in.
1013
« on: September 28, 2011, 08:39:33 pm »
Whoops, I guess I've sort of let my documentation fall behind since Axe left 0.X.X versions. A good deal of the information is still accurate, but I guess it's missing some changes and some additions.
1014
« on: September 27, 2011, 11:05:34 pm »
I don't think you should force write-back. If a user has write-back disabled, they probably have it off for a good reason and would be annoyed if your program ignores that they purposely disabled write-back.
1015
« on: September 27, 2011, 10:58:17 pm »
A far simpler way to use write-back is to compile your program for MirageOS or DoorsCS. This will require that the program be run by a shell that allows easy write-back in the form of you simply modifying data in your running program, and the shell will then write any changes back to the original copy.
1016
« on: September 26, 2011, 05:43:02 pm »
I see what you mean about the 'var' token now. But I still think that tokens that correspond to strings larger than 1 character should be represented in their full form. If someone entered "sin(" into an Axe string, I'm pretty sure they actually want to see "sin(". If they wanted to see "s", they probably would have entered "s". This would especially make more sense to less experienced Axe coders who are familiar with being able to include tokens in strings in TI-BASIC. One way or another, you're probably going to need to address the string parsing code again. Because right now, a 2-byte token in a string = instant crash.  EDIT: Whoops, I meant a multi-character token.
1017
« on: September 26, 2011, 05:22:46 pm »
The new speedy compile option disables peephole optimizations. This should result in the parsing of average code being about two times faster while producing compiled code that is about 1-5% larger. It's very useful for recompiling large projects after making small changes for testing purposes, but remember to compile the slow way for your project releases!
1018
« on: September 26, 2011, 04:44:35 pm »
Good news everybody! After a bit of examination of Axe's string parsing code, I've pinned down the exact cause of random characters in strings being replaced with 'r'. I even found two other bugs in the process!
The errors lie in this routine, found at $66FC in Axe 1.0.4:
GetTokString:
or a
ret z
ld hl,OP1
ld (hl),a
cp tVarEqu
jr z,GetTokString_uvw
cp tProg
ld a,ProgObj
ret z
ld a,(hl)
B_CALL(_IsA2ByteTok)
call z,ReadAByte
GetTokString_Cont:
ld (OP1+1),a
ld hl,OP1
B_CALL(_Get_Tok_Strng)
ld a,(OP3)
ret
GetTokString_uvw:
call ReadAByte
ld b,a
cp tvn
ld a,AppVarObj
ret z
ld a,b
cp twn
jr nz,GetTokString_Cont
ld a,GroupObj
ret
First, the 'r' bug. When parsing a 2-byte token in a string, a second byte has to be read from the source file. This raises a (1-in-256?) chance of Axe updating the progress counter in the middle of the routine, and B_CALL(_DispHL) places the string representation of HL in OP1. So whenever the progress counter is updated in the middle of reading a 2-byte token in a string, the first byte of the token (which was stored at OP1) is destroyed and replaced with the character code for a space, $20. This is then passed as input into B_CALL(_Get_Tok_Strng), and token $20 is "randM(" which results in the phantom 'r'.
This leads into the next bug, the presence of which probably made diagnosing the first bug more challenging. The length of the token string as reported by B_CALL(_Get_Tok_Strng) (returned in a and bc) is disregarded by Axe, resulting in every token in a source string corresponding to only one character in the compiled string.
The final bug is regarding a token of special meaning to Axe. Although this routine correctly checks if the token is the "appv" or "grp" token, it doesn't check if it's the "var" token.
1019
« on: September 25, 2011, 07:38:09 pm »
I learned from this tutorial when I made YAAR (Yet Another Axe Raycaster). Both could be useful resourses to learn how raycasting works. The source code for YAAR is the last file attached to the first post if you want to peek at it.
1020
« on: September 24, 2011, 07:07:02 pm »
Good news Freyaday, I found your bug. I always had a lingering feeling that the forward djnz I used in to optimize the 4-level grayscale entry was too good to be true. And it was. It works great 99.9% of the time, which is why nobody saw a problem until now. But the issue is, if (flags+asm_flag2) holds a vaue other than -2, -1, or 0 when the grayscale routine is first called, the grayscale mask isn't rotated for anywhere from 1-253 calls.
This is fixed easily enough to restoring the grayscale mask initialization code for p_Disp4Lvl to what it was in Axe 0.5.3, and changing the mask initialization code for p_Disp4Clr in a similar way.
Pages: 1 ... 66 67 [68] 69 70 ... 153
|
Show Posts