[TI ASM] REALLY Weird Bug

[Jim e]

Under what function does this getkey loop occur? I can't even find a link to that. Rather Im seeing other bugs, but not this pausing bug.

In its current state, the game works fine.

If I add in a line of code at the beginning of the game to modify one particular memory address (a variable), the game "freezes."

Code: Select all

ld a,0
ld (BOB_CASTING),a

And by freezes, I don't actually mean freezes... it goes into some kind of strange pause mode and only works if I continually press any key.

If I replace that line of code with one that modifies any other memory address (a different variable, for example), the outcome is the same... still freezes the game when you run it.

Code: Select all

ld a,0
ld (BOB_TALKING),a

So, I wrote a piece of code so that every time I press ALPHA, the value of that memory address (BOB_CASTING) is displayed. The value is 205 as long as I don't modify it at the start of the program like I am trying to do.

Taking that into consideration, I changed the line of code in the start of the program to read:

Code: Select all

ld a,205
la (BOB_CASTING),a

Still freezes.

If I write a piece of code to modify that variable somewhere else in the game (on ALPHA keypress, for example), the game works just fine, even after (BOB_CASTING) is set to 0.

I have checked and re-checked to make sure that no variables are overwriting one another. That's not the problem.

I have also checked every one of my bcall(_getkey) statements, since the "freezing" seems to be stuck in some kind of getkey loop. None of them even get accessed until certain keys are pressed... so I don't think that is the problem either.

There is no endless getkey loop in my code that I can find... but that is what seems to be be happening because when the game "freezes" you can still run it if you hit any key over and over. The fact that it is caused by a getkey loop is speculation on my part.

Also, see the comments in loom.z80 for a second description of the bug.

Yes I read your post the first time, though after much testing I could not see the "freezing". Now I do, By freezing I thought you meant locking up, What I see happening is you animations stopping, I don't consider that freezing, espeicially considering I had over looked that bug.

Did you try dwedits fix?

The appBackupScreen thing? Yes... and it generated a ton of 'Forward Reference' errors. I know what that means, but since ion.inc is included before any references to appBackupScreen are made, I shouldn't be getting those erros . The reason that I use appBackupScreen instead of just $9872 is for portability.

Well I meant replacing getkeys with getcsc and some extra code, but to fix dwedits fix, equate appbackupscreen to $9872.

Well okay its obvious that something is going wrong in the idle call. I look more into it later.

[L4E_WakaMol-King]

Possibly, but if I remember correctly, none of the routines access that memory address that is causing the trouble. And I don't think it is being overwirtten anywhere. I have the size that each variable needs written to the side in comments.

Also, I tried putting appBackupScreen = $9872 at the start of the variable table, but then I got a 'Repeated Label' error. It's weird... like TIASM will only see that part of ion.inc when I don't want it to -_-.

[L4E_WakaMol-King]

Where in memory does my program start? I tried out PTi's debugger... but I don't know if I am in my program or somewhere in a rom call or what.

[threefingeredguy]

$9D95 or $959D, not sure. Probably the first one.

[NanoWar]

The first one, $9D95.
When you get a 'Repeated Label' error you can simply rename 'appBackupScreen' to whatever you like (for example 'FreeRamArea').

[Jim e]

woot, that was interesting. About an hour ago I decided I give your code another go, I had a bitch of a time in pti due to lack of a stack view, but thanks to that send utility cobb made I figured it out. It seems that adding a byte before a certain point causes a crash. So I went through moving a nop to find that point. The problem is in Animate, I'll post the code.

Code: Select all

animate:
	ld hl,0			;  Reset animation counter
	ld (ANIM_COUNTER),hl
	ld a,(WAIT_COUNTER)	;  Decrement Wait Counter if needed
	cp 0
	jr z, animate_skip
	dec a
	ld (WAIT_COUNTER),a	
animate_skip:
	ld hl,SCREEN
	ld b,24
animate_loop_1:
	ld a,(hl)
    ;<Animation tags:>
	ld c,8			;  007 -> 008
	cp 007
	call z, animate_change
	ld c,7			;  008 -> 007
	cp 008
	call z, animate_change
	nop
	nop
	nop
    ;</Animation tags>
	inc hl
	djnz animate_loop_1
	call update
	ret
animate_change:
	ld d,a
	ld a,c
	ld (hl),a
	ld a,d
	ex de,hl
	pop hl          ;I admit it, I smiled when I saw this.
	inc hl
	inc hl
	inc hl
	inc hl
	inc hl
	push hl
	ex de,hl
	ret

I see what you are doing, You want to check if (hl) is equal to 7 or 8 and depending on the circumstance change that value, but you don't want your following code swap it back. So you perform stack play so that your code returns to a different address. Problem is that you didn't count the instructions right so the return of the first animate_change resulted in landing on the address part of the call z, instruction.

Without the "ld (bob_casting),a" this instruction would be performed.

add a,*

By adding a nop instead of ld (*),a.

Rst 00h ;fun

by adding the ld (*),a

ret ; Hence the lack of animation.


So the fix? quite simple:

Code: Select all

animate_change:
	ld (hl),c
	ret

Replace your animate_change code with that.


I'm gonna give you credit on this one. You have understanding of pointers which many new asmers don't get, you also understand the stack, something that drives most n00bs insane and makes them go back to basic. What you lack is a knowledge of the instructions. You should read up on them in ASM in 28 Days, or CoBBs guide(where ever it is). I haven't relied on an instruction guide in a long time, so if someone knows of more please post a link.

However you should know now Stack bugs are probably the hardest to track down. Its hard to see something wrong in code and is usually why people are forced to run line for line in debuggers. If you can I suggest to be careful of the stack until you are more acquainted with asm.

[L4E_WakaMol-King]

Thank you so much! I'm gald to know this bug was actually something really challenging to find and not some kind of stupid mistake on my part -_-. You've been super helpful Jim e. You just moved up to the top of the Special Thanks list. If I can ever return the favor, let me know. And your fix is so simple... brilliantly simple. It even makes the game flow better, since the animate routine doesn't take as long.

On the way to finding this bug, I've heard a lot of troubling things. Is it true that Ion can't read the program if it is bigger than a certain size? If so, then I will need to port to Mirage or some other shell. This game is going to be a lot bigger... I will be lucky if it fits in RAM (and that's not including the data file).

I was under the impression that there was no size limit on the programs Ion could read, considering it can execute programs in the archive. That would be very ironic if it could run programs from the archive but not from RAM.

I plan to port to Mirage eventually anyway. The reason that I use Ion is because I am familiar with it and it's the shell I used back when I played a lot of calc games. I like its simplicity. But if it can't do what I need it to do, I'm not going to compromize my game for it. If I do in fact need to port, is there someone familiar with Mirage willing to help me do that? It will be more than just changing the header... since I use the Ion asm routines a fair bit in my program.

Thanks again to everyone who helped, especially Jim e! I seriously wouldn't be able to do this without a great community like this.

[KevinJB]

I was under the impression that there was no size limit on the programs Ion could read, considering it can execute programs in the archive. That would be very ironic if it could run programs from the archive but not from RAM.

ALL programs run from the ram, the difference is ion just copies it from archive to $9D95.

[L4E_WakaMol-King]

I see. I'm not familiar with the other shells, but can any of them execute programs over this troublesome size limit?

[Jim e]

Ion can run a program almost the size of the ram. However it copies levels that where detected with iondetect to the ram, So you need that much ram availible. Since you are not using levels you could just find the program and then and access it via loadcindpage, from what I could tell it was only strings that should work fine. A better solutions is converting it to an app, You weren't using anything that was particularly app un-friendly so it shouldn't be to hard a task.

Mirageos supports anything ION did, all you must do is change the header.

The size limit is a hardware limitation, no shell can get around it, and maintain compatibility.

[L4E_WakaMol-King]

Hmm, what is involved in converting it to an App? I must admit that I have no idea what apps are compared to regular asm programs.

[Dwedit]

Apps are ROM programs. The biggest difference is the lack of writeback and self modify code. Other than that, it's the exact same thing as asm programs.
Oh yeah, your size also gets padded to a multiple of 16384 bytes.

[CompWiz]

I was under the impression that there was no size limit on the programs Ion could read, considering it can execute programs in the archive. That would be very ironic if it could run programs from the archive but not from RAM.

ALL programs run from the ram, the difference is ion just copies it from archive to $9D95.

Nope, not true. CrunchyOS runs programs from the archive.
It can run all mirageos and Ion programs in this manner. However, the size constraints still exist.

If you want a lot of space, you could go for an app, as it basically does let you use as much of the archive space as you want. But as Dwedit says, it does fill them up to multiples of 16k, so if it's not at or a bit under one of those multiples, it wastes archive space. An asm with extra data file could work though, and it wouldn't waste space.

@Jim e: Nice catch on that error.

[Jim e]

Nope, not true. CrunchyOS runs programs from the archive.
It can run all mirageos and Ion programs in this manner. However, the size constraints still exist.

No they run from the ram even in CrunchyOS, unless dwedit has figured out a way to re-address asm programs and a workaround for smc and dealing with the paging I truly doubt that any programs could run from the flash without major modification.

Everything dwedit said but one more thing, you have to deal with paging if you want to exceed 16k. The benefit is that this allows for huge applications, the size of the entire flash. Now from your style of game, there could be a very simple implementation for this. Keep all maps and pics on the first page, and keep all strings on the second page, since it looks like you will have a lot strings this may work well. But really you shouldn't worry about this until your ready to cross that road.

Also you can't use vputs quite the same, you have to include a different routine.

[CompWiz]

Nope, not true. CrunchyOS runs programs from the archive.
It can run all mirageos and Ion programs in this manner. However, the size constraints still exist.

No they run from the ram even in CrunchyOS, unless dwedit has figured out a way to re-address asm programs and a workaround for smc and dealing with the paging I truly doubt that any programs could run from the flash without major modification.

Writeback for archived programs is implemented by creating and loading small patch files, and archiving those instead of the complete program. This takes up more memory, but the calc will perform garbage collects far less often.

I think CrunchyOS runs programs from the archive, unlike Mirage and Ion, which unarchive the entire program every time they run, and rearchive them when you're done. Because of this, you will get many less garbage collects when using crunchy, as opposed to mirage or ion. A huge advantage of this is that it will cause a lot less wear on the archive. Unlike the RAM, the archive of a calculator will wear out after being used a lot. So if you use your calculator a lot with games and other archived programs, it would be stupid not to use Crunchy. It extends the life of your archive by a Lot. Also, if it crashes, the program is safe in the archive, and will not get corrupted or cleared, even if the ram clears. In mirage crashes can easily corrupt or delete the game.