Thepenguin77's Utilities

[thepenguin77]

Darl convinced me to make this, and I think it's a great idea. I'll just list all of the utilities I've made here. Not all of them deserve their own topic, so this is a great place to put them.

(Alphabetical for now as I go through my list of programs)

AppUnlok
   This runs Calcsys with flash unlocked. Useful if you want to screw with protected ports or look at the certificate.
link

CheckOS
   This returns the 16 bit checksum of your OS, good for if you think you corrupted something.
link

CleanArc
   This program will fix most corrupted archives. If your archive is corrupted: boot holding the CLEAR button, send this program, run it, it will manually garbage collect, and then reboot. Hopefully this will fix your archive. If it doesn't, scroll down to Rebuild.
link

DelCert
   This deletes the certificate of another calculator via usb->SilverLink. This can fix semi-bricked calculators with bad certificates. To use this, you will need to hook a silver-link adapter up to your 84+ (USB8X style) and plug the I/O end into the semi-bricked calculator. Boot the semi-brick into the boot code, (battery + DEL, or most likely in this case, ON) and run DelCert on the good 84+. If all goes well, in 5 min, it will be unbricked. I used this when developing unsigned.
link

Fullrene
   This is an Axiom that allows you to bypass the $C000 execution limit.
Usage:
   Fcdf() - put this at the start of your program to break the execution limit on all calculators (124 bytes)
   Fcdf()^r - put this at the start of your program to break the execution limit on everything but the 83+BE (76 bytes)
link

Group2
   This allows you to make groups from a basic program, and if you Hex it, you can put it in-line in a basic program using some kind of shell. Here are the directions:
 Str3 = group name (all uppercase of course, 8 letter max) Ex: MYGROUP
 Str4 = list of programs to group with identifiers Ex: +A+B-IMPOSBLE-GROUP2
   Identifiers:
     + = regular program (you can edit it in the editor)
     - = protected program (you can't edit it in the editor)
 I'm not positive if it will work with the wrong identifier, never tried it.
link

LearnPi
   Ok, so this isn't a utility, but if you want to memorize PI to 200 decimals, this is a pretty sweet way to do it.
link

LinkPort
   Hey, this program sucks. But if you need a crappy way to toggle the link port state, use this.
link

MemTest
   This app was created after I discovered that I could make the OS run faster by changing a certain port. If you think that your memory is screwing up (highly unlikely unless you overclock) this app can help you determine if it is indeed not working. (This program reads memory in the fastest possible way)
link

NSpeed
   Ever wonder just what speed the NSpire 84+ emulator is running? Well this will tell you.
link

NyanMem
   This program temporarily gives you 64KB more archive space. This should only be used to send apps that are too big to fit on your calculator. A garbage collect will kill this change and might delete part of that super large app.
Usage:
   1. Clear Mem
   2. Run NyanMem
   3. Send super large app
When done:
   4. Clear Mem
link

Patcher
   Source: Use this to easily make patches to your OS. I've included a few sample patch files so you can see how it works.
link

Rebuild
   Use this if CleanArc fails. This program will rebuild your VAT in the case that your archive is corrupted. Run this program after an ON + CLEAR boot and then send all of your programs to your computer. I don't know what will happen if you run this program when your vat is actually full, so make sure it is empty. (i.e., don't run it when the calculator acknowledges that you have programs)
link

Speed
   This will tell you: 1. Your maximum LCD refresh rate, 2. Your CPU speed, and 3. The ALCDFIX delay you need (for NSpires, check out NSpeed)
link

StopTime
   This is a pretty sweet stopwatch. I never actually finished the splits, but it sure looks nice.
link

SymGraph
   This enables the Symbolic and Graph3 hooks. Mostly for use with zStart's "run on zStart"
link

Univrsl
   Source: This is the new univeral flash unlock, please use this instead of the old one. It is only 75 bytes, and best of all, it doesn't corrupt the OS. This includes both a program and an app version.
link

UnlockAll
   Source: This is the flash unlock that I created, it works on everything but the 83+BE and is only 47 bytes.
link

Unsigned
   The main purpose of this is to downgrade from OS 2.55 on boot code 1.03. But total features:
1. Name on about screen
2. Custom certificate revision on about screen
3. Installing unsigned apps
4. Installing unsigned OS's
link

Unsquish
   This program unsquishes an assembly program for easy recall into the Basic editor.
Usage:
  Str1 = name of program to unsquish with identifier padded to be exactly 8 characters with spaces Ex: -GROUP2__
   Identifiers:
     + = regular program (you can edit it in the editor)
     - = protected program (you can't edit it in the editor)
  It will change the first letter of the program to an A and fill it with hex.
  To copy/paste the hex codes, just use RCL to recall the program. Ex: RCL prgmAROUP2
link

zStart
   How could I ever forget zStart? Check my sig for the link.

OS patches (these are all post links)

Here is a link to a post where I put up a whole bunch of my OS mods to fix random things.

2.55 fraction glitch fix (actually caused by old univeral unlock exploit)

Bad address 2.53 fix (In that mega pack above, I screwed up the 2.53 fix)

Moves the Mem Mgmt/Del... menu into Stat>Tests>H so that your "friends" can't delete stuff. 2.53 only. (Rather silly if you ask me) 2.43 version

OS 2.71 - this was an April Fools prank. This file patches OS 2.55 into the dreaded OS 2.71.

More Precision - while not technically more precise, this patch allows your exponents to range from 10^-127 to 10^127

Faster flash access - this makes writing and reading from flash faster. It basically just makes your calculator faster.


If you want to source to any of these, tell me (either via PM or this topic). I'll then add a little "source" link next to the "link". I'm not going to do it right now because I don't want to spam the attachments system. (If you even think you might want the source, tell me. I actually enjoy it when the source link has several downloads.)

Edit: 5-20-12
   Runer got the UnlokAll down to 47 bytes.
   The Universl got a slight tweek

[Yeong]

holy... that's a lot of programs

[Sorunome]

Yeah, that are A LOT of programs!

[Hayleia]

Some of them could be useful indeed (the others are not for my level of programming )
However, there is a problem: should I give you a +1 or leave your respect to 666 ?

edit: someone +1'd you, now I can do the same since you are not evil anymore

[shmibs]

ooh, i completely missed that mem menu patch the first time around. thanks!

[DJ Omnimaga]

That is awesome. Also I really wish CleanArc existed back in Feb 2002 And nice other programs too.

[Hayleia]

Since you know how to do Axioms (Fullrene) and how to unlock flash, would it be possible that you create an Axiom to allow the user to somehow write to flash (like I have an appvar in Flash and want to write to it, without unarchiving it then archiving it back) ?

(I know I already asked in Axiom Request but maybe you didn't see it)

[thepenguin77]

Since you know how to do Axioms (Fullrene) and how to unlock flash, would it be possible that you create an Axiom to allow the user to somehow write to flash (like I have an appvar in Flash and want to write to it, without unarchiving it then archiving it back) ?

(I know I already asked in Axiom Request but maybe you didn't see it)

To be completely honest, aside from the top 15 recent posts, I don't check any topics besides asm/basic projects and asm help.


Ok, but for changing an appvar in flash, there is a really good reason that you don't want to do this, and that is that you can't change a 0 back to a 1. So for instance, lets say you have the number 200 stored in your appvar and you want to increase it to 201, guess what, you can't. You would have to erase the entire sector, or, more simply, create a new copy

However, if you did already knew this and you wanted to use the appvar as flag storage or something, then I suppose I could make the axiom (it's really easy actually) but I have a feeling it wouldn't be much use to you.

[Hayleia]

To be completely honest, aside from the top 15 recent posts, I don't check any topics besides asm/basic projects and asm help.


Ok, but for changing an appvar in flash, there is a really good reason that you don't want to do this, and that is that you can't change a 0 back to a 1. So for instance, lets say you have the number 200 stored in your appvar and you want to increase it to 201, guess what, you can't. You would have to erase the entire sector, or, more simply, create a new copy

However, if you did already knew this and you wanted to use the appvar as flag storage or something, then I suppose I could make the axiom (it's really easy actually) but I have a feeling it wouldn't be much use to you.

No, it is not for flag storage, it is for a savegame in which every value could appear

But you said that erasing the entire sector would work ?
Maybe it would take time of course, but I don't care. In fact, I would like to avoid garbage collecting at all costs, even if it takes less time to garbage collect.

[thepenguin77]

Sorry, garbage collecting is simply the best way. Each of the sectors is 64KB. So, unless you want a 64KB save file, you are going to have to do it the way TI does it.

[Hayleia]

you are going to have to do it the way TI does it.

The problem is not me.
In fact if I asked this, it is because some of my classmates don't know calcs at all but still want games. They don't even know they can archive their progs, so you can easily guess that they have never seen their calc do a Garbage Collecting.
And lastly, one of them told me "Hey, there is a bug in your game. My calc asked to garbage collect and now it freezes".
But, it is not a bug, it is not in my game, and the calc doesn't freeze <.<
This is why I asked.

Sorry, garbage collecting is simply the best way. Each of the sectors is 64KB. So, unless you want a 64KB save file, you are going to have to do it the way TI does it.

If the only problem with this is that it takes time to erase the 64KB, I really don't care. In fact, I copy the savegame in an unarchived copy then save it back to the true one when quitting. I'll only need the Axiom when quitting so speed won't be an issue at all.

[Runer112]

Hayleia, I believe the point thepenguin77 is trying to make is that, unless your save file mostly fills a whole 64KB sector, manually rewriting the save file back over it's original location in flash will produce more flash wear and actually be slower in the long run than archiving it normally with the occasional garbage collect.

If the issue is people who have no idea what garbage collecting is, put a note somewhere to tell them to accept the garbage collect if they're prompted. If this is for Pokemon, to save most Pokemon games you have to hit save, and then confirm it. You could display this note during the confirmation display.

[Hayleia]

Hayleia, I believe the point thepenguin77 is trying to make is that, unless your save file mostly fills a whole 64KB sector, manually rewriting the save file back over it's original location in flash will produce more flash wear and actually be slower in the long run than archiving it normally with the occasional garbage collect.

Ok. I think I understood the main point but what exactly does "flash wear" mean ? -.-°

If the issue is people who have no idea what garbage collecting is, put a note somewhere to tell them to accept the garbage collect if they're prompted. If this is for Pokemon, to save most Pokemon games you have to hit save, and then confirm it. You could display this note during the confirmation display.

Nope, it is not for Pokemon since the savegame is quite small for this one.
It is for a game (secret project <.<) for which the savegame takes 7000 bytes.

edit: 1000^th post

[Runer112]

Hayleia, I believe the point thepenguin77 is trying to make is that, unless your save file mostly fills a whole 64KB sector, manually rewriting the save file back over it's original location in flash will produce more flash wear and actually be slower in the long run than archiving it normally with the occasional garbage collect.

Ok. I think I understood the main point but what exactly does "flash wear" mean ? -.-°

Every time a 64KB sector of flash ROM is erased (which you need to do to modify its contents), that sector degrades a tiny bit. After being erased enough times, it can actually begin failing to retain data, at which point any of your archived data is at risk of being corrupted.

If you used your method of rewriting the save file back over its original location, every save would erase and rewrite that single sector and the swap sector. If you saved 100 times, the sector containing the save file and the swap sector would each be cleared 100 times.

In contract, the OS's archive function rewrites the save file back to an unused location in flash and marks the old save file for deletion on the next garbage collect. When there is no room left to write the save file back to flash, a garbage collection is performed to remove the old files marked for deletion by erasing and rewriting many sectors. But if you've saved 100 times, you may have something like 10 old save files in 10 different sectors. Each of these 10 sectors would only need to be erased once, and the swap sector would need to be erased 10 times. So the flash wear is spread over many sectors and the swap sector is used less, greatly reducing the chance of a sector wearing out to the point that it starts failing.

Theoretically, a sector isn't supposed to wear out for something like 10,000-100,000 erases, numbers which nobody would probably ever reach with either of the above methods of saving. But the first method is still a bad idea in principle. For all I know, the flash sector in which somebody's save file exists could have been manufactured poorly and will start failing after only a few hundred or thousand sector erases. I would not want to be the one to hear about someone discovering this the hard way because of my program causing an unnecessarily high amount of flash wear in one sector.

[Hayleia]

Ok, thanks for the clarification