Omnimaga
Calculator Community => Other Calculators => Topic started by: thepenguin77 on August 02, 2010, 03:58:19 pm
-
I was reading the topic about backing up your groups, when I just went, duh, I know what is happening. After a little abuse to my calculator's flash, I managed to pull my own ERR:VERSION. It's actually very simple if you know what you are doing.
Flash is made of sectors, each sector is 65,536 bytes long. Then each sector is split into 4 pages of 16,384 each. When you archive stuff, it is stuck where ever there is room while trying to be efficient. This means that data is allowed to run over one page onto the next, (not a sector boundary though). The only problem is that it is rather annoying to see if the data crosses a page boundary. Normally this is not a problem as TI checks to see if the data crosses the boundary. But if the 9 byte header which has to be processed byte by byte crosses a boundary, ERR:VERSION. This is TI's way of saying since the chance of this happening is only 3*9/65535 = .04%, we just won't bother with it.
Pretty soon I'll be looking to see how this can be patched, I'd imagine it's not too hard, but I'll see what I can do.
Here is the proof of concept screen shot.
Edit:
Whoa, the problem is a lot worse than I thought, that was a completely blank group that it made. It has a flash header, but no data, just FF's.
-
I'm to tired to really understand what you said but from the sound of it basically we are seeing TI's laziness once again?
-
Basically we are seeing Ti being very very undescriptive. Err: Version wouldn't make you guess that the header of a group was split over 2 Flash pages wouldn't it? Err: Flash or Err: Header or Err: Boundary would have been better. Secondly it indeed shows Ti being lazy about getting the header always in the right place, makes me wonder if data actually is at all neatly packed of any prm or app in flash rom. Would there be FF's between several apps? that would indicate that Ti is even more lazy then I initialy thought. Does make something as rudimentary as a garbage collector needed though.
-
So, wait.
How did you trigger this error?
-
What makes groups different than programs and the other variable types though? Because I'm pretty sure those can have headers on the page boundary.
-
My guess is that TI just was too lazy to write in the check for Group names in the ungrouping routine? Or it happened so infrequently that they never even knew the bug existed.
-
I have found one source of the problem. When the OS makes the group, it stores the start page and address in a temporary memory location. It then loads them in the OS specified page and address spot. The only problem is that the routine it calls to setup the group header, happens to also use the temporary memory location. So what happens is that the page gets first put by the main program, then increased by the header program, and finally the main program grabs it and raises it again! These ERR:VERSION groups actually start at the beginning of one page, and restart at the beginning of the next.
What worries me is that the best way to fix the problem was actually to NOP 15 bytes. Not only that, TI went through and optimized this section for 2.53. That means they looked at it, saw nothing wrong, and continued on.
But that's only half the problem! After I patched it up to make the groups, it can't read them. The group was definitely created successfully because GrpTool can read it. Plus it was readable after it got relocated on a garbage collect. TI just doesn't want us to use groups.
So, wait.
How did you trigger this error?
I GC'd to erase all memory. Then I filled the first flash page up until it only had 3 bytes left. (Flash isn't truly erased until GC it is just marked dirty). Then I made a group.
What makes groups different than programs and the other variable types though? Because I'm pretty sure those can have headers on the page boundary.
What makes them different is that they have very specific code that creates and reads them! The ERR:VERSION groups function normally anywhere else, unless they corrupted the next page.
Now I'm off to find part two of this horrible group handling.
Edit:
Found the second one, it only occurs if the group starts <4 bytes from the end of a page. TI almost did it right, they checked for page crosses, it's just that they assumed that it wouldn't change pages.
Edit 2:
For those that want to jump the gun, I finished the patch for 2.53. Tomorrow I'll have to make one for 2.43, maybe the 83+ and SE too if I can find some roms. It won't run on anything but, 2.53. Don't run it if you know your batteries are low and especially don't pull a battery. I was even nice enough to make it so that it won't say ROM failed in the self test.
-
One last question:
Is this error something someone would run into practically or is it from stress test only?
-
@Raylin: I don't use groups (There have been issues that turned me off of using them), but this does actually happen sometimes. It's poor programming on TI's part really.
-
I have no idea if this applies or not, but does a defragmentation fix the ERR:VERSION? I once grouped a project and it ended up with that bug, then accidentally deleted MirageOS, and the group suddenly worked again.
-
This looks like another unofficial patch to fix TI's bugs... people, keep them going :)
-
Awesome! I can't wait for the 2.43 version! ERR:VERSION caused me to lose quite a bit of stuff over the years, so this is great!
-
Here is the fix for 2.43.
While we're on the topic of protecting groups, I also added in two more programs. For 2.43 and 2.53 respectively, these stop the OS from deleting all your groups during press to test. It has always bothered me that it disables all your programs, and then deletes all your groups.
As far as these patches go, they are all undo-able. When you run them, a menu pops up with a fix and unfix option.
-
Wow I missed this entire thread x.x
Nice to see someone else fixing TI's problems :P
I'm getting the patch right now. Good job! +1 for you. :D
-
Woah! I missed it too. It's wonderful to see you fixing the problems. Thank you! +1 also! ;D
Any chance of a 83+SE Patch? :D
-
Here is the fix for 2.43.
While we're on the topic of protecting groups, I also added in two more programs. For 2.43 and 2.53 respectively, these stop the OS from deleting all your groups during press to test. It has always bothered me that it disables all your programs, and then deletes all your groups.
As far as these patches go, they are all undo-able. When you run them, a menu pops up with a fix and unfix option.
Wow, this is great! Another bug fixed! :D
And then I ruin the celebration :(
I just got another bug with grouping, which allowed me to ungroup some but not all of the files in the group. The ungrouping stopped halfway with a different error: ERR:MEMORY. I'm sure there was plenty of space, both RAM and archive, because larger groups still worked perfectly. Then I did a GarbageCollect, which took only a few seconds, proving that there was still a lot of free archive space. For some reason, the group then worked. It's actually happened before, too, but the last time I had it happen to me was a few years ago, so it's about as uncommon as the bug in the main topic. Does anyone know about this one?
-
Oh wow I remember that one. I had it happen with some group files back then. Sadly I did not know how to use Calcsys so I lost the files. Idk if the cause is the same as ERR:VERSION...
-
Seeing that a garbage collect fixed it, it would mean there is another way to make a group straddle a page boundary that causes problems. If you can find a way to repeat the problem, I can fix it. But until I can watch the variables in an emulator that does the error memory, I really can't fix it.
-
Seeing that a garbage collect fixed it, it would mean there is another way to make a group straddle a page boundary that causes problems. If you can find a way to repeat the problem, I can fix it. But until I can watch the variables in an emulator that does the error memory, I really can't fix it.
I'm really bad at using Calcsys, so I probably won't be able to, unfortunately. Except by accident :P
-
I'm just wondering, are the patches permanent? Like when you ram clear or even all clear, the ERR:VERSION error won't occur again? I just really want to not have to keep the patches on my calc forever :P
-
Yeah, it's permanent, unless you resend the OS :P
You can get rid of the patching programs after you've done it, since not even a reset all will undo them. (Again, only an OS resend)
-
On that same note, you can't send your OS to someone else while you have the patch installed. That's why I have the undo option. Although for most people this isn't really a problem. It only becomes a problem when you have that person who managed to delete their OS or similar. (Pulling batteries during garbage collect) And you have to send them a new one. But for the most part, you can always find a clean OS.
-
What does happen? Does it refuses to send due to not being signed or something?
-
Yeah, it's certainly due to the TI-Z80 OS checking the signature before trying to send itself to another calculator. That's what the TI-68k OS does, at least.