Author Topic: Bug Reports (Read 455869 times)

calc84maniac · « **Reply #1380 on:** July 14, 2011, 08:21:56 pm »

I tried compiling one of my programs and I got a Bad Flash error. I checked my swap sector and it had been erased (the starting byte was 0xFF instead of 0xFE). I tried compiling again and it worked. What the heck was going on there?

Edit: In particular, what causes a Bad Flash error?

Quigibo · « **Reply #1381 on:** July 14, 2011, 09:53:54 pm »

Both of those bugs should have been fixed with the 1.0.1 update. The issue was that the swap sector was being cleared but I forgot to reset the bit to re-indicate it was the swap sector once compiling finished. A bad flash error means that either the calculator could not find a swap sector or that flash failed to unlock.

calc84maniac · « **Reply #1382 on:** July 14, 2011, 09:55:32 pm »

Quote from: Quigibo on July 14, 2011, 09:53:54 pm

Both of those bugs should have been fixed with the 1.0.1 update. The issue was that the swap sector was being cleared but I forgot to reset the bit to re-indicate it was the swap sector one compiling finished. A bad flash error means that either the calculator could not find a swap sector or that flash failed to unlock.

I was using 1.0.1. The swap sector was cleared, which mean flash was unlocked.

I think a better idea, though, is to set the 0xFE byte directly after you erase the page, then use the rest of the sector as you please. After you're done, you won't have to erase it again because the identifier byte is there. (Trust me, I do this with TI-Boy)

Ti-Programmer · « **Reply #1383 on:** July 14, 2011, 09:58:24 pm »

Hey!

Sorry if i am reposting this, i found a small bug in axe (truely in asm moreso) that causes the display to do weird things in the new ti MathPrint OS. (2.55 for 84+SE, 2.56 for Nspire) the quick fix is to enable classic mode (mode, then scroll down till you see "MathPrint Classic" select Classic and press clear, now run asm prgm. Although if it could be helped it'd be better to solve the mathprint bug.

Thanks!

Edit:
Triggered by code:

Code: [Select]

.AXEPRGM
"Hello World!"->Str1
Disp Str1
clrHome

asm(prgmAXEPRGM)
it displays an 'H' and then done the first time (if it is the first entry), the rest just random pixels on a line. (numerous entries on calc screen) I could maybe post a vid for better details.

Freyaday · « **Reply #1384 on:** July 14, 2011, 09:59:15 pm »

What triggers it?

Quigibo · « **Reply #1385 on:** July 14, 2011, 10:12:46 pm »

Quote from: calc84maniac on July 14, 2011, 09:55:32 pm

Quote from: Quigibo on July 14, 2011, 09:53:54 pm
Both of those bugs should have been fixed with the 1.0.1 update. The issue was that the swap sector was being cleared but I forgot to reset the bit to re-indicate it was the swap sector one compiling finished. A bad flash error means that either the calculator could not find a swap sector or that flash failed to unlock.
I was using 1.0.1. The swap sector was cleared, which mean flash was unlocked.

I think a better idea, though, is to set the 0xFE byte directly after you erase the page, then use the rest of the sector as you please. After you're done, you won't have to erase it again because the identifier byte is there. (Trust me, I do this with TI-Boy)

Ah, I always thought the identifier might imply that the sector was expected to be cleared for other programs, that's why I had to erase it twice. Its strange it didn't write the byte there the second time, I guess that would explain the bad flash error.

calc84maniac · « **Reply #1386 on:** July 14, 2011, 10:16:31 pm »

You will always want the first byte to be 0xFE. That's how the OS knows where the flash sector is. If Axe happens to crash while compiling without an 0xFE at the start of the swap sector, the swap sector might be lost. I've had this sort of thing happen in TI-Boy -- the swap sector kept moving higher and higher in flash until it filled up with garbage. Not good.

Quigibo · « **Reply #1387 on:** July 14, 2011, 10:24:15 pm »

Ah okay. Yeah I just realized now that that could happen if the parsing doesn't complete as a result of an error. Is that bug as serious as requiring a ROM clear?

ztrumpet · « **Reply #1388 on:** July 14, 2011, 10:24:58 pm »

Yes. * ZTrumpet looks at the past four (five?) hours of #omnimaga...

FinaleTI · « **Reply #1389 on:** July 14, 2011, 10:30:48 pm »

I had to ROM clear several times as well.

Quigibo · « **Reply #1390 on:** July 14, 2011, 10:34:40 pm »

Alright, I guess its another update tonight then.

calc84maniac · « **Reply #1391 on:** July 14, 2011, 10:44:16 pm »

To be clear, if the OS doesn't find a sector starting with 0xFE, it uses the first sector starting with 0xFF as a swap sector instead. This causes a 64KB memory leak in archive each time.

defmenge · « **Reply #1392 on:** July 15, 2011, 06:02:08 am »

I'm not quite sure what these sector things are, but I guess you're talking about the bug that occurs after compiling which messes up the calc (or in this case, Wabbitemu), causes errors when sending files and clears the RAM after my app has executed until I restore an older saved state or clear the Archive.

It would be nice if you could fix that, I'm currently having incompatibility problems with the room drawing routines (objects and the player disappear sometimes), which I can't fix if I have to restore an old save state after each compile.

Also, I found out that DROD8x outputs a lot of random garbage to the home screen whenever I load a room, even though there is not a single command for printing text inside the room loading code. Perhaps that's related to MathPrint, though I haven't had any problems with that in 0.5.3 and earlier.

Spoiler For Lengthy room loading code:

Code: [Select]

Lbl LOA
Copy(Y1+R,L1+150,144)
sub(LDR,L1+150)
.Random garbage occurs above this line
sub(DRU)
sub(DRR)
If {L1+123}>0
For(I,0,{L1+123}-1)
sub(DRO,I)
End
End
0->{L1+114}->{L1+115}
0->{S+34}
sub(PSW)
Return

Lbl LDR
.r1: DATAPTR
0->{L1+123}->{S+186}
Fill(S+186,288)
For(J,0,11)
For(I,0,11)
If inData({J*12+r1+I},GDB1O)^(length(GDB1O)+1)!=0
{J*12+r1+I}->{{L1+123}*2+S+186}
I->nib{{L1+123}*2+S+187*2}
J->nib{{L1+123}*2+S+187*2+1}
{L1+123}++
0->{J*12+I+S+42}
Else
{J*12+r1+I}->{J*12+I+S+42}
End
End
End
sub(MSK)
Return

Lbl MSK
0->{L1+150}
Fill(L1+150,144)
For(I,0,143)
If inData({I+S+42},GDB1S)^(length(GDB1S)+1)!=0
1->{L1+I+150}
End
End
For(I,0,min({L1+123}-1,287))
sub(OMK^^r,I,1)
End
Return

Freyaday · « **Reply #1393 on:** July 15, 2011, 01:50:01 pm »

A sector is the four pages of ROM that have to be erased at once.

defmenge · « **Reply #1394 on:** July 15, 2011, 02:46:13 pm »

Ah okay, thanks. I've never worked with anything more low-level than Axe and I don't know much about how the TI-8x's flash memory works, so I was a bit confused between sectors, pages, swap memory and why APP sizes have to be multiples of 16 KB.

Author Topic: Bug Reports (Read 455869 times)

calc84maniac

Re: Bug Reports

Quigibo

Re: Bug Reports

calc84maniac

Re: Bug Reports

Ti-Programmer

Re: Bug Reports

Freyaday

Re: Bug Reports

Quigibo

Re: Bug Reports

calc84maniac

Re: Bug Reports

Quigibo

Re: Bug Reports

ztrumpet

Re: Bug Reports

FinaleTI

Re: Bug Reports

Quigibo

Re: Bug Reports

calc84maniac

Re: Bug Reports

defmenge

Re: Bug Reports

Freyaday

Re: Bug Reports

defmenge

Re: Bug Reports