1

I've recently come across a problem that PedroM has when dealing with programs that can create archived files (For example, I used this sprite editor: http://www.ticalc.org/archives/files/fileinfo/208/20808.html , which can save sprites in C format in a TI text file, and the new GB68k 0.5, which can create save states). What happens is that sometimes it will corrupt the saved file, which will show up as a 1 byte archived file. If you unarchive it, it will turn into a 65536 file. Luckily, If you reset while the file is archived, it will return to the state it was before the error, but from this point on it will just be corrupted again every time you try to save it from the program that created it. When this happens, it also corrupts the archive in general, showing up less archived memory with the mem command and erasing random archived file after a reset .Only a install format will fix this, and that after erasing everything in memory manually and a few resets. There's a slight chance that this problem is more related to the progams used, since I don't seem to have that problem with side (side can open the text files created by the sprite editor), and it also can edit and save archived files. Still, I've been testing these same programs with AMS 2.05 for some days and they don't have this problem. By the way, I tested this on every PedroM avaible, from the 0.80 beta, the 0.81 RC5, and even that ld-tigcc build that Kevin Kofler did. Also, I did all the testing from my TI-89 HW2.
Well, besides this problem, I am compelled to say that I haven't come across any major problem with PedroM(besides the windows problem, but you already know that), and I've been using it since it came out (maybe because I play games like Chrono Fantasy and the old doorsos SF2 that just crash all the time anyway, regardless of the OS)

2

Ok I'll try to look at this problem. Thanks for the report.

3

I wasn't able to reproduce your problem with tiemu, pedrom 0.81 and your sprite editor.
Could you developp a little more how to get it?

4

mmm, I can't seem to fully recreate the problem on tiemu with the 0.81 rc5, but I was close. See, it seems that was causing the problems with the archive was my constant testing of gameboy roms, which requires a lot of archiving and rearchiving of pretty big files. I was able to cause a similar error by sending some gameboy files, archiving them, and then unarchiving and erasing them(which would be the kind of thing I would make to test a game and then finding out it doesn't work well enough) and then sending the same file again. This way, when I tried to open a file in the sprite editor it gave me an error and erased some random files from the archive, but after a reset everything was fine, unlike what happened in my calc. My guess is that, since I used to do this archiving mess a lot, and often just reseted after an error instead of using clean, at one point my archive was corrupted, and it wouldn't fix even after reflashing other versions of Pedrom, since doing this, as I found out, doesn't really do anything with the archive (It even leaves the files there). I assume that installing the AMS 2.05 fixed the issue only because it is abigger file and it replaced the corrupt part or something, which might be the reason that so far I haven't had any problems with AMS 2.05.
Still, I'm gonna do some of this archiving/dearchiving with the AMS 2.05 to see if I have a similar error, and if I don't, I'll give pedrom another go and see if it works now, and if it does, It'll mean that it was a mistake on my part, and you don't need to do anything. By the way, do you recommend me any version of Pedrom in particular to have? I can't use the RC5 too much, since it has that problem that doesn't let you hold the alpha key and type, so I guess that ld-tigcc version is fine.

5

Ok, I will look at the code.

> unarchiving and erasing them
rmarc removes the archives directly.

Question: Are you able to reboot the calculator and to get the prompt command after the archives are corrupted?

6

PedroM 0.81 RC8 should be ok : http://www.medicis.polytechnique.fr/~pphd/preos/pedrom-0.81-rc8.tar.bz2
ChangeLog from RC7 to RC8:

* If Desktop Window has dirty flag, clrscr is done.
Which make the programs using HSR to clean up while existing.
* clrscr clears Desktop window flag.
* Add 2nd+Alpha for Alpha Lock on 89.
* Add flags "StatusError" to display error in status line instead of Dialog Box.
* The handle of the ALPHA key on 89 should look like much more AMS:
Keeping ALPHA while pressing keys, press the alpha keys. Releasing ALPHA, remove ALPHA status.
* clear - clear now erases the screen (just like the clear command).

7

When it happened on my calc, it would show the error and reset (only if I went on and tried to open the corrupt file with the sprite editor. In gb68k, opening corrupt save states would do nothing), the only peculiar thing is that sometimes it wouldn't let me install format(it would run the command but not do anything), so I would have to erase all files manually an reset it a few times for it to work, and that would make the mem command display the correct amount of archive, but when I installed everything again, sooner or later the error would show up again. In tiemu, a simple reset fixed everything. And yeah, I forgot about rmarc. Thanks, I'm gonna try that out.

8

So the "install format" command does not work?

9

Ok, I seem to have narrowed down the problem. It seems that, at some point, if you copy too much gameboy roms(I suppose other big files will do the same), the OS will refuse to archive anymore files, even if there's still archive memory left (this happens both in AMS 2.05 and pedrom, but it happens with about 200k left in ams, and at about 400k in pedrom). The thing is, by using pograms like the sprite editor I mentioned, you can go around this "protection" and keep saving fairly big files in the archive(a 32x32 sprite with 25 frames, for instance). At some point, in AMS 2.05, it will stop saving the files to the archive and start saving them in RAM, and when there's no more RAM, it will throw a protected memory violation(in tiemu, it even brings out the debugger). Still, a reset fixes that in my calc. In pedrom, things are a little bit different, and if you keep saving big files (this takes some time, since the limit starts at 400k), it will have some of the errors I mentioned. For example, when there's about 80k left, if you keep saving files to the archive, it will show that you have something like 250k left of archive memory. At this point, it will throw an unknow error if you try to open a file with the sprite editor, and random files in the archive will be deleted after a reset.
About the install format, it seemed to fix things in tiemu, but, as I mentioned, for some reason it didn't work in my calc one time, and the fact that I just reflashed the os after that didn't seem to help.
It's still a very hard to reproduce bug, but in my humble opinion, it seems that Pedrom has some problems regarding that "limit" the archive has (by the way, it seems to happen only with big files, since I seem to recall that I have filled my archive in the past). I'm just gonna install Pedrom again, and be careful with saving too much stuff in the archive, and probably I won't have this problem again. Thanks for looking into it. If you need anything else, just post a question.

10

Damn, I got the same error again not too long after installing pedrom 0.81 rc8, and I didn't even had too many programs on the archive. Only thing I did was play some megaman on gb68k (and I tested some programs, but this was the first time that I tested them, so I don't see how this can be related), and after a while the save states didn't load, a sign of the error happening, so I'm inclined to say that it might be related to that program more than the sprite editor. Still, I even beat the whole megaman game on tiemu and I don't get this error at all(the thing I mentioned before seems to be unrelated to it). Perhaps it is a problem with my calc? But it works fine on AMS 2.05... Meh, maybe I'm just unlucky. Well, before giving up, my calc has the error right now, and I've not fixed it yet. Would it help if I do an hexdump or something like that? if not, I guess its okay. Thanks anyway.

11

> Would it help if I do an hexdump or something like that? if not, I guess its okay. Thanks anyway.
Yes, I think it may help PpHd.
avatar
Membre de la TI-Chess Team.
Co-mainteneur de GCC4TI (documentation en ligne de GCC4TI), TIEmu et TILP.
Co-admin de TI-Planet.

12

and what value should I use for that? I run "hexdump 0x4000" and nothing shows up, but if I use 0x5000, something else shows. I actually don't know anything about that, so i would appreciate any help.

13

I found out what caused the bug!
It turns out that it's caused by a low battery. Let me explain:
After my previous post, I put my batteries to charge and was ready to tryout bombermaze 0.9b (which, by the way, doesn't work with Pedrom anymore on RC8) and the bug was fixed. After a while, it came back, but I took some batteries off the remote and put them in the calc and the bug was gone. Putting the old batteries on again caused the error to reapear. The problem is, since no emulator that I know of emulates a low battery, this bug is gonna be hard to replicate, but at least we know now what causes it.
Why I've been having this bug so much? because I don't have any rechargeable batteries at hand, so I've been recharging regular batteries, which will lose most of their charge some time after the recharging. Also, I've found that the bug is not that fatal, because replacing the batteries makes everything work again(do not reset, because that might erase some files). As a matter of fact, removing the bad batteries and putting them back fixes it too, though you will corrupt the file again if you try to save it. The tricky thing is, the low battery indicator isn't actually showed when this happens, so it's a little difficult to know when this can happen. Still, I'm just gonna go buy some real rechargeable batteries and have some spares at hand, and that way I can continue to use Pedrom.
However, it counts as a Pedrom bug since this doesn't happen with AMS. But I think you might be on to the solution, since, as I mentioned before, this bug doesn't seem to affect side, and it can still save archived files even with the low batteries.
Well, I'm sorry to have wasted your time before and coming at you with a bug without knowing the cause beforehand. Thanks for your time.

14

No. I thank you for the time you spent reporting such bugs smile

I will try to find what's wrong.

15

It seems the bug is the Check Battery function which doesn't work at all: it should disable the Flash functions if it detects that the Battery level is too low.

16

I have rewritten the Battery checker code in this new RC: t3/?id=2&d=archives/OS/rc/
Could you tell me if it works better?

17

I've installed it and it works great (flavien racine's games work!), but I trew away the old batteries, so It'll take some time until my new batteries are drained. I'll tell you if it works when I get to it.

18

Ok.

19

Nope, it didn't fix it. Isn't it possible to emulate a low battery on tiemu?

20

Could you do a hexdump of an invalid archived file?
It may help me.

21

and how do I do that?

22

Find a file which seems to be corrupted.
Do a ls -l
You should see its address.
Then run "hexdump 0x123456" where 0x123456 should be replace by the offensing file.

It will be better if I can see a file before it is corrupted, and after(if it hasn't changed).

23

well, here we go:
first, we got a text(TXT) file generated by that sprite program, and its hexdump is like this(from the 0x2bc032 address, by the way):
35 e5 00 01 20 7b 30 78
30 30 30 37 43 30 30 30
2c 30 78 30 30 30 46 45
30 30 30 2c 30 78 30 30
31 46 46 30 30 30 2c 30
78 30 30 31 30 46 30 30
30 2c 30 78 30 30 31 36
46 30 30 30 2c 30 78 30
When the batteries are low, if you try to save it(even without modifying it), it will show up at another address(in this case, 0x24c032), the hexdump will show up a bunch of FF. At this point, the file shows up as a 64 kb EXPR type file (in tictex, it shows as being only 1 byte, and only shows to be 64 k if you unarchive it). If you unarchive it (it shows at 0x16ff2), the hexdump shows ff 00 00 00 00 00 00 , followed by a lot of 00. If you remove the batteries, the file will return to its previous state before saving it, even with the same hexdump and at the same address, but if you mess too much with the file, even removing the batteries won't fix it. Here is a link to the original file http://home.ripway.com/2005-7/344679/tt.89t, and also to the corrupted file http://home.ripway.com/2005-7/344679/t1.89e. As I mentioned, this error doesn't seem to affect side, and, as a matter of fact, after saving the file with side, that file wouldn't be corrupted anymore, even if any other file I saved still got corrupted. By the way, I've used the sprite editor example because of convenience, but the files get corrupted in all kind of programs, like the gb68k save states and some game's highscore files.
I won't be able to check this for some time because I'm going on a trip, but I hope you can make some sense out of this, because I sure can't. Again, thanks for your time.

24

Ok thanks a lot for your report. I will do my best to fix this problem.

25

There is a new RC here : t3/?id=2&d=archives/OS/rc/
I hope I have fixed the bug in this one.
Note that the archive format has changed: you should lost all the files when installing this new tib.

26

Does-it work ?

27

Sorry for the late reply, I was on vacation. Anyway, here are the results of my tests.
-First, the low battery indicator now works. In previous versions of pedrom, it didn't actually work, and programs that show the amount of battery left like tict explorer, would never show the right amount. Now, such programs show the correct value, and the BATT indicator showed in just a short time after I replaced the new batteries for old ones. I would say it works just as the one on Ti-os.
-The refered archiving bug...Well, it doesn't corrupt files anymore. Now, when the battery is low, it will still save changes and you can work normally...until a reset or a battery change. If you do any of these, the changes will be lost. And, If you happen to create a new file when the batteries were low, it will be lost after the reset. I guess there's still something wrong, because when you save in GB68k with the low battery, it will claim that there's an archiving bug, but it still save the file anyway (at least until the reset)

But, because of the improvement of the battery indicator, now I can know when it's time to change the batteries, so it's not a guess work like before. And, since it doesn't corrupt files anymore, if I really need to make changes to some file or save a game when I don't have fresh batteries avaible, I can get home and send the file to the computer. This way, I will save the changes after changing the batteries(I've tested this and it works, by the way).
So, my opinion is that, while the bug isn't tecnically completely fixed, now the pluses greatly outweight the minuses, and with this, along with other recent improvements (I like how you've been fixing the menu boxes), and the NES and GB emulators making big strides, I can say that now pedrom is a legitimate option for anyone that has a TI-89/92+/V200, etc. For this, I congratulate you for your effort. On my part, I can say that you can move on to other things if you wish. You can still contact me if you want to test anything. Again, thanks.