I was wondering when this would be on the news... I wonder if Dwedit will be the newest member of DS soon...

A very good shell!!

But it must have some more oncalc options:
- "zip" your files on the calculator
- program icon
- archive / unarchive
- ...

But this is a VERY good start!!

Yeah, being able to compress files on-calc would be nice...but if you're going to put some programs on your calc, just compress them first. (Unless you're lazy like me-that's why the new directory of pre-compressed games is nice. ;-) ). I can't think of any situation where it would help to be able to compress them after sending them-it can't do BASIC programs, and no one writes asm on-calc.

Can't wait to try this out...

But what if you get the programs from a friends calc?

Very true-I forgot about the link.

Because he chose to use pucrunch it is not possible to have fast oncalc compression. The best way to add it would be to use a huffman routine. The only disadvantage is that it would be slower when decompressing.

I would like to see on-calc "zip"-ing, even if it IS pitifully slow at-least you could save alot of space especially on games like Wolfenstein 83

Pucrunch as-is requires way too much RAM even for the TI-89. There is no chance whatsoever to get that to run on a TI-83+ or TI-83+ SE.

The modified algorithm used by XPak might work, but I think it would still need to much RAM for the TI-83+. 24 KB is really very few RAM for compression.

You can run pucrunch on a ti83 but it will be very slow. The "huge" mem requirements are mainly there to make the compression fast.

This will be great!!! I'm tired of running out of RAM, and having archived programs take about a second to start, and coming up with a garbage collect screen every other time.

BTW, this is the third 83+ program that I've downloaded, then found in the ticalc.org news the next day.

>> BTW, this is the third 83+ program that I've downloaded, then found in the ticalc.org news the next day.


Expect that to happen a lot. The archivers and news editor work on different schedules. We could coordinate uploading with an article but it's not really necissary.

Yup, you can tell. Today's for example has a bunch of files uploaded about a half hour past midnight here and then a couple more in the afternoon.

The compression thing is really great. Finally a compressed format had comed usfully to the 83+.

Question:
Will high scores be saved in the compressed games?

-W-

You have to tell the shell which parts of the file it should save. Thus if the developer tells the shell to save the highscores it will.

that is very cleaver.

-W-

It is. It also means the programmers won't have to add writeback code for the high scores.

I didn't know Mirage had memory leaks.

Ion does.

Ohhhhhhh...

What sort of memory leaks? Does it fill up the VAT?

MWM

When you run an ion program, the contents of the program are moved to $9D95, leaving the size bytes and the $BB,$6D bytes behind. Because the size bytes haven't changed, you end up with a 4 byte long program that claims to be much larger.

If the progam fails to return to the shell (ie. 2nd+OFF at a getkey, or maybe an ERR:SOMETHING), you will be back at TIOS, with the program contents stuck at 9D95 and a 4 byte stub hanging in ram. You will see the full size at the delete program screen, but it will remove more than 4 bytes if you try to delete it, usually it will crash too, or delete big chunks of your other programs.

MirageOS also leaves the 4 byte stub with the wrong size bytes in ram when you run a program, but tries harder to prevent failure (for example, you can't press 2nd+OFF). Doesn't always work, I've seen ZTetris fail a lot.

CrunchyOS on the other hand takes a different approach. For Ram programs, it removes the first 4 bytes from the program, then relocates the program AND sizebytes to the start of memory, where it is run from there. If the program fails under this shell, the name entry will point to the correct location, with the correct size bytes, so there is no leak or crash risk when deleting it. It will put the first 4 bytes back on if you quickly run the shell again, repairing the program.

For archived programs, it creates a temporary program named CruEXEC and sticks the sizebytes and data at the start of user ram. The program isn't needed anymore after the save patch is created, so it just gets deleted. If it fails, the program is in the correct place with the correct size bytes, so it can just be safely deleted (the shell will delete it automaticly).

There's also a shell for the regular TI83 with memory leak protection, called Venus. Smallest shell too.

Wow. That explains a lot. What I still don't understand is why some Ion-compatable shells turn off the axes on the graph screen upon quitting even if the axes are turned on in the format menu.

Is CrunchyOS compatable with the 83+ SE? MirageOS always crashes mine :(

I'd guess that the programs (shells) use the graph memory for drawing on and just clear it when they're done. The Graph function of TI-OS doesn't know that the graph is "dirty", so it doesn't clear and redraw it.

At least that's the experience I've had with some TI-86 programs (probably some of my own too).

I think that there is a flag you set to tell the OS that the graph buffer is dirty. I am sure that the SDK says something about it.

Something that I have often wondered about, is what is $9D95? I know that is where the assembly programs are copied to, but why there?

MWM

9D95 is the first byte of user memory.

It's stupid to compile programs there, better to compile to 9D97, which lets the size bytes go at 9D95. Gotta go with what the shell requires though...

Wow-I never knew about those potential memory leaks. That's a really smart way of getting around them in CrunchyOS...yet another reason to use it...