I recently began to organize my giant collection of Files/Programs. i did this by changing things like locking some, hiding others, and deleting the rest. after i deleted about 6 useless programs, my calculator crashed. I turned it back on and started organizing again. I delete more things and during somewhere around the 10th delete, my calculator crashed again. I don't know if it specifically has to do with deletes because i did other work between deleting but it only crashed on a delete.
Doors CS 7.2
TI-84 plus
OS 2.43
KermMartian wrote:
Ivoah wrote:
Which error? Can you tell to where your code gets before the error triggers? Which version of Doors CS are you using?
The error was happening on line #7, as it should.
I'm running DCS 7.2
Is that code directly from SourceCoder? Because you wrote this:
Code: Get(|L1
But in SC, it seems like you get a list with name "1", not L1 or whatever. A list name must start with a letter, not a number.
For those of list 1-6 that the calculator comes with, you don't need the | symbol in front. That symbol is the token for a small L in source coder.
Haobo wrote:
For those of list 1-6 that the calculator comes with, you don't need the | symbol in front. That symbol is the token for a small L in source coder.
yeah, I fixed it, but 2: Goto should still have worked.
Homerun doesn't work with unsquished assembly programs
DoorsCS clears plotSScreen/graphscreen before launching an assembly program. Example where this behavior is bad: Program uses the data on graphscreen as level.
Back port the real() fixes and app support from DCS 8
[edit]
Also the DCS6 header incorrectly calculates offsets for the unarchive portion of the header if the icon string has its closing quote. This should probably be documented, since the sprite editor in source coder terminates its strings.
I was talking with some users on SAX this morning in regard to a glitch when using a program with Celtic3/DCS library commands. The program would randomly quit when run with the libs disabled in DoorsCS but would work fine with the libs active and with the dependent feature turned on and off. Initially I believed the glitch was in my program, which led to my sharing the program here this morning.
However, I was just possessed with the idea of RAM clearing, so as to totally purge the DCS hook from memory and attempt to run the program with no DCS interference at all -- it worked fine. This leads me to the conclusion that the glitch is not actually in my code at all but is in DCS's hook. Somehow, when the libs hook is disabled, it is not handling ignoring the commands properly. So Kerm, I have a bug for you. When I get home, I'm going to test with Celtic3 and no DCS to see if the same issue arises. I have enclosed the program for use with reproducing/testing this bug.
http://www.mediafire.com/download/npqqmnl8g5b488s/POLYAIO3+TI-84+Plus+Silver+Edition.8xp
Although I was lucky and almost no data was lost, some of the Doors CS 7.2 xLib routines once froze and another time crashed (RAM reset) my calculator.
I am not quite sure what is going on there, I and PT_ need to analyze the code further to find out ehat exactly crashes.
Anyways, our algorithm uses the DrawShape ("real(12,...)"), ScrollScreen ("real(4,...)") and RecallPic ("real(3,...)") commands.
With some certain input it either throws an error and if pressing 2:Goto exits to the homescreen or once it froze and another time just crashed.
No libraries/external programs are used other than Doors CS, and we use TI-Basic, so the problem must be with Doors CS or, very unlikely, TI-OS.
I am running Doors CS 7.2 on a TI-83+ (Not SE) with TI-OS 1.19 installed. Me and PT_ have similar issues.
If that helps, I have ~16500 byets of RAM and ~33500 bytes of Flash Memory free. My last Garbage Collect was relatively long ago.
Nik wrote:
Although I was lucky and almost no data was lost, some of the Doors CS 7.2 xLib routines once froze and another time crashed (RAM reset) my calculator.
I am not quite sure what is going on there, I and PT_ need to analyze the code further to find out ehat exactly crashes.
Anyways, our algorithm uses the DrawShape ("real(12,...)"), ScrollScreen ("real(4,...)") and RecallPic ("real(3,...)") commands.
With some certain input it either throws an error and if pressing 2:Goto exits to the homescreen or once it froze and another time just crashed.
No libraries/external programs are used other than Doors CS, and we use TI-Basic, so the problem must be with Doors CS or, very unlikely, TI-OS.
I am running Doors CS 7.2 on a TI-83+ (Not SE) with TI-OS 1.19 installed. Me and PT_ have similar issues.
If that helps, I have ~16500 byets of RAM and ~33500 bytes of Flash Memory free. My last Garbage Collect was relatively long ago.
Addition: you will get a Syntax Error if the left bound of a shape > 95, so Code: real(12,7,96,0,97,64,1
will give an error.
EDIT: it froze when the upper bound > 63, so Code: real(12,7,0,64,96,66,1
will not work, then the calc freezes.
I have two that have to deal with libs and a misc one
1. I was using ErrorHandle det(25,function,string)
It launched the specified program and when I pressed ON, RAM cleared.
2. ChkStats
Code: det(4,3)
shouldn't return the string value of "2CubicReg 55"
on 2.55 MP on a TI-84 Plus
Doors CS 7.2
DCSB 5
3. Even if on hooks and homerun hooks and run at startup are all off, if you launch dcs, your OFFSCRPT var is overwritten.
New bug! I'm working on adding asm libraries supplied by Dcs into my SysTools v3.0 program, and parts are being erased, overwritten, corrupted, and even copying chunks from the beginning over random parts mid-line further down. Please help! I lost all of my program to Dcs aside from my header which is pasted over every line now
This happens only when breaking a program to access the dcs program editor and it happens regularly
Apps installed:
Calcsys
Doors CS 7
Omnicalc (no hooks)
Start-up Customization (no hooks)
Bugs with the Home run hook
The output( trick to hide the Done message doesn't work
Turning off lowercase won't work if the home run hook is on and the TI-OS Lowercase setting is checked
The Output() trick only works on OS 2.43 or older.
DJ_O wrote:
The Output() trick only works on OS 2.43 or older.
But it works on my TI-84 Plus on 2.55 MP without Doors CS hooks, but with hooks, it says Done
When using libraries in Doors CS 7 to get the calculator ID, the hardware version digit (3rd digit) and the first digit of the serial number (4th digit) is incorrect
Comments2010 wrote:
When using libraries in Doors CS 7 to get the calculator ID, the hardware version digit (3rd digit) and the first digit of the serial number (4th digit) is incorrect
Are you talking about Celtic III's ChkStats function? Doors CS directly calls the OS BCALL for this and creates a string from what it returns: Code: fChkSerial:
bcall($807E)
bcall(_Op4toOp6) ;move needed data out of harm's way
ld hl,Op6
ld bc,5
jp fBinToString+6
(see https://github.com/KermMartian/Doors_CS_7/blob/master/c3_cfn.asm).
KermMartian wrote:
Comments2010 wrote:
When using libraries in Doors CS 7 to get the calculator ID, the hardware version digit (3rd digit) and the first digit of the serial number (4th digit) is incorrect
Are you talking about Celtic III's ChkStats function? Doors CS directly calls the OS BCALL for this and creates a string from what it returns: Code: fChkSerial:
bcall($807E)
bcall(_Op4toOp6) ;move needed data out of harm's way
ld hl,Op6
ld bc,5
jp fBinToString+6
(see https://github.com/KermMartian/Doors_CS_7/blob/master/c3_cfn.asm).
Please ignore the following sentence: Yes I was, but where does the "CubicReg " come from?
Comments2010 wrote:
Yes I was, but where does the "CubicReg " come from?
Pardon? Your post didn't mention anything about the CubicReg token.
KermMartian wrote:
Comments2010 wrote:
Yes I was, but where does the "CubicReg " come from?
Pardon? Your post didn't mention anything about the CubicReg token. I need sleep. I was thinking of a different bug. My mistake...
Comments2010 wrote:
2. ChkStats
Code: det(4,3)
shouldn't return the string value of "2CubicReg 55"
on 2.55 MP on a TI-84 Plus
Doors CS 7.2
DCSB 5
I was thinking of this