Weeell, Ask BrandonW

Err: Bad Address

From what has happened, I can assure you that if you clear all mem with 5+8 then ON, the problems will go away.

The new OS didn't touch user archive. And it is the user archive that is corrupted. Once you clear that out, everything will be back to normal.

Well, doing 5+8+ON said Err: Bad Address. So sent ARCHUTIL to my calc, restored BLAST5 and BRESTORE, pieces of my project, and sent them to my computer. Then did the normal Full Mem Reset. Then I used CERTIMG.8xv and PUTCERT.8xp on the certificate, just in case. Then I retried the OS install...


GREAT SUCCESS!!!


Currently repopulating my calc's memory with the files I want on it.

Yay!!!!

I didn't think that creating groups could screw the OS over. It's good to see you have a working calculator once again.

I believe that my Flash may have somehow gotten unlocked by some routine and stood unlocked for some strange reason, penguin. I have patched the PTT on the OS, so its possible. What else would explain how susceptible the OS was to interference from your program? Also, what else would explain the fact that when my calc RAM cleared, it cleared Archives as well, even thought it was only told to clear RAM?

The archive cannot be written to unless flash is unlocked. So the OS unlocks and locks it every time something is archived, it is just very careful about it so that user programs can't mess with flash.

When someone says that they unlocked flash, they actually found a way to make the OS unlock it, then glitch so that they can change the OS. But flash is then locked back pretty quickly. For example, I just ran my unlocking program, and by the time I opened up Omnicalc's port monitor to see if it was unlocked, it had already been locked.

When you say that your archives were cleared, how do you know this? Did the calculator say MEM cleared, or were the programs just gone. When you boot the calculator holding CLEAR, the OS doesn't look for programs in the archive which makes it look like they are all gone. But the next time it goes to look and finds the weird group, it crashes.

If that were the case, ARCHUTIL would have detected them as being still there, but it saw them as dirty variables, meaning "marked for deletion". Also, when i did manage to get into VAT in CalcSys, it did not detect any Archive programs.


PS: In CalcSys, where do you go to see the values of the OS's "pages", as I was told in this thread to check for FF on some pages.

Ok, they were deleted, as in the calculator says that you can't use them anymore. But it still passes over them when creating the vat. The only way to completely get rid of them is a full clear, or a garbage collect. But since the garbage collect would also get confused when it saw the deleted group, I don't think it would have worked.

To view different pages in Calcsys, press alpha + R. Then type in the page. What I meant by FF's is that one of the OS pages might have been deleted. FF is flash for 00. But your OS was fine.

Ok. What exactly does VAT stand for?

Variable Allocation Table

It's how the OS keeps track off all variables on the calculator. It looks something like this:

Type | OS version | Address | flash page | Name | (repeat).

That's not exact obviously, but the OS makes it by scanning through all of the archive and picking out the programs that aren't marked as deleted.

So the programs aren't actually deleted until garbage collection. The OS redoes this every ram clear, and when all of a sudden the information on a file is totally messed up, the OS can't make it's vat entry and crashes.

I would go buy a new calc.

Why? I'm fully functional again. And, I really don't want to learn the 86k variant of TI-Basic.

Just a point of interest, those are stored in reverse order, so Type is at the highest memory address of the entry, and you step towards low memory from left to right. Also, there's a Type#2 byte after Type, which is where Doors CS (and MirageOS) store their folder information for the given program. Flash page is 0 for programs in RAM, and nonzero otherwise. There's a name length byte after the Flash Page byte, and then the non-zero-terminated Name.