Login [Register]
Don't have an account? Register now to chat, post, use our tools, and much more.
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.

This forum is locked: you cannot post, reply to, or edit 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
Sven.Thomas0


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

Posted: 03 Feb 2010 05:05:10 pm    Post subject:

http://tibasicdev.wikidot.com/2-propztest

I've never used it, so I can't give an example. Smile
Back to top
Display posts from previous:   
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
    » Goto page Previous  1, 2
» View previous topic :: View next topic  
Page 2 of 2 » All times are GMT - 5 Hours

 

Advertisement