### Author Topic: Bug Reports  (Read 223502 times)

0 Members and 1 Guest are viewing this topic.

#### calc84maniac

• eZ80 Guru
• Coder Of Tomorrow
• LV11 Super Veteran (Next: 3000)
• Posts: 2898
• Rating: +467/-17
##### Re: Bug Reports
« Reply #1440 on: August 19, 2011, 03:50:51 pm »
The proper way to check flash unlockage is by checking bit 2 of port 2. I think WriteAByteSafe will probably return the flag on any kind of failure (like passing a bad address or writing a set bit over a reset bit)
"Most people ask, 'What does a thing do?' Hackers ask, 'What can I make it do?'" - Pablos Holman

#### Runer112

• Project Author
• LV11 Super Veteran (Next: 3000)
• Posts: 2289
• Rating: +639/-31
##### Re: Bug Reports
« Reply #1441 on: August 20, 2011, 12:14:21 am »
Here's a pretty nasty bug. The length() routine isn't being inserted properly; the code for checking if the ON key is pressed is being inserted in its place. And that code doesn't have a return, which can cause very bad stuff to happen... If there's some table you can easily look at that simply has an incorrect value for the length routine, perhaps you should check all the other routines while you're at it.

#### Quigibo

• The Executioner
• CoT Emeritus
• LV11 Super Veteran (Next: 3000)
• Posts: 2031
• Rating: +1075/-24
##### Re: Bug Reports
« Reply #1442 on: August 20, 2011, 01:39:32 am »
Oh wow, thanks.  Yeah, it was just a wrong value in the table.  Fixed that now.
___Axe_Parser___
Today the calculator, tomorrow the world!

• The One And Only Serial Time Killing Catboy-Capoeirista-Ballerino
• LV10 31337 u53r (Next: 2000)
• Posts: 1970
• Rating: +128/-15
• I put on my robe and pixel hat...
##### Re: Bug Reports
« Reply #1443 on: August 20, 2011, 01:54:46 am »
Encountered in 0.5.3
GetCalc(Str1,W+Length(P)) threw a Bad Symbol at me upon encountering Length(). Changing it to Length(P)+W fixed it.
In other news, Frey continues kicking unprecedented levels of ass.
Proud member of LF#N--Lolis For #9678B6 Names

I'm a performer at heart; I stole it last week.
My Artwork!

#### Hayleia

• Programming Absol
• Coder Of Tomorrow
• LV12 Extreme Poster (Next: 5000)
• Posts: 3367
• Rating: +393/-7
##### Re: Bug Reports
« Reply #1444 on: August 20, 2011, 02:56:20 am »
I have lots of those Bad Symbol bugs. Sometimes, I unarchive the source, re-compile (ERR: Out of mem) then re-archive it and re-compile and everything works Also, removing the appvar AxeData seem to make the compiling work afterwards
« Last Edit: August 20, 2011, 09:04:50 am by Hayleia »
I own: 83+ ; 84+SE ; 76.fr ; CX CAS ; Prizm ; 84+CSE
Sorry if I answer with something that seems unrelated, English is not my primary language and I might not have understood well. Sorry if I make English mistakes too.

#### Quigibo

• The Executioner
• CoT Emeritus
• LV11 Super Veteran (Next: 3000)
• Posts: 2031
• Rating: +1075/-24
##### Re: Bug Reports
« Reply #1445 on: August 20, 2011, 05:06:04 am »
I have lots of those bugs. Sometimes, I unarchive the source, re-compile (ERR: Out of mem) then re-archive it and re-compile and everything works

That's not a bug.  Axe needs lots of RAM to compile, even when compiling for an app.  If you don't have enough on your calculator, it will throw an out of memory error.  Archiving the source will often free up enough memory to compile for large sources.
___Axe_Parser___
Today the calculator, tomorrow the world!

#### Hayleia

• Programming Absol
• Coder Of Tomorrow
• LV12 Extreme Poster (Next: 5000)
• Posts: 3367
• Rating: +393/-7
##### Re: Bug Reports
« Reply #1446 on: August 20, 2011, 09:03:50 am »
Yes, I was not talking about that but about the Bad Symbol bug. It says Bad Symbol (with the source archived, after 67% of 1st pass), then I unarchive the source, re-compile (ERR: Out of mem of course, after 100% of 1st pass, 0% of 2nd pass) then re-archive it and re-compile and everything works, without the original Bad Symbol "error". Sometimes, it also works with the Pic missing bug (I have the pic in the Rom)
In fact, it sees error when they aren't
« Last Edit: August 24, 2011, 03:34:40 am by Hayleia »
I own: 83+ ; 84+SE ; 76.fr ; CX CAS ; Prizm ; 84+CSE
Sorry if I answer with something that seems unrelated, English is not my primary language and I might not have understood well. Sorry if I make English mistakes too.

#### thepenguin77

• z80 Assembly Master
• LV10 31337 u53r (Next: 2000)
• Posts: 1591
• Rating: +823/-5
• The game in my avatar is bit.ly/p0zPWu
##### Re: Bug Reports
« Reply #1447 on: August 23, 2011, 10:16:32 pm »
zTrumpet tells me that Axe makes trial apps. If that's the case, there's a really easy way to make them valid.

Here is a little section I wrote on the topic, and here is some code that you can put in Axe to make an app valid.

Code: [Select]
;#;validate an app;input: b = page; flash = unlockedvalidateApp: in a, (02) rlca ld de, $1F18 ld a,$15 jr nc, havePageAndAddress ld de, $1E50 in a, ($21) ;I know rrca ld a, $29 jr nc, havePageAndAddress ld a,$69havePageAndAddress: push af sub b add a, a ld h, 0 ld l, a add hl, de push hl bcall(_getCertificateStart) pop de add hl, de pop bc in a, (02) rlca jr c, not83PBE ld b, $1E-$15not83PBE: ld a, b add a, $15 ld b, a bcall(_loadCIndPaged) ld a, c ld c, b and$80 ld b, a ld a, c ex de, hl push af bcall(_writeAByte) pop af ld b, 00 bcall(_writeAByte) ret
It even has a check to make sure it won't crash if the app trials table is zeroed. Of course the proper thing to do would be to remake the entire certificate, but you probably don't want to be doing that. Plus, if you do end up writing 00 00 to the certificate, that kind of app will still run fine, so that's really not a problem.
zStart v1.3.013 9-20-2013
All of my utilities
TI-Connect Help
You can build a statue out of either 1'x1' blocks or 12'x12' blocks. The 1'x1' blocks will take a lot longer, but the final product is worth it.
-Runer112

#### Runer112

• Project Author
• LV11 Super Veteran (Next: 3000)
• Posts: 2289
• Rating: +639/-31
##### Re: Bug Reports
« Reply #1448 on: August 24, 2011, 12:17:22 pm »
Zeros() should immediately throw an error if the size argument contains a constant that has not yet been defined. Using a constant that has not yet been defined in the size argument can cause multiple problems.

And while we're on the topic of the Zeros(), any chance this old feature request could be implemented?

Can we have a feature like "Zeros()," but for any data.  For instance, something like this:
Command(1,12) would be the same as [010101010101010101010101]
Command([56],4) would be the same as [56565656]
Command(127,6) would be the same as Data(127,127,127,127,127,127)
Potentially, this command could even be used for repeating sets of data.  For instance:
Command([010203],12) would be the same as [010203010203010203010203]
Command("Text"[00],15) would be the same as "Text"[00]"Text"[00]"Text"[00]

So, what do you think?  Could this be a command?  I think it's a good idea, to avoid situations like this.

I really like that idea. What about changing Zeros( (det() to something more universal?

I would suggest changing the token replacement to Block(). Feeding 1 argument would create a block of the specified size filled with zeroes. Feeding 2 arguments would create a block of the specified size filled with a specified value. Maybe you could even add a Block()r command for creating a block filled with a specified word while you're at it, although this probably isn't as necessary as a normal byte-filling block command.

#### Quigibo

• The Executioner
• CoT Emeritus
• LV11 Super Veteran (Next: 3000)
• Posts: 2031
• Rating: +1075/-24
##### Re: Bug Reports
« Reply #1449 on: August 24, 2011, 04:33:19 pm »
@thepenguin77 Thanks!  I was avoiding that initially because some people were uncomfortable with modifying the certificate page.  But if you're sure that code works, I'll try it out.

@Runer112, I would have to modify a bunch of code in order to make data recursively definable.  Either that, or just allow a single non-zero byte to be filled instead of only zeros.
___Axe_Parser___
Today the calculator, tomorrow the world!

#### Runer112

• Project Author
• LV11 Super Veteran (Next: 3000)
• Posts: 2289
• Rating: +639/-31
##### Re: Bug Reports
« Reply #1450 on: August 24, 2011, 04:39:11 pm »
Being able to fill a block with one number (possibly words as well as bytes) is all I ever really wanted. I think the more complicated data insertion should be handled at a later date when you add macro support.
« Last Edit: August 24, 2011, 04:39:58 pm by Runer112 »

#### Runer112

• Project Author
• LV11 Super Veteran (Next: 3000)
• Posts: 2289
• Rating: +639/-31
##### Re: Bug Reports
« Reply #1451 on: August 26, 2011, 11:06:19 am »
It looks like you were in the middle of changing the multiplication routine when you released Axe 1.0.3. If I had to guess, I'd say you were going to make a separate routine for simple multiplication that doesn't worry about the high 16 bits of the result, while using the old routine for *^ and **. This sounds like a great idea to me. It would save about 300 cycles for most multiplications and save 5 bytes if neither *^ nor ** is used in the program, which probably fits many programs. If you wanted to go even further with this optimization, you could split off yet another routine that doesn't worry about the high 8 bits of the result for fixed point multiplication. I would personally do this because I love speed, but it's up to you.

But enough of that, back to the actual bug. Right now the two separate multiplication routines are lumped into one, resulting in an unnecessarily big multiplication routine, as the second copy is useless. *^ and ** will not work properly either, since the first routine and thus the routine that is called for multiplications is the simplified routine that disregards the high 16 bits of the result.
« Last Edit: August 26, 2011, 11:07:30 am by Runer112 »

#### Runer112

• Project Author
• LV11 Super Veteran (Next: 3000)
• Posts: 2289
• Rating: +639/-31
##### Re: Bug Reports
« Reply #1452 on: August 27, 2011, 02:51:34 pm »
Nice to see that you added the faster archive reading commands in 1.0.3. And using port 7 for applications was pretty smart, not sure why I didn't think of that. But there's one slight problem with your adaptation. You hijack p_Safety at a point where a should equal zero, but you don't set a to zero. Inserting a simple xor a before the call to p_Safety should fix this problem.

#### Quigibo

• The Executioner
• CoT Emeritus
• LV11 Super Veteran (Next: 3000)
• Posts: 2031
• Rating: +1075/-24
##### Re: Bug Reports
« Reply #1453 on: August 27, 2011, 10:31:01 pm »
Shoot!  I totally forgot I was experimenting with modifying multiplication and didn't revert it before releasing... But yeah that's why I was doing it, I figured since *^ and ** are used so rarely, it would be nice to have a 32bit multiplication routine for those and use the faster 16bit multiplication for *.  It would always be faster and still be smaller for most programs.

I think after these bug fixes I will upload 1.0.4 as an official stable version.
___Axe_Parser___
Today the calculator, tomorrow the world!

• The One And Only Serial Time Killing Catboy-Capoeirista-Ballerino
• LV10 31337 u53r (Next: 2000)
• Posts: 1970
• Rating: +128/-15
• I put on my robe and pixel hat...
##### Re: Bug Reports
« Reply #1454 on: August 27, 2011, 10:47:12 pm »
Woot, 32bit multiplication!
Can we get the other operations too, please?
In other news, Frey continues kicking unprecedented levels of ass.
Proud member of LF#N--Lolis For #9678B6 Names

I'm a performer at heart; I stole it last week.
My Artwork!