Would you mind showing us the code?
The code to do this should simply be:

Code: [Select]

.org $9d93
  .db $bb,$6d
  bcall(_Arc_Unarc)
  retThis works because the name of the original program is put into OP1 when the TI-OS starts the program.

That won't corrupt your archive. Firstly, that would just archive the current program, I don't even think you would get a crash. Second, _arc_unarc is pretty safe.

My guess is that TiAddict was using _archiveVar, _archiveVar will archive whatever you tell it to, even if it doesn't make sense. So lesson learned, don't use _archiveVar unless you absolutely have to, like when making groups. Any time else, you can just use _arc_unarc.

Bet you can't guess what I added.

Update!!!:

• Changed "Screen" menu to "Hardware"
• Added in option to allow code execution in when PC >C000. (Actually, all of ram, anywhere)

The only downfall to allowing execution everywhere is that the calculator will never really "crash." Instead, it will just bounce around until it goes into an endless loop or goes to 0000h. I'm not sure what kind of effect this is going to have, so we'll have to see.

---

Sorry Darl, SirCmpwn told me that you could only have 2 letter labels. If 3 letter labels are real, that's an easy fix.

Quote from: thepenguin77 on June 28, 2011, 08:03:12 pm

Yeah, hot_dog, I don't think putting it in the boot code is a good idea, yet. We first need to know what kind of side effects this will have before we make it permanent. (Programs will no longer crash, they will freeze or go crazy.)

Hmmm, that makes sense.  It's for that reason that Crabcake relocks the C000-FFFF area upon shutdown

Wait, you mean you already implemented this? Because if that's the case, then you should save the previous values so that if a person has it permanently unlocked, crabcake won't relock it.

Edit:
    Also with this, you don't to shut down the hooks.

Well, since runer did a (no revision) we can safely assume that this works on all 84+'s and that you don't need to use the special sequence for anything besides port 14h.

Jkag, how about a boot code mod?

Well, first, flash has to be unlocked before you can even dream about changing ports 25 and 26.

But actually, what we've found through testing is that you don't need that special sequence and it doesn't have to be on a privileged page, the boot code does it, but I'm not really sure you need it. I've been just changing them with OUT ($24), a.


So, unlock flash. Then use the ports like normal.

This whole process started a long time ago when FloppusMaximus unlocked flash on his calculator. Then came custom OS's, the key factoring, and finally modifying the boot code. This will remove almost all traces of TI from your calculator, but your not quite done, you still can't execute code >$C000.

However, today, I managed to do it. I executed code all the way from $C000 to $FFFF on page 0.

I was playing around with DrDnar's MicrOS preparing to do some boot code changes, when I got a little scared and decided to play around with the protected ports a little. I kept going down the line seeing what would change, and what wouldn't, when all of a sudden, writing to port (25h) crashed my calculator. After a little bit of experimentation, I figured out that any value higher than 17h caused a restart. Then I noticed that port (26h) also crashed my calculator, so after a bit more playing, I realized that any value lower than 1Ah would cause a reset.

Why this actually happened caused me quite a bit of trouble. I started outputting different values to the ports and seeing what I could get to crash. I tried running all sorts of programs with these ports enabled and I wasn't really getting any results. But finally, four hours later, with lots of trial and error with StarFox, I realized that the programs would crash if they executed ram low in memory. A quick check with a RET placed at $8000 confirmed this and then I was off to test the limits.

Setting port (25h) to 17h crashed when PC went below 9C00h. 16h crashed at 9800h. So obviously it is counting by 400h. I then did some testing with port (26h). 19h crashed at A800h and 1A crashed at AC00h. So again, counting by 400h.

After a bit more testing, I realized that these ports are looking at the ram chip as a whole where page 00h comes first, then 01h, 02h, and so on and setting the upper and lower ram execution limits.

So...
Send 00h to port (25h) and FFh to (26h) and your calculator will never crash from PC execution ever again.


For more details, see the newly updated wikiTi for ports 25h and 26h.

I have a P-0510O. With boot code 1.02.