| Author |
Message |
|
SuspendedFour
Newbie
Joined: 24 Feb 2011
Posts: 15
|
 Posted: 30 Mar 2011 07:03:00 pm Post subject: |
|
|
I've released two programs out to my friends, they've found a few bugs.
First, the "Plot 1, Plot 2, and Plot 3" buttons disappear on their Y= menu after running either of my programs and sometimes appear on the graph screen. I suspect that this may have to do with the IY flags I'm dingling with (namely, "textWrite, (IY + sGrFlags)"). Am I obligated to restore the system flags before return control to the OS?
The second bug is a total calculator wipe-out, with your classic random characters and lines running across the screen followed by a RAM reset. The backdrop of this error is that the program runs fine a couple of times and then the issue occurs when exiting the program after a few runs.
I speculate that this may have something to do with the nature with which I am exiting. I'm using the ld SP trick that Asm in 28 Days taught us.
At the beginning of my program I put
[indent][/indent]ld (SPExit), sp
where SPExit: .dw 0
When I want to exit I write
ld sp, (SPExit)
ret
Is there a problem with this?
Last edited by Guest on 30 Mar 2011 07:05:59 pm; edited 1 time in total |
|
| Back to top |
|
|
Impiety
Newbie
Joined: 06 Feb 2011
Posts: 5
|
| Posted: 30 Mar 2011 08:17:40 pm Post subject: |
|
|
| Well, I know that ret will affect SP, but I doubt that your program crashes because of that. |
|
| Back to top |
|
|
Xeda112358
Active Member
Joined: 19 May 2009
Posts: 520
|
| Posted: 30 Mar 2011 08:48:17 pm Post subject: |
|
|
You should restore those flags, yes, and are you by any chance making use of SP? If you are, you should turn interrupts off because the system interrupts use pushes and pops, so that could corrupt some data. I'm not sure if this is the issue for you, but I know this was a problem in BatLib! I hope that is the problem because that should solve it !
EDIT: Also, ret affects SP because it pops the last value off the stack and jumps to the address by loading it into PC 
Last edited by Guest on 30 Mar 2011 08:49:44 pm; edited 1 time in total |
|
| Back to top |
|
|
SuspendedFour
Newbie
Joined: 24 Feb 2011
Posts: 15
|
| Posted: 30 Mar 2011 10:29:53 pm Post subject: |
|
|
I'm not using SP to load data or anything. I'm just storing it away once at the beginning of the program and then using that to exit. I use this method to exit from two nested calls, which means the top of the stack will have my garbage call addresses, but that shouldn't matter I point the stack below them (or above, since the stack grows downward), right?
I just thought of another reason my program might wreaking havoc: I'm using a recursive routine. It pushes three values per reoccurrance and reccurrs about twelve calls deep. But that's only about 2 x 3 x 12 = 72 bytes of stack space (plus return addresses). And I can't think of any procedure I can set up to trace this hypothesis.
Last edited by Guest on 30 Mar 2011 10:30:29 pm; edited 1 time in total |
|
| Back to top |
|
|
Xeda112358
Active Member
Joined: 19 May 2009
Posts: 520
|
| Posted: 30 Mar 2011 11:24:35 pm Post subject: |
|
|
Ah, that could be a problem... You can try this and compare the values it outputs:
Code:
ld hl,0
ld (844Bh),hl ;This is either CurCol or CurRow, I only remember the address XD
add hl,sp
bcall(_DispHL)
ld sp,(SPExit)
ld hl,CurRow
inc (hl)
ld hl,0
add hl,sp
bcall(_DispHL)
ret
You should always make sure that for every push you have a pop, though. Saving and restoring SP should be used in case an emergency exit needs to be performed and the state of the stack is unknown. Also, if the recursive routine produces more pushes than pops... x.x
Last edited by Guest on 30 Mar 2011 11:24:50 pm; edited 1 time in total |
|
| Back to top |
|
|
SuspendedFour
Newbie
Joined: 24 Feb 2011
Posts: 15
|
| Posted: 31 Mar 2011 01:00:36 am Post subject: |
|
|
ThunderBolt wrote:
Code:
ld (844Bh),hl ;This is either CurCol or CurRow, I only remember the address XD
lol.
So yeah...the difference was 65493 (initial) vs 65015 (current) :D
I rewrote the routine using AppBackupScreen as a stack and JRing until the stack depleted. It seems to be working on the emulator--now to hand over this grenade to my friends and see if it blows up. Thanks for the help. |
|
| Back to top |
|
|
Xeda112358
Active Member
Joined: 19 May 2009
Posts: 520
|
| Posted: 31 Mar 2011 09:04:48 am Post subject: |
|
|
Okay, so now if you are using AppBackUpScreen as the stack, you should disable interrupts. The actual stack is only a little less than 400 bytes, and the OS uses a small portion of that, so you overflowed into the vat data x.x I'm glad the problem was found! Also, the calc will seemingly crash at random if you don't use di. Here is an example of what happened to me and I only used SP 8 times each execution!
http://www.omnimaga.org/index.php?action=dlattach;topic=6361.0;attach=5816;image
(It's an image, but it wouldn't let me link to it) |
|
| Back to top |
|
|
calc84maniac
Elite
Joined: 22 Jan 2007
Posts: 770
|
| Posted: 31 Mar 2011 03:29:31 pm Post subject: |
|
|
Well, you don't have to disable interrupts if you are simply moving the stack to a bigger buffer. It's only if you start doing fancy stuff with SP other than using it as a stack that could be problematic.
Edit:
Actually, I suppose any OS code that unlocks flash makes sure that SP is within a certain range. So just don't archive/unarchive stuff.
Last edited by Guest on 31 Mar 2011 03:33:08 pm; edited 1 time in total |
|
| Back to top |
|
|
DrDnar
Member
Joined: 28 Aug 2009
Posts: 116
|
| Posted: 31 Mar 2011 08:16:43 pm Post subject: |
|
|
To a large extent, the OS won't care where you place the stack as long as it's in the physical address space at all times. Can you show us some more of your code?
As for flags, if you're using the flags for anything other than the documented purpose, then yes, you should restore them. Don't trust a bit to be unused just because it isn't documented as doing anything.
Edit: I just looked at the OS code that cleans up after an assembly program runs. You don't need to restore the stack after returning, as the OS will handle that. You only need make sure that your code returns to the correct address, and that SP points to RAM that can be erased. So, just do the following at the start of the program:
Code:
pop hl ; save the return address to jump to when the program is done
ld (returnAddress), hl
; If you play with port 6 (memory mapping for the 4000h-7FFFh bank), do this too:
; in a, (6)
; ld (returnPage), a
And at the end:
Code:
; Restore the page, if needed
; ld a, (returnPage)
; out (6), a
ld hl, (returnAddress) ; jump back to the OS
jp (hl)
Last edited by Guest on 31 Mar 2011 08:38:39 pm; edited 1 time in total |
|
| Back to top |
|
|
tr1p1ea
Elite
Joined: 03 Aug 2003
Posts: 870
|
| Posted: 02 Apr 2011 07:43:01 pm Post subject: |
|
|
| Are you really in a position where you dont know where the stack is at when you quit? |
|
| Back to top |
|
|
|
Z80 & 68k Assembly => z80 & ez80 Assembly
