| Author |
Message |
|
Iambian
Advanced Member
Joined: 13 Mar 2004
Posts: 423
|
 Posted: 03 Aug 2009 03:37:51 pm Post subject: |
|
|
If you've check the ReadME file for any answers, if you've checked elsewhere on this forum for answers, and you still can't figure out why Celtic III is behaving incorrectly, you may have found a bug. Before you tell me all about the bug, first ensure that the bug hasn't been addressed already in this thread. This first post contains information about what's being addressed and what still remains to be done. If what you found is new (enough), I'll need to know the following information.
1. The version code of Celtic III. Bugs need to be kept track of and I can't do that without a version code. What if I need to look back at the thread after, say, several versions later? It would turn into a guessing game if people used adjectives like "most recent version".
2. Explain what went wrong. What command did you use? What is the behavior I'm looking for and what did you think the expected behavior was?
3. I need to be able to reproduce this error. You need to tell me how to do so. Post the offending piece of code. Make sure that strip of code by itself will cause the error. And by that I mean BASIC code. If you post ASM code that shows the fix, then I'd be even happier.
-------
The next section is purely informative. Helps me keep track of stuff.
Current vesion: Celtic 3 version [ s ]
Known bugs:
real(12...) [.drawshape] Both box and line not rendering correctly.
identity(4...) [.stringtile] Faulty offsets?
identity(9...) [.boxshift] Not fully implemented
det(12...) [.extgroup] Causes crashes for an unknown reason
det(25...) [.errorhandle] Does not reliably work. Don't know why.
Reported errors (As of Aug 9, 2009)
LOOKUPINDEX [s]pair suffers from not stripping newline characters[/s] FIXED
DRAWTEXT [s]command does not reset flags after exiting.[/s] FIXED
Reported error (As of Sept 14, 2009)
MATTOSTR Output is not valid
Reported error (As of Feb 3, 2010)
Two byte tokens containing $3F as second byte does not properly parse in any lineread command
Last edited by Guest on 03 Feb 2010 02:46:53 pm; edited 1 time in total |
|
| Back to top |
|
|
simplethinker
snjwffl
Active Member
Joined: 25 Jul 2006
Posts: 700
|
| Posted: 09 Aug 2009 05:12:18 pm Post subject: |
|
|
The det(24 command (LOOKUPINDEX) in 3.09r doesn't strip the newline from the end of the string. I think I have a fix though (and I doubt this is the best fix):
In _CFN.z80 (in "fLookupIndex") between lines 1246 & 1247 ("sbc hl, bc" and "push hl") insert a "dec HL"
In _CFN.z80 (in "fIndexFile") between lines 1184 & 1185 ("jr z,fGetLineNum1" and "ret"), insert a "inc (IX-2)"
The first one shortens the length of the string that's read so the newline isn't copied. This runs into a problem when copying the last line of the file since there is no newline. The second one increments the pointer to the last line (which actually points to the final token in the last line), so when the length is decremented (for the final line) it's just ignoring junk.
If you do go this route for the fix, I think the second one would need to be modified to decrement the word-sized offset instead of just its LSB.
On a side note, in the fIndexFile code there's a "call $8000". What's loaded at $8000? |
|
| Back to top |
|
|
ajlitzau13
Newbie
Joined: 19 Jan 2009
Posts: 9
|
| Posted: 09 Aug 2009 09:37:43 pm Post subject: |
|
|
| I have version 3.09r. I found a bug in the drawtext command. The command works great in a program, but after running the program, the text in the TI-OS stays the same as it was in the program. For example, if you use large inverted text, the places in the TI-OS that would usually display small normal font (graph screen, Y= screen, stat plot screen, list editor screen, etc.) are all screwed up because they are trying to display large inverted text. |
|
| Back to top |
|
|
Graphmastur
Advanced Member
Joined: 25 Mar 2009
Posts: 360
|
| Posted: 09 Aug 2009 10:09:59 pm Post subject: |
|
|
ajlitzau13 wrote: I have version 3.09r. I found a bug in the drawtext command. The command works great in a program, but after running the program, the text in the TI-OS stays the same as it was in the program. For example, if you use large inverted text, the places in the TI-OS that would usually display small normal font (graph screen, Y= screen, stat plot screen, list editor screen, etc.) are all screwed up because they are trying to display large inverted text.
He probably just forgot to store the flags and change them back. |
|
| Back to top |
|
|
Iambian
Advanced Member
Joined: 13 Mar 2004
Posts: 423
|
| Posted: 10 Aug 2009 12:20:25 am Post subject: |
|
|
det(24...) and identity(10...) are being addressed. Thanks.
EDIT: Loaded to $8000 is a routine to transparently track the location of the "current" line being read. "Transparent" being that the routine that uses it doesn't need to know whether or not the information is in RAM or Flash. det(23...) calls fGetLineNumCore on line 176 of _CFN.z80, which calls setupfindline located at line 447 of _UTL.z80. I hope this explanation makes it a bit clearer since the last one I gave was rather... vague.
The first post is being edited to track changes.
Last edited by Guest on 10 Aug 2009 12:11:40 pm; edited 1 time in total |
|
| Back to top |
|
|
JoeYoung
Advanced Member
Joined: 15 Nov 2008
Posts: 316
|
| Posted: 10 Aug 2009 01:38:10 pm Post subject: |
|
|
oh sweet, thanks for reporting this, simplethinker. I'll just wait till a revised version comes out.
And yeah, I noticed the text problem too. My recent submission to ticalc covers that bit up so it wouldn't change anthing..... |
|
| Back to top |
|
|
ajlitzau13
Newbie
Joined: 19 Jan 2009
Posts: 9
|
| Posted: 10 Aug 2009 05:11:08 pm Post subject: |
|
|
I have found another bug in the drawtext command in version 3.09r. If I use the identity(10...) command in a program and later use the text() command, the graph screen is cleared before the text is drawn. Here is an example:
Code:
ClrDraw
real(0,0)
identity(10,1,0,0,"TEXT")
real(6) ;Updates screen because identity(10...) does not.
Pause
Text(-1,8,1,"TEXT IS GONE")
However, if you get rid of the ClrDraw at the beginning, you don't have the problem.
You say in the readme to use text() instead of identity(10...) if you want to update the LCD. However, I think you should make identity(10...) able to update the LCD, because with text(), you can't use inverted text or the hex string option. Also, if identity(10...) was able to update the LCD, we could get away from using text() altogether and avoid the bug mentioned above. |
|
| Back to top |
|
|
simplethinker
snjwffl
Active Member
Joined: 25 Jul 2006
Posts: 700
|
| Posted: 10 Aug 2009 05:24:50 pm Post subject: |
|
|
ajlitzau13 wrote: I have found another bug in the drawtext command in version 3.09r. If I use the identity(10...) command in a program and later use the text() command, the graph screen is cleared before the text is drawn.
The problem comes from the ClrDraw, not identity(10. When ClrDraw is executed the graph screen isn't actually cleared, but a flag is set saying "next time the graph screen is displayed, clear it". You should be able to get around this by using real(0 to clear the screen instead of ClrDraw (I also have a feeling the same thing happens when you use the sprite or tilemap commands and a ClrDraw as well).
[edit] The cause of the problem is actually using identity(10, so even if identity(10 is extended to update the LCD, once you display the graph screen it will be cleared.
Last edited by Guest on 10 Aug 2009 05:30:11 pm; edited 1 time in total |
|
| Back to top |
|
|
ajlitzau13
Newbie
Joined: 19 Jan 2009
Posts: 9
|
| Posted: 10 Aug 2009 07:05:41 pm Post subject: |
|
|
| Ok, I understand what I was doing wrong now. I guess all I want is for identity(10...) to be able to update the LCD. It seems like something that would be quite easy to implement, and I see no reason not to. |
|
| Back to top |
|
|
simplethinker
snjwffl
Active Member
Joined: 25 Jul 2006
Posts: 700
|
| Posted: 10 Aug 2009 09:06:01 pm Post subject: |
|
|
ajlitzau13 wrote: It seems like something that would be quite easy to implement, and I see no reason not to.
Maybe, but identity(10 has three more arguments than text(, and then adding an argument for updating the LCD would mean needing twice the number of arguments, which means unnecessarily inflating code in a language where every byte counts.
[edit] I'm just putting this here because I'll probably forget it by tomorrow. To extend my 'fix' to when the offset of the final line is on a byte boundary, I think
Code:
inc (IX-2)
jr nc, $+2 ;or whatever it takes to skip the next "inc"
inc (IX-1)
is all that's needed.
Last edited by Guest on 10 Aug 2009 10:26:59 pm; edited 1 time in total |
|
| Back to top |
|
|
ajlitzau13
Newbie
Joined: 19 Jan 2009
Posts: 9
|
| Posted: 10 Aug 2009 10:27:30 pm Post subject: |
|
|
Quote: Maybe, but identity(10 has three more arguments than text(, and then adding an argument for updating the LCD would mean needing twice the number of arguments, which means unnecessarily inflating code in a language where every byte counts.
Ok, but like I said before, text() doesn't allow you to use inverted text or the hex string option, which limits your abilities. Also, almost every other graphical command in Celtic 3 gives you the option of updating the LCD, so why shouldn't this one? I think the few exta bytes are worth having the ability to do more in a single command (rather than having to use det(19) or real(6) after identity(10...) to update the screen). |
|
| Back to top |
|
|
JoeYoung
Advanced Member
Joined: 15 Nov 2008
Posts: 316
|
| Posted: 10 Aug 2009 11:53:21 pm Post subject: |
|
|
ajlitzau13 wrote: Quote: Maybe, but identity(10 has three more arguments than text(, and then adding an argument for updating the LCD would mean needing twice the number of arguments, which means unnecessarily inflating code in a language where every byte counts.
Ok, but like I said before, text() doesn't allow you to use inverted text or the hex string option, which limits your abilities. Also, almost every other graphical command in Celtic 3 gives you the option of updating the LCD, so why shouldn't this one? I think the few exta bytes are worth having the ability to do more in a single command (rather than having to use det(19) or real(6) after identity(10...) to update the screen).
I'm inclined to agree with ajlitzau13 here, adding one more argument for this sort of thing seems to outweigh a few bytes being taken up. I don't think it's a huge problem. I think it would do well as far as simplifying any of the BASIC code using this feature.
EDIT: simplethinker isn't wrong, though. It isn't NECESSARY. But I think it would be nice having it.
Last edited by Guest on 10 Aug 2009 11:54:28 pm; edited 1 time in total |
|
| Back to top |
|
|
Iambian
Advanced Member
Joined: 13 Mar 2004
Posts: 423
|
| Posted: 18 Aug 2009 08:51:38 pm Post subject: |
|
|
Released C3.09s http://www.unitedti.org/index.php?s=&s...st&p=135672
This implements a fix supplied by simplethinker, and a fix/upgrade to the DRAWTEXT command. See the ReadME for further information.
The first post of this thread tracks what identified bug has been fixed and what hasn't. |
|
| Back to top |
|
|
Graphmastur
Advanced Member
Joined: 25 Mar 2009
Posts: 360
|
| Posted: 18 Aug 2009 09:07:29 pm Post subject: |
|
|
| can you fix the real 12 next? |
|
| Back to top |
|
|
Iambian
Advanced Member
Joined: 13 Mar 2004
Posts: 423
|
| Posted: 18 Aug 2009 11:17:18 pm Post subject: |
|
|
Graphmastur wrote: can you fix the real 12 next?
All things will be fixed in due time.
I would encourage you to find new bugs and report those findings. Or if you feel like re-reporting real(12...), provide some detailed information about what exactly is going wrong, like under exactly what conditions does the actual results deviate from the expected result. That kind of stuff.
Keep an eye on the first post. Any fixes will be reflected there. Also, new bug findings will be reflected there.
Last edited by Guest on 18 Aug 2009 11:48:05 pm; edited 1 time in total |
|
| Back to top |
|
|
JoeYoung
Advanced Member
Joined: 15 Nov 2008
Posts: 316
|
| Posted: 19 Aug 2009 12:03:28 am Post subject: |
|
|
| when will you enable copybox? :/ |
|
| Back to top |
|
|
Weregoose
Authentic INTJ
Super Elite (Last Title)
Joined: 25 Nov 2004
Posts: 3976
|
| Posted: 19 Aug 2009 03:50:04 am Post subject: |
|
|
metagross111 wrote: when will you enable copybox? :/ Perhaps in due time? Maybe sooner, if illustrative code is provided for it in the Feature Requests topic. As it is, something that's on the table but hasn't been implemented yet doesn't really fit into the "bug" category (and is probably best kept out of this thread).
Last edited by Guest on 19 Aug 2009 03:53:12 am; edited 1 time in total |
|
| Back to top |
|
|
Eeems
Advanced Member
Joined: 25 Jan 2009
Posts: 277
|
| Posted: 14 Sep 2009 05:05:19 pm Post subject: |
|
|
ok, so I'm using Celtic 3.09s
and yeah...the matrix to string command isn't working right...I tried a few different syntaxes...and every one didn't work...
the string I got was filled with "?"'s instead of the right 'bin' chars....I then checked the length, and it was correct, I checked the matrix, and it wasn't filled with 0's....so yeah....I don't know why it did that |
|
| Back to top |
|
|
Iambian
Advanced Member
Joined: 13 Mar 2004
Posts: 423
|
| Posted: 14 Sep 2009 08:58:52 pm Post subject: |
|
|
I've made a few changes the code, and there's also a mistake in the ReadME with regards to the input. The function calls for the actual matrix for the second argument instead of the number of that matrix.
The problem was caused by an incorrect address being passed to the writing portion of the routine. As such, I suggest you back up all your information because the location of the write was unknown, and for all I know, it was either writing back to the matrix with invalid values, or writing elsewhere on the calculator which would invariably cause some sort of adverse effect at some point.
Version "t" will be released shortly (after I get to packaging it) |
|
| Back to top |
|
|
Eeems
Advanced Member
Joined: 25 Jan 2009
Posts: 277
|
| Posted: 14 Sep 2009 09:03:38 pm Post subject: |
|
|
ah ok, well I already had a memory error error when trying to view my memory menu, but thanks to Celtic I saved my valuable stuff by archiving it 
but yeah, thanks...I was using both that syntax, and the one that was wrong too btw
sweet! can't wait to try it out! |
|
| Back to top |
|
|
|
Celtic III => Your Projects
