Quote from: calc84maniac on November 14, 2010, 11:14:12 pm

Quote from: Runer112 on November 10, 2010, 05:24:48 pm

EDIT 2: Oh, and in the commands list you accidentally call EXP1**EXP2 signed multiplication instead of fixed point multiplication.

It actually is a signed fixed-point multiplication. The list doesn't say "fixed-point" in so many words, though it does describe the type of number it is.

You're right, there's definitely some signed stuff going on here. But it's a good thing you pointed this out, because now that I look into it more, it appears that the routine itself is buggy. For instance, ᴇ0400**ᴇ2000 evaluates to ᴇ8000, although, it should be ᴇ0000 signed. It seems to be a problem with signed overflows not carrying properly. As another example, ᴇ0410**ᴇ2000 evaluates to ᴇ7E00, although it should be ᴇ0200.

Although it may work perfectly and I'm just misunderstanding how it's supposed to work.

Signed overflows don't wrap around to 0, they wrap around to -128. I do think that the ᴇ7E00 should be ᴇ8200, though. But at any rate, you should be making sure it doesn't overflow anyway.

Apparently Axe does not like a !If / ElseIf / ... / End block, or !If / Else!If / ... / End. Basically, a !If cannot start an ElseIf chain. It gives ERR:BLOCK.

Oh, that's how it happened! I got that ERR:BLOCK too, but I couldn't find what caused it.

^ Nothing happens when I try doing that (you're saying, press APPS while selecting the last item in the list which is a backup file, right?)

Strange. X.x

At least it doesn't seem as bad as the bug involving the ! and # programs in MirageOS 1.1 (horrible stuff happened if you archived those, requring both RAM and archive to be reset)

Another bug report: I've never compiled an app before, so I tried it once with a 3 KB program (just to see what it's like). It compiled normally, but when it started writing to an app, Axe suddenly froze. I waited 3 minutes, because I really had no idea how long it usually took to make an app, but I figured it was probably frozen and pulled a battery. Pretty scary considering Axe was writing to flash at the time, but thankfully all I got was a RAM clear.

Info: I'm using a TI-83 Plus OS 1.19 with Axe 0.4.4 to compile a 3 KB (exec) program into an app. The source was split into 9 programs (one main program and 8 subs). I had 80 KB of free archive space, but since my last garbagecollect was several weeks ago (and the one I did right after the RAM clear took quite a while), I think my archive space was just about filled at the time. Should I try again now that I've garbagecollected to see how it works now?

That happened to me before. Garbage collecting didn't work, but after I deleted some app and the calc defragg'd, it worked. Is defragmenting different from garbagecollecting

Weird, what's the difference?

EDIT: Okay, just tried it again after garbagecollecting, and it ... worked. Huh

Defragmenting and garbage collecting are the same thing, but in different regions in the ROM.  Garbage collecting happens in the general archive where you keep programs and stuff, but defragmenting happens on the app space and swaps entire pages at a time.

Right now, I only force a defragmentation when overwriting an existing app.  But now that I've got a few of these reports, it might be better to always defragment, just in case.  I know it takes a while sometimes, but writing to flash is scary so I'd rather be safe than sorry.

Agreed, and if possible could you add more updates while it's making the app? Like Defragmenting... when it's defragmenting and a % counter while it's actually writing the app.

quick question.

Could you make a program preferably an app that will just defrag the calc?
I have had errors where i was forced to delete an app to cause a defragmentation to fix the problem.