This is an archived, read-only copy of the United-TI subforum , including posts and topic from May 2003 to April 2012. If you would like to discuss any of the topics in this forum, you can visit Cemetech's
Your Projects subforum. Some of these topics may also be directly-linked to active Cemetech topics. If you are a Cemetech member with a linked United-TI account, you can link United-TI topics here with your current Cemetech topics.
Celtic III =>
Your Projects
| Author |
Message |
|
simplethinker
snjwffl
Active Member
Joined: 25 Jul 2006
Posts: 700
|
 Posted: 11 Oct 2009 07:20:43 pm Post subject: |
|
|
Celtic3.09s: CoolioJazz pointed out an issue with det(4,3) (ChkStats, get calc OS version) on IRC. Instead of a period (".") in the returned string, it has "CubicReg ". I'm assuming you already knew about this, since the readme entry for det(4 says "note that the period will be bugged. It still works", but since it's not mentioned in any of these topics you've probably forgot about it XD. I think the problem is just that the version number is stored internally as a string of font codes instead of token codes ("."'s font code is $2E, which is "CubicReg "'s token code).
Here's a fix for it, though it seems like there should be a better way to do it. It just copies the first byte, puts $3A (the token code for a period), then copies the next two bytes. Replace the "ldir" around line 862 in _CFN.z80 (after label fChkOSVer in routine fChkstats) by:
Code:
ldi
ld A, $3A
ld (DE), A
inc DE
inc HL
ldi
ldi
|
|
| Back to top |
|
|
Mapar007
Advanced Member
Joined: 04 Oct 2008
Posts: 365
|
| Posted: 13 Oct 2009 02:00:33 pm Post subject: |
|
|
You're correct. The version string is being copied from the OS.
EDIT: Or so I assume...
Last edited by Guest on 13 Oct 2009 02:01:33 pm; edited 1 time in total |
|
| Back to top |
|
|
simplethinker
snjwffl
Active Member
Joined: 25 Jul 2006
Posts: 700
|
| Posted: 13 Oct 2009 03:10:12 pm Post subject: |
|
|
Mapar007 wrote: The version string is being copied from the OS.
Yep, from 0064h. |
|
| Back to top |
|
|
Xeda112358
Active Member
Joined: 19 May 2009
Posts: 520
|
| Posted: 03 Feb 2010 07:39:04 am Post subject: |
|
|
I found a bit of a bug (well, a byte) last week and I have a general idea for a fix:
I was thinking about how the LineRead command might work, when I
suddenly had an idea. I haven't needed to rely on Xtravar Beta
because I could use det(17. I knew that the newline token was
3Fh, so what I did was this:
det(17,"AA3F3FAA3F
And then I made a new program and did Rcl Ans. I deleted the
quotes (OCD, what can I say?) and then I used det(5 to check
the number of lines. The result was four; one plus three 3Fh's.
Even though the program had two lines, each with a hacked
string, the output was off. When I tried to actually read a
line, I either got a ".NULLINE" or the first part of the string
token, AAh. You could make it so that every time a two-byte
token start is encountered, the next byte is skipped. That is
the best fix I can think of, but it may slow the routine down.
Sorry, I tend to be a bit long-winded, so pardon all of the
useless language. Here is my condensed version:
Bug=(2-byte token start)+(3Fh) registers as a line.
Fix=Skip 1 byte after 2-byte token start. |
|
| Back to top |
|
|
Iambian
Advanced Member
Joined: 13 Mar 2004
Posts: 423
|
| Posted: 03 Feb 2010 02:07:27 pm Post subject: |
|
|
ThunderBolt wrote: I found a bit of a bug (well, a byte) last week and I have a general idea for a fix:
I was thinking about how the LineRead command might work, when I
suddenly had an idea. I haven't needed to rely on Xtravar Beta
because I could use det(17. I knew that the newline token was
3Fh, so what I did was this:
det(17,"AA3F3FAA3F
And then I made a new program and did Rcl Ans. I deleted the
quotes (OCD, what can I say?) and then I used det(5 to check
the number of lines. The result was four; one plus three 3Fh's.
Even though the program had two lines, each with a hacked
string, the output was off. When I tried to actually read a
line, I either got a ".NULLINE" or the first part of the string
token, AAh. You could make it so that every time a two-byte
token start is encountered, the next byte is skipped. That is
the best fix I can think of, but it may slow the routine down.
Sorry, I tend to be a bit long-winded, so pardon all of the
useless language. Here is my condensed version:
Bug=(2-byte token start)+(3Fh) registers as a line.
Fix=Skip 1 byte after 2-byte token start.
Interesting observation. Seems like there's someone else out there that knows his/her stuff!
I'll make note of this problem. What really caught my attention while I was going through the token table provided in the app is that the token 2-PropZTest( is also affected by this bug.
On a semi-related note, exactly what does 2-PropZTest( do and how would it be useful in a BASIC program? |
|
| Back to top |
|
|
ztrumpet
Active Member
Joined: 06 May 2009
Posts: 555
|
|
| Back to top |
|
|
|
Register to Join the Conversation
Have your own thoughts to add to this or any other topic? Want to ask a question, offer a suggestion, share your own programs and projects, upload a file to the file archives, get help with calculator and computer programming, or simply chat with like-minded coders and tech and calculator enthusiasts via the site-wide AJAX SAX widget? Registration for a free Cemetech account only takes a minute.
»
Go to Registration page
