I have seen DoorsCS, and it appears to be a great program. However, I had problems using MirageOS. My calculator would not function properly, no matter what I did, so I had to contact TI tech support and get a new calculator (luckily mine was still under warrenty). They said that the main cause of problems is assembly games (I know some ASM myself). I asked some people why this was the problem, and they said that the problem was because ASM games sometimes access parts of the memory that is not meant to be accessed and generally reserved for the OS. This makes sence because MirageOS could run programs with virtually no RAM, which is impossible, because memory is required to use commands and create variables.

I want to know if DoorsCS access's any parts of the memory that shouldn't be messed with, or anything else like that (probably from the programmer(s)). Thanks for the help, because I do not want to mess up my calculator again.

somewhere around here is the DCS sourcecode, if you know ASM, that would probably tell you.

Well, I am not an expert on ASM, and stopped learning it once my calculator was messed up, so I only know about half of it. I guess I could read through it, but I probably would not know everything that happened, and might miss something.

Who wrote DoorsCS anyway?

Kerm Martian, who also started this site.

Owner, Admin, that kind of stuff. Some of just hang around here some odd reason and attempt to accumulate a bunch of posts.

I think the only thing that wouldn't be solved by a RAM clear would be writing directly to the archive, which doesn't normally happen.

Which _doesn't_ happen. That calculator has hardware specifically designed to stop that.

Not necessarily true. Do realize that the entire program is in RAM, meaning it can access and use itself for all its RAM needs. Also, there are several hundred bytes of "safe-ram" that programs can use (these are areas of ram that TI says are OK to use)

Hi b-flat, welcome to Cemetech.

OK, what TI told you was indeed true, but it was nevertheless only part of the truth. When they say ASM games access parts of the RAM that are not "intended" to be accessed, they are referring to two separate issues. First, some programs make use of unorthodox RAM reallocation that does not fit within the way TI wants programmers to work with the OS, but which certainly does not cause permenant problems. The other is when ASM programs malfunction and accidentally begin writing to memory locations they do not mean to write to, or accidentally jump to an uninitialized area of memory. Both of these cause random commands to be executed that often crash the calc, nothing that a battery pull won't fix.

However.

The true issue TI is trying to get across to you (which I doubt the support person understands ) is that the most vulnerable part of a TI graphing calculator is its ROM. Interrupt a write to ROM, especially if it's to what is called a Privileged Page, and your calculator may not be able to function. Generally this is because the TI-OS is unable to verify the contents of the ROM, from which it rebuilds the VAT after a RAM clear (a copy of the requisite VAT entry is stored with every program and variable archived in ROM). Basically, the only way you can make a calculator completely nonfunctional softwarewise is to overwrite the Os loader, an incredibly difficult tasks. Therefore, I recommend the following if you still have the calc:

1. Pull out all batteries, including the dim-sized lithium backup battery.
2. Leave all batteries out for at least an hour.
3. Insert ONLY three of the AAA batteries. Then hold down [DEL] with one finger while inserting the fourth AAA. The backup should still be out.
4. With [DEL] still held down, tap [ON] and then let go of [DEL]. If tyour calculator is still functional, it will ask you for the OS.
5. Use a calculator of the same model (like a friend's) or the SilverLink TI-OS loader program to load the OS. If you don't get the message, try this again with CLEAR-ON instead of DEL-ON.
6. If you still have no luck, use it as a hardware modding practice calc.

Thanks for the help/response!

I believe you are correct about it being the ROM that was messed up, not the RAM. I had to send in my calculator to get the new one, and have not used any ASM games after that. What happened was that I would turn the calculator on, random things would happen. Then, when I tried to do anything, nothing happened. When I took out a battery, the screen turned a brilliant shade of blue, even outside of the pixels. I had to clear the RAM again to get the screen back to normal.

I did delete the OS and send it back (several times), but it still would not work. I did all of those tricks you mentioned, except pressing the ON-Clear one. The ROM was most likely fried, then.

I should probably mention that the screen looked really cool while it was blue (apart from the fact that I new it was ruining my LCD).

That's caused by overpowering the LCD. It can be done in controlled circumstances, and while it's been said to destroy the LCD, tests have found that even ten hours of continuous blue cause no detectable LCD decay.

Whose tests? I refer you to this topic at Detached Solutions regarding test mode (and more), particularly Michael Vincent's post on the second page.

I know that, but someone (either Brazucs of UTI or benryves of MC) did the test and found it only ran down the batteries, even though logic says it would harm the LCD.

btw netham's Omnicalc trick is also replicable in xlib and doesn't put the screen in test mode or over power it at all.

Interesting, have to try that out at some point then.

Brazucs left his calculator in test mode overnight and no harm was done to it.

Ah, 'twas Brazucs. There we go then, that's what I had thought I read.