Author Topic: Bug Reports (Read 456557 times)

Freyaday · « **Reply #1245 on:** May 08, 2011, 02:10:47 pm »

I was wrong; It has nothing to do with ERR:BLOCK
Here's the source that has been destroying my memory with leaks the most.

Freyaday · « **Reply #1246 on:** May 10, 2011, 03:54:55 pm »

I found it.
The memory leak occurs when restoring a backup when a program with the same name already exists.

Builderboy · « **Reply #1247 on:** May 10, 2011, 04:13:34 pm »

I still can't replicate the error o.O What *exactly* are you doing? And make sure you test this after a fresh RAM clear with no hooks installed

Freyaday · « **Reply #1248 on:** May 10, 2011, 04:16:51 pm »

Clear Ram
Open up Axe
Restore a Backup with the same name as an existing program, making Axe overwrite the prexisitng program. (I'm not sure, but it may have to do with the preexisting program being in Archive)
Your memory is now much less than it should be.

Builderboy · « **Reply #1249 on:** May 10, 2011, 04:28:34 pm »

Hmmmm I still can't replicate it. How big is the source program in size?

Runer112 · « **Reply #1250 on:** May 11, 2011, 02:03:01 pm »

I think I've mentioned this bug before, but I'll mention it again because it still persists. If the absolute last code in a program getKey(#), with or without the closing parenthesis, Axe throws ERR: PARENTHESIS. This problem does not exist for getKey(EXP), though.

Completely unrelated, but there's an Axiom system bug that's really annoying me. As far as I can tell, there is no way to prevent $7F bytes in data such as a LUT from being parsed as the REP_NEXT() indicator, thus removing them from the data. Specifying the command type as AXM_DATA does not help.

Quigibo · « **Reply #1251 on:** May 11, 2011, 05:26:40 pm »

Are you using "tok_Data" for the token (which tells Axe not to do auto-replacements)? All AXM_DATA does is add the routine to the end of the program instead of inline (like a subroutine) except it skips the call to it. Maybe I should rename that AXM_NOCALL or something like that for clarity...

Runer112 · « **Reply #1252 on:** May 11, 2011, 05:42:06 pm »

Ah yes, it looks like that does it.

It didn't occur to me that changing the token equate would have any affect on how the command is parsed, which I think is fair to say isn't that strange. But may I ask what exactly the purpose of AXM_DATA is then? Because I'm not sure how having a command that just adds data to the program would be useful. It doesn't return a pointer or anything, so it doesn't allow the data to be used by the programmer. And if the data was needed by another Axiom command, accessing it with something like REP_NET() \ ld hl,sub_Axiom# would add it to the program automatically.

Quigibo · « **Reply #1253 on:** May 11, 2011, 08:51:38 pm »

Oh wait a minute, I think that's the bug. That was something I changed last minute and I forgot to remove it from the Axe.inc. As you can tell by the Axiom SDK, that bit isn't even documented because I had removed it and replaced it with the Token indicator instead. I shall remove it. Either that, or more usefully, It can be the same thing as AXM_SUB except it parses as "ld hl,yourAxiom" instead of "call yourAxiom". But then argument count for that would have to be restricted to 0 or 1.

Runer112 · « **Reply #1254 on:** May 11, 2011, 08:54:04 pm »

That would actually be awesome. That way people could use Axioms to include large amounts of image/pre-calculated data into their program and get a pointer to it for their own uses.

Happybobjr · « **Reply #1255 on:** May 12, 2011, 10:10:58 am »

If your last line is...

Repeat getkey(#)

It returns Error: Parenthesis instead of Error: Block

doesn't really matter but i guess it is a bug

Quigibo · « **Reply #1256 on:** May 12, 2011, 02:16:40 pm »

Yeah I fixed that. Also happened with #Realloc() and all commands that enforce constants as their last arguments.

Runer112 · « **Reply #1257 on:** May 16, 2011, 06:14:09 pm »

A few suggestions/bug reports regarding the new version of Axe:

The nibble reading and writing commands have opposite endianness again. I would suggest changing p_NibSto to be big-endian like the reading commands currently are, since a lot of people complained about the nibble commands being little-endian. Which makes sense, because big-endian style is a lot better for things like reading from nibble tilemaps. Big-endian nibble order better corresponds with how hex data is added and displayed.
p_Safety is, well, I have no idea. It works, but it has lots of code that serves no apparent purpose. I'll post what I think the routine should probably look like following this list.
Probably not a big deal, but if either p_FastCopy or p_DrawAndClr were called immediately after sending data to the LCD, the initial row setting would fail. This could be fixed by moving the safety call after the ld hl,plotSScreen and adding some waste instructions after the initial row setting.
Commands.htm still says that DispGraph^r and DispGraph^rr will not work at 15MHz.

Don't get me wrong though, the new update isn't all bad. The CPU speed and interrupt saving with display commands will make things a lot simpler, and I always love new constant optimizations, of which there were a ton. But on the topic of constant optimizations, although For() loops with a constant upper bound got a slight upgrade, it missed the much larger upgrade that the constant comparisons received. Any chance of sneaking that into For() loops as well?

Code: (Less crazy p_Safety) [Select]

p_Safety:			;Output: af holds state to-be-pushed
	.db __SafetyEnd-1-$	;DESTROYS B, all other registers okay.
	in	a,($02)		;Save model settings
	rla			;BE flag into carry
	sbc	a,a		;00 if BE else FF
	jr	z,__SafetyBE	;Check If model is base edition
	in	a,($20)		;Get current speed setting
__SafetyBE:
	ld	b,a		;Save speed setting
	xor	a
	out	($20),a		;Set speed to slow
	ld	a,i		;pe if interrupts
	di
	ld	a,b		;Restore speed setting
	ret
__SafetyEnd:

squidgetx · « **Reply #1258 on:** May 16, 2011, 06:15:31 pm »

Quote from: Runer112 on May 16, 2011, 06:14:09 pm

A few suggestions/bug reports regarding the new version of Axe:

The nibble reading and writing commands have opposite endianness again. I would suggest changing p_NibSto to be big-endian like the reading commands currently are, since a lot of people complained about the nibble commands being little-endian. Which makes sense, because big-endian style is a lot better for things like reading from nibble tilemaps. Big-endian nibble order better corresponds with how hex data is added and displayed.

..Seconded. Please. Thank you.

Freyaday · « **Reply #1259 on:** May 16, 2011, 06:28:29 pm »

Axe seems to introduce some spooky getkey action at a distance; press GRAPH in the latest upload of xy for an example--that's not supposed to happen, in fact, there's not even a getkey(49) in there!

Author Topic: Bug Reports (Read 456557 times)

Freyaday

Re: Bug Reports

Freyaday

Re: Bug Reports

Builderboy

Re: Bug Reports

Freyaday

Re: Bug Reports

Builderboy

Re: Bug Reports

Runer112

Re: Bug Reports

Quigibo

Re: Bug Reports

Runer112

Re: Bug Reports

Quigibo

Re: Bug Reports

Runer112

Re: Bug Reports

Happybobjr

Re: Bug Reports

Quigibo

Re: Bug Reports

Runer112

Re: Bug Reports

squidgetx

Re: Bug Reports

Freyaday

Re: Bug Reports