Log inRegister an accountBrowse CSDbHelp & documentationFacts & StatisticsThe forumsAvailable RSS-feeds on CSDbSupport CSDb Commodore 64 Scene Database
You are not logged in - nap
CSDb User Forums


Forums > C64 Coding > ?stack overload error
2003-10-27 20:42
Dosoo
Account closed

Registered: Apr 2002
Posts: 32
?stack overload error

Those of you who have downloaded my Amebas preview may notice some ugly methods I used to make it work. That made me think of situation which might be possible, but I would like hear an opinion from a more exprerienced coder.

Is there a possibility that using several subroutines and interrupts may cause stack to overload? This is vital information for my project, as I think every time in the Amebas game when new shooter is initialized there is one return address that remains in the stack. That's because at the end of an interrupt there is jmp to the main code loop instead of RTI.

The code works OK, but is there a possibility that after several shots the stack overloads and code becomes unstable? Tell me what you think? Have you ever encountered such a situation?

Any comment appreciated
2003-10-27 22:36
Stryyker

Registered: Dec 2001
Posts: 468
How about pulling some data off the stack that the interrupt puts on there then JMPing to whereever? I've had stack issues in the past where I put more on than I pull off. Once balanced it was ok.
2003-10-28 00:00
CyberBrain
Administrator

Posts: 392
The stack can easily overload. There are only 256 bytes for the stack, so if you try to push more than 256 bytes on the stack, it will overwrite the first bytes of the stack.

So if you shoot enough times you code could crash. (allthough i actually wonder if it would in your case, coz it sounds like you wouldn't use the first bytes for anything once the overflow happens - but unless you're sure, maybe pretty code is better, unless it REALLY optimizes something.. saving 6 cycles for the RTI isn't that much imo)
2003-10-28 09:04
MorGorr
Account closed

Registered: May 2002
Posts: 47
You will have to insert a couple of PLAs in the appropriate place to rid the stack of those garbage bytes.
2003-10-28 09:14
Stryyker

Registered: Dec 2001
Posts: 468
Or sometime like TSX, INX for however many bytes need to be removed then TXS. Same cycles as 2x PLA and after that you save. Only lose on bytes used.
2003-10-28 09:27
Dosoo
Account closed

Registered: Apr 2002
Posts: 32
Let it be noted, that when I have tested the code the stack overload hasn't happened yet. Maybe I should try to play longer.

But that information, that stack resets after overflow is relieving information, in case the bytes that are lost are the first, NOT the last bytes. In my theory my code leaves only one address in stack that is not removed. After that is JMP instruction and after that a new interrupt is set.

Using the information you've given me the stack slowly fills with that same address and although it's ugly coding, the code itself stays stable. That's my theory. Only way to test it is to play my game...

And what comes to ugly code, in my case it doesn't optimize, but it was the only way I could think of to solve a precalculation problem.

Advert: Download Amebas preview in this site and comment the whole game ;)
2003-10-28 10:02
WVL

Registered: Mar 2002
Posts: 902
why not test it by putting the stack pointer on the screen?

that way you can keep track of it's value while playing the game.

so just :

tsx
stx $0400

or you can even write it out nicely if that's too unreadable for you.

if you notice it's dropping, you're making stack-garbage. Just pull enough bytes from the stack in that case (pla pla for 1 irq/jsr)
2003-10-28 11:29
Oswald

Registered: Apr 2002
Posts: 5094

at first: you absolutely shouldnt do things like jumping into the main code from the irq...

secondly: but afterall you did it so... you can:

do pla pla pla after the jmp, to take out of the stack the return adress (2 byte) and the status register (1 byte), so the stack pointer will have the same value as it would have after rti.

...in c64 machine code it doesnt really matter if the stack overflows, the stack pointer just wraps around and nothing happens unless it writes over some return adress(es) you would need later on.

if after every irq you jump to the main loop, and you dont need to return to the subroutines where the irq happened, your solution may work fine without taking care of what the stack does. (unless your main loop is not a subroutine :)
2003-10-28 21:57
Dosoo
Account closed

Registered: Apr 2002
Posts: 32
Thanks for the info.

I know I shouldn't do that kind of code and I'm thinking of other solutions. However my game needs calculations and I think it's more user-friendly to use every single clock cycle for calculating instead of calculating one digit per interrupt so that the code remains beautiful.

Coding continues
RefreshSubscribe to this thread:

You need to be logged in to post in the forum.

Search the forum:
Search   for   in  
All times are CET.
Search CSDb
Advanced
Users Online
Marq/Fit^Lieves!Tuor..
theK/ATL
Unlock/Padua/Albion
Fred/Channel 4
Peacemaker/CENSOR/Hi..
algorithm
The Syndrom/TIA/Pret..
Guests online: 133
Top Demos
1 Next Level  (9.7)
2 13:37  (9.7)
3 Mojo  (9.7)
4 Coma Light 13  (9.6)
5 The Demo Coder  (9.6)
6 Edge of Disgrace  (9.6)
7 What Is The Matrix 2  (9.6)
8 Uncensored  (9.6)
9 Comaland 100%  (9.6)
10 Wonderland XIV  (9.6)
Top onefile Demos
1 No Listen  (9.7)
2 Layers  (9.6)
3 Cubic Dream  (9.6)
4 Party Elk 2  (9.6)
5 Copper Booze  (9.6)
6 X-Mas Demo 2024  (9.5)
7 Dawnfall V1.1  (9.5)
8 Rainbow Connection  (9.5)
9 Onscreen 5k  (9.5)
10 Morph  (9.5)
Top Groups
1 Performers  (9.3)
2 Booze Design  (9.3)
3 Oxyron  (9.3)
4 Censor Design  (9.3)
5 Triad  (9.3)
Top Fullscreen Graphicians
1 Joe  (9.7)
2 Sulevi  (9.6)
3 The Sarge  (9.6)
4 Veto  (9.6)
5 Facet  (9.6)

Home - Disclaimer
Copyright © No Name 2001-2024
Page generated in: 0.043 sec.