Login [Register]
Don't have an account? Register now to chat, post, use our tools, and much more.
This is an archived, read-only copy of the United-TI subforum , including posts and topic from May 2003 to April 2012. If you would like to discuss any of the topics in this forum, you can visit Cemetech's z80 & ez80 Assembly subforum. Some of these topics may also be directly-linked to active Cemetech topics. If you are a Cemetech member with a linked United-TI account, you can link United-TI topics here with your current Cemetech topics.

This forum is locked: you cannot post, reply to, or edit topics. Z80 & 68k Assembly => z80 & ez80 Assembly
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 Laughing


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
Display posts from previous:   
Register to Join the Conversation
Have your own thoughts to add to this or any other topic? Want to ask a question, offer a suggestion, share your own programs and projects, upload a file to the file archives, get help with calculator and computer programming, or simply chat with like-minded coders and tech and calculator enthusiasts via the site-wide AJAX SAX widget? Registration for a free Cemetech account only takes a minute.

» Go to Registration page
    »
» View previous topic :: View next topic  
Page 1 of 1 » All times are GMT - 5 Hours

 

Advertisement