Author Topic: Bug Reports (Read 466024 times)

nemo · « **Reply #570 on:** July 26, 2010, 05:23:47 pm »

has anyone successfully stored data into a list from an axe parser program? i can't seem to get it to work, and after running this program twice, i get a RAM clear:

Code: [Select]

.B
5->{L1}
GetCalc("L1",1)->A
{L1}->{A}

the program compiles fine, and after running the program once, i end up with the value 0 in the OS var L1. i run the program again, the calc freezes and i get a RAM clear.

calcdude84se · « **Reply #571 on:** July 26, 2010, 05:56:32 pm »

Quigibo, do you mind explaining the floating-point format to us?
nemo, the main problem is that floating-point numbers use a very different format than two-byte integers.

Quigibo · « **Reply #572 on:** July 26, 2010, 06:52:58 pm »

Lists and other floating point stuff is really complicated and I don't know it well myself. You'll have to refer to the TI-Developer's guide to see how floats are formatted. The only thing I know is that they're 9 bytes each and the last 7 bytes are the number itself in BCD. Its way too complicated I think to work with them now in Axe, it will be easier when I get floating point conversions working. For now, just stick with programs, appvars, pics, and strings is my advice.

Also, Runer112 I can't seem to simulate that problem and I don't see anything obvious in the parser that would cause that. Would you mind emailing me an example that I can debug?

calcdude84se · « **Reply #573 on:** July 26, 2010, 06:58:27 pm »

Also, bug I meant to report earlier. I have to pass 7 as the size argument to GetCalc( for real variables else I get memory leaks (too high) or crashes (too low). I guess this isn't a bug, but you should document it

Runer112 · « **Reply #574 on:** July 26, 2010, 10:41:50 pm »

So, any luck with my hexadecimal parsing problem Quigibo?

Quigibo · « **Reply #575 on:** July 26, 2010, 11:18:47 pm »

Yeah, I'm looking into it. I'm working on the masked sprite routine right now so at least I can add something new to 0.4.1 instead of just a bunch of bug fixes. Hopefully I will find and fix them all so I can update late tonight or tomorrow.

DJ Omnimaga · « **Reply #576 on:** July 29, 2010, 03:43:42 am »

Btw did you fix the whole APP issue in 0.4.1? (including on the regular 83+)

EDIT: Actually according to bug reports, the defragmenting issue seems fixed. I'll try on my Nspire later. Any luck figuring out the 83+ issue, though?

Quigibo · « **Reply #577 on:** July 29, 2010, 04:25:38 am »

I couldn't find a pattern in Runner's corrupted data, it seemed to be completely random, but always a high order nibble indicating to me that it's most likely an error in reading the hexadecimal number since if one character gets accidentally read as a zero, that could cause it. My solution to this was to disable interrupts during all of the routines which swap pages (which is all the reading routines) because I fear that could be interfering. I have no idea if that solves the problem or not since I can't replicate it myself, I'll need some confirmation.

In DJ's case the corrupted app he sent me randomly had a zero written to exactly every 256th address, that is all addresses of the form $xxCE, and this isn't the data part of the code I'm talking about, this is the entire application and so some commands got screwed up due to having random zeros written over them. I'm not sure what this implies, but I think its possible that its a problem with the rom chip since the errors are so regular and the app itself compiled completely normally otherwise.

DJ Omnimaga · « **Reply #578 on:** July 29, 2010, 04:31:19 am »

Ouch

, so I guess this migth be my calc, then

I know I recently started having other errors, too, that happened, but I could not always reproduce them. For example, earlier, when running my ball game, nothing happened, it just exited the ASM program, not even a Done message. A RAM clear didn't fix it and I had to reset the archive, followed by the RAM.

One day, I'll attempt sending Illusiat 13 again on this calc and playing it, or maybe of of my game that archives/unarchives, just to see if problems will occur. This calc hasn't been used for BASIC programming for over a year, but a lot of archiving/unarchiving went on since then (mostly grouping progress on programs). I wonder if the flash chip isn't wearing out?

Runer112 · « **Reply #579 on:** July 29, 2010, 11:25:15 pm »

I'm having some problems with division... I was trying to debug the problem in my program with this:

Code: [Select]

Text(0,52,C^213*256▸Dec)
Text(0,58,C^213*256/213▸Dec)

The only difference between these two lines is that one has a /213 at the end. When I run the program, the output is (almost always) incorrect.

I attached a sample program I quickly whipped up to further demonstrate the problem. Almost every division is incorrect, although a few are correct. The divisions always seem to result, in order of commonness: 0s, powers of 2, 18 times powers of 2, 66 times powers of 2, 68 times powers of 2, and if and only if C^213 equals 114, the correct answer of 137.

Quigibo · « **Reply #580 on:** July 29, 2010, 11:53:14 pm »

That's bizarre... the routine isn't mine though it's TI's! I'm using BCALL(_DivHLByA) and the disassembly is showing the executable is setting up the inputs correctly so it must be something wrong with their routine. I'm going to investigate.

Most interesting! With the following input:

Code: [Select]

	ld	hl,25600
	ld	a,213

I disassembled the exact routine the OS uses. Running the input through this exact routine:

Code: [Select]

	push	bc
	ld	c,a
	sub	a
	ld	b,16
loop:
	add	hl,hl
	rla
	cp	c
	jr	c,skip
	sub	c
	inc	l
skip:
	djnz	loop
	pop	bc

Does indeed return the result "0" in HL instead of "120" like it should. Am I misusing something here? This is a 16-bit / 8-bit division right? Why is it failing?

Runer112 · « **Reply #581 on:** July 30, 2010, 12:26:32 am »

Haha wow, the OS division routine doesn't work properly? How have I been the only one to discover this?

calc84maniac · « **Reply #582 on:** July 30, 2010, 12:44:37 am »

Quote from: Quigibo on July 29, 2010, 11:53:14 pm

That's bizarre... the routine isn't mine though it's TI's! I'm using BCALL(_DivHLByA) and the disassembly is showing the executable is setting up the inputs correctly so it must be something wrong with their routine. I'm going to investigate.

Most interesting! With the following input:
Code: [Select]
ld hl,25600 ld a,213
I disassembled the exact routine the OS uses. Running the input through this exact routine:

Code: [Select]
push bc ld c,a sub a ld b,16 loop: add hl,hl rla cp c jr c,skip sub c inc l skip: djnz loop pop bc
Does indeed return the result "0" in HL instead of "120" like it should. Am I misusing something here? This is a 16-bit / 8-bit division right? Why is it failing?

Yeah, it makes sense that it can fail for divisors greater than 128 (and especially ones close to 256). Here's a modified one that should work:

Code: [Select]

	ld	c,a
	xor	a
	ld	b,16
loop:
	add	hl,hl
	rla
	jr	c,overflow
	cp	c
	jr	c,skip
overflow:
	sub	c
	inc	l
skip:
	djnz	loop

Quigibo · « **Reply #583 on:** July 30, 2010, 01:33:09 am »

Ah, so its really 16-bit / 7-bit then. In that case, the name is really deceiving, maybe I should mention this in the WikiTi for that bcall. I might just change the auto-opt to use this optimization only if the constant is smaller than 128 and just use my normal 16 bit division routine otherwise.

Hmm... but that routine is faster for 8-bit numbers. I wonder if it wouldn't be too much overhead to have single routine for both 8-bit and 16-bit divisions that checks if the input is 16-bit or 8-bit at the start and then branches to the correct routine. I feel this might be a large enough speed increase to justify the extra size since i think a majority of divisions are with numbers smaller than 256 which will all be sped up almost double, both when using constants and variables. It would be about 20 extra bytes to the subroutine and only 1 extra byte when calling the routine with a constants smaller than 128 (unless otherwise optimized). This would also increase the speed of signed division. Can I get some opinions on this?

calc84maniac · « **Reply #584 on:** July 30, 2010, 01:36:06 am »

Sounds good to me. Just simply not using a bcall will probably increase the speed of divisions considerably

Author Topic: Bug Reports (Read 466024 times)

nemo

Re: Bug Reports

calcdude84se

Re: Bug Reports

Quigibo

Re: Bug Reports

calcdude84se

Re: Bug Reports

Runer112

Re: Bug Reports

Quigibo

Re: Bug Reports

DJ Omnimaga

Re: Bug Reports

Quigibo

Re: Bug Reports

DJ Omnimaga

Re: Bug Reports

Runer112

Re: Bug Reports

Quigibo

Re: Bug Reports

Runer112

Re: Bug Reports

calc84maniac

Re: Bug Reports

Quigibo

Re: Bug Reports

calc84maniac

Re: Bug Reports