Author Topic: Bug Reports  (Read 407656 times)

0 Members and 1 Guest are viewing this topic.

Offline Runer112

  • Project Author
  • LV11 Super Veteran (Next: 3000)
  • ***********
  • Posts: 2289
  • Rating: +639/-31
    • View Profile
Re: Bug Reports
« Reply #1260 on: May 16, 2011, 08:50:55 pm »
I think I might have mentioned this bug a while ago, and it's been around for a long time, but since it isn't fixed yet I'll mention it again. {CONST}rr, →{CONST}rr, and →{EXPR}rr are all broken. The first two compile into incorrect code, while the third won't compile.
« Last Edit: May 16, 2011, 08:51:13 pm by Runer112 »

Offline Quigibo

  • The Executioner
  • CoT Emeritus
  • LV11 Super Veteran (Next: 3000)
  • *
  • Posts: 2031
  • Rating: +1075/-24
  • I wish real life had a "Save" and "Load" button...
    • View Profile
Re: Bug Reports
« Reply #1261 on: May 17, 2011, 01:27:54 am »
The nibble reading and writing commands have opposite endianness again. I would suggest changing p_NibSto to be big-endian like the reading commands currently are, since a lot of people complained about the nibble commands being little-endian. Which makes sense, because big-endian style is a lot better for things like reading from nibble tilemaps. Big-endian nibble order better corresponds with how hex data is added and displayed.
Why does that keep reversing?  I don't remember the last time I changed it... I'll fix it once again.

p_Safety is, well, I have no idea. It works, but it has lots of code that serves no apparent purpose. I'll post what I think the routine should probably look like following this list.
Haha!  I wish it could be that simple.  But as I mentioned in another thread and on Cemetech, there is actually a bug in the z80 hardware where if an interrupt occurs during a ld a,i instruction it will erroneously set the flags as if there was no interrupts, so a more robust test is needed unfortunately.  The one I'm using was invented by calc84maniac.  This was a bug I had for a long time; that custom interrupts would suddenly stop working after a minute or so.  And I'm so glad I finally fixed it!

Quote
Probably not a big deal, but if either p_FastCopy or p_DrawAndClr were called immediately after sending data to the LCD, the initial row setting would fail. This could be fixed by moving the safety call after the ld hl,plotSScreen and adding some waste instructions after the initial row setting.
Hmmm... I will double check this and change it if its as simple as moving a few instructions around.  I want to try to avoid waste instructions though.

Quote
Commands.htm still says that DispGraphr and DispGraphrr will not work at 15MHz.
I'll fix that.

Quote
But on the topic of constant optimizations, although For() loops with a constant upper bound got a slight upgrade, it missed the much larger upgrade that the constant comparisons received. Any chance of sneaking that into For() loops as well?
I'll get to that hopefully...

Quote
I think I might have mentioned this bug a while ago, and it's been around for a long time, but since it isn't fixed yet I'll mention it again. {CONST}rr, →{CONST}rr, and →{EXPR}rr are all broken. The first two compile into incorrect code, while the third won't compile.
O.O How could something this big go unnoticed for so long!  I'll fix it right away.
« Last Edit: May 17, 2011, 01:29:31 am by Quigibo »
___Axe_Parser___
Today the calculator, tomorrow the world!

Offline Deep Toaster

  • So much to do, so much time, so little motivation
  • Administrator
  • LV13 Extreme Addict (Next: 9001)
  • *************
  • Posts: 8217
  • Rating: +758/-15
    • View Profile
    • ClrHome
Re: Bug Reports
« Reply #1262 on: May 17, 2011, 09:42:05 am »
p_Safety is, well, I have no idea. It works, but it has lots of code that serves no apparent purpose. I'll post what I think the routine should probably look like following this list.
Haha!  I wish it could be that simple.  But as I mentioned in another thread and on Cemetech, there is actually a bug in the z80 hardware where if an interrupt occurs during a ld a,i instruction it will erroneously set the flags as if there was no interrupts, so a more robust test is needed unfortunately.  The one I'm using was invented by calc84maniac.  This was a bug I had for a long time; that custom interrupts would suddenly stop working after a minute or so.  And I'm so glad I finally fixed it!

That's why! I noticed that (interrupts suddenly going back to normal) a few versions ago but I didn't know it was a bug with Axe.
« Last Edit: May 17, 2011, 09:42:31 am by Deep Thought »




Offline Quigibo

  • The Executioner
  • CoT Emeritus
  • LV11 Super Veteran (Next: 3000)
  • *
  • Posts: 2031
  • Rating: +1075/-24
  • I wish real life had a "Save" and "Load" button...
    • View Profile
Re: Bug Reports
« Reply #1263 on: May 17, 2011, 06:52:21 pm »
I found the bug to the big endian reading/writing.  It just happened this version so it wasn't around before.  Its because I added the No-Op command which uses the illegal command size 0.  A zero normally signifies an immediate replacement when found right after a command and the no-op was right after the swap command so it was trying to replace pars of the swap command with the last thing in "ans" which would be the constant.  So I've moved the no-op operation to the top of the file instead so that its never trailing another command.  I realize I could just slap on the label to any zero byte in the file, but I'm trying to keep it readable.
___Axe_Parser___
Today the calculator, tomorrow the world!

Offline Runer112

  • Project Author
  • LV11 Super Veteran (Next: 3000)
  • ***********
  • Posts: 2289
  • Rating: +639/-31
    • View Profile
Re: Bug Reports
« Reply #1264 on: May 17, 2011, 07:07:41 pm »
Oh yeah, I see now that loading and storing big-endian values with constant pointers worked correctly before 0.5.2. I was partially correct in saying that the bug has been around for a while, though. Although constant pointers never had problems, when storing big-endian values was introduced in Axe 0.4.7, it didn't work for non-constant pointers right from its release. So this bug/feature lack has been around for almost half a year. :o And it went completely unnoticed until a month and a half ago, when I noticed it and posted the bug report here. Apparently you didn't see my report. :P

This bug must have been present for a long time, because I can't even find a version of Axe in which this bug doesn't exist. Storing a 2-byte value backwards to an expression pointer like →{}rr throws a compile error. The error doesn't happen if the pointer is a constant, only if it's an expression.

Offline Munchor

  • LV13 Extreme Addict (Next: 9001)
  • *************
  • Posts: 6199
  • Rating: +295/-121
  • Code Recycler
    • View Profile
Re: Bug Reports
« Reply #1265 on: May 18, 2011, 10:11:42 am »
Every time I had a certain feature to my program the game crashes when it happens.

What I'm adding is a Pxl-On(96,Z)^r and then a Horizontal -^r.

I made different programs with this feature (the Y of Pxl-On is random) in several games I made as prototypes and it always compiles well, runs well but crashes during runtime (I never get to see the feature).

So the thing is, is there any problem in the code or in the Parser? I can't give full code because this is for my entry.

Offline Runer112

  • Project Author
  • LV11 Super Veteran (Next: 3000)
  • ***********
  • Posts: 2289
  • Rating: +639/-31
    • View Profile
Re: Bug Reports
« Reply #1266 on: May 18, 2011, 10:52:08 am »
Scout, neither of those should be able to cause crashes. When I wrote a quick test program with those two lines of code in a loop, nothing bad happened.

Also, Pxl-On(96,Z)r does nothing because 96 is out of the bounds of the screen.
« Last Edit: May 18, 2011, 10:52:28 am by Runer112 »

Offline Munchor

  • LV13 Extreme Addict (Next: 9001)
  • *************
  • Posts: 6199
  • Rating: +295/-121
  • Code Recycler
    • View Profile
Re: Bug Reports
« Reply #1267 on: May 18, 2011, 11:01:53 am »
Scout, neither of those should be able to cause crashes. When I wrote a quick test program with those two lines of code in a loop, nothing bad happened.

Also, Pxl-On(96,Z)r does nothing because 96 is out of the bounds of the screen.

I actually managed to do it too, but it was a bit weird because it happened in two different programs. Thanks for checking it :)

Offline Runer112

  • Project Author
  • LV11 Super Veteran (Next: 3000)
  • ***********
  • Posts: 2289
  • Rating: +639/-31
    • View Profile
Re: Bug Reports
« Reply #1268 on: May 20, 2011, 11:31:46 am »
The flipH() command has a problem. I think when I was optimizing it, I got confused about which register pair held a pointer to what and ended up using an 8-bit increase for the sprite input instead of the sprite output. Please change inc l \ inc de to inc e \ inc hl.

Offline Freyaday

  • 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...
    • View Profile
Re: Bug Reports
« Reply #1269 on: May 20, 2011, 11:43:49 am »
Under the ZOOM menu in VARS, there's a bunch of changed tokens that give an ERR:BAD SYMBOL when I try to use them. None of them are mentioned in the documentation anyway....
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!

Offline FinaleTI

  • Believe in the pony that believes in you!
  • CoT Emeritus
  • LV10 31337 u53r (Next: 2000)
  • *
  • Posts: 1830
  • Rating: +121/-2
  • Believe in the pony that believes in you!
    • View Profile
    • dmuckerman.tumblr.com
Re: Bug Reports
« Reply #1270 on: May 20, 2011, 02:50:05 pm »
Under the ZOOM menu in VARS, there's a bunch of changed tokens that give an ERR:BAD SYMBOL when I try to use them. None of them are mentioned in the documentation anyway....
Those tokens are for use with Axioms.


Spoiler For Projects:

My projects haven't been worked on in a while, so they're all on hiatus for the time being. I do hope to eventually return to them in some form or another...

Spoiler For Pokemon TI:
Axe port of Pokemon Red/Blue to the 83+/84+ family. On hold.

Spoiler For Nostalgia:
My big personal project, an original RPG about dimensional travel and a few heroes tasked with saving the world.
Coding-wise, on hold, but I am re-working the story.

Spoiler For Finale's Super Insane Tunnel Pack of Doom:
I will be combining Blur and Collision Course into a single gamepack. On hold.

Spoiler For Nostalgia Origins: Sky's Story:
Prequel to Nostalgia. On hold, especially while the story is re-worked.

Offline ralphdspam

  • LV8 Addict (Next: 1000)
  • ********
  • Posts: 841
  • Rating: +38/-1
  • My name is actually Matt.
    • View Profile
Re: Bug Reports
« Reply #1271 on: May 20, 2011, 06:44:26 pm »
In Axe 0.5.2, there seems to be a problem with constants and If [variable]<[constant].  When I replace GDB2 with 10, the code functions correctly.  For some reason, the If statement gives a false "true" when I use GDB2.  ???

For example,
Code: [Select]
10->GDB2
If K<GDB2
.GDB2 is not compiled correctly, so it shows a false true.
End
If 10=GDB2
.GDB2 is compiled correctly for some odd reason.
Text(0,0,":)")
.A smilie is displayed, so I know that GDB2 is supposed to be compiled as 10 (Here at least).
End
« Last Edit: May 20, 2011, 06:45:11 pm by ralphdspam »
ld a, 0
ld a, a

Offline Runer112

  • Project Author
  • LV11 Super Veteran (Next: 3000)
  • ***********
  • Posts: 2289
  • Rating: +639/-31
    • View Profile
Re: Bug Reports
« Reply #1272 on: May 20, 2011, 07:07:30 pm »
There appears to be quite a fatal flaw with user-defined constants. If a user-defined constant is used as the operand in an operation that wouldn't qualify for any constant auto optimizations, the code will be compiled correctly. But if the operation would be turned into a constant auto optimization (e.g. any constant less-than/greater-than comparison), the parser gets confused. It parses the code as the normal, unoptimized command, which would still work if that was the only flaw. However, because of what I can only guess is the remnants of some sort of debugging code, the constant is replaced with 0x9001. :P

Offline Freyaday

  • 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...
    • View Profile
Re: Bug Reports
« Reply #1273 on: May 20, 2011, 07:09:17 pm »
It's over 9000!!!!! in hex!
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!

Offline ralphdspam

  • LV8 Addict (Next: 1000)
  • ********
  • Posts: 841
  • Rating: +38/-1
  • My name is actually Matt.
    • View Profile
Re: Bug Reports
« Reply #1274 on: May 20, 2011, 07:09:43 pm »
9001? Really? wow.  :P

So, how would I write that If statement so it compiles correctly?
ld a, 0
ld a, a