- This topic has 522 replies, 8 voices, and was last updated 4 years, 8 months ago by
.
-
Posts
-
So, what data is located at the top of the “data ram” right next to the bottom of the “stack ram”? I know that there are different layouts. Now assume for a second that the stack would go too deep in some layout. What sort of information would be corrupted?
Told you before 🙂
See: http://vide.malban.de/forums/topic/downloadable-vectorblade-versions/page/17#post-5026
The stack can quite easily be extended, because exactly below the stack are all dynamic lists. Make any one of the lists shorter -> than you have more space for the stack.
The list nearest are the playerShots.
As said – upon each level these are newly initialized!And… the contents is fairly “short lived”…
And I already admitted to being a pain in the back 🙂
I work meticously by nature 😉 And if some ram gets corrupted, there must be a reason…
Hi there, this is the early morning post of relentless me 😉
The reason, why I am being so picky here is as follows. There is an infamous probability fallacy. When gathering theories, which are all deemed unlikely, at some point (once there are enough unlikely theories), it becomes unlikely that none of them is true. If you give all our present unlikely theories a chance of just 1%, and let us say we have 10 such unlikely theories, then the probability that none of them is true, is 90.43820%. In other words, we already have approximately 10% chance, that one of them is true. If you give each unlikely theory 5%, then the probability of at least one of them being correct is around a whopping 40%.
At some point we must progress from just deeming a hypothesis as unlikely to ruling it out. And we should only rule it out if we have considered every aspect of it, or if we have sufficient proof for it not being true. That is the (mad) scientist inside me speaking.
I am (still) considering stack corruption. I agree with all your argumentation. And thanks for explaining some points over and over again (sometimes my brain memory also seems to have ram failures).
Now, there could still be a “sneaking stack pointer corruption”.
Assume the following scenario: Initially, the SP is set to STACK_BASE. So whenever the stack-depth (the fill level) is zero, SP should have value STACK_BASE. If, at some strange point AREA_52 during program execution, one of the previous “pushes” is not “pulled”, then we can reach a situation where stack-depth is zero and SP is at STACK_BASE+1. Now, the stack can overrun into the heap-data. It will corrupt a bit of the, say, shot-data entries, and then the stack goes back to depth zero and STACK_BASE+1. Your next code initializes the shot-data, and everything will work fine. After the next time AREA_52 is visited, SP will be at STACK_BASE+2 when going to stack-depth 0. Some more of the shot-data entries are corrupted, but again no harm. But after enough visits of AREA_52, SP will eventually transgress beyond the shot-data and go deeper inside the heap. This still might not lead to a crash, if everything is correctly initialized, but the whole situation is getting more and more dangerous…
I have seen such a thing happen in my past programming life. Good thing, there is an (easy?) test. Do long-run experiments, and inspect SP in situations where you know that stack-depth is zero, and verify that the value of SP is still STACK_BASE. Hell, if I could, I would do such investigations by myself, but I am still only scratching at the surface of the VB code.
Before I rule out the stack as potential cause, I just want to be sure.
Cheers, and have a nice Sunday all of you!
PeerNo worries, thanx for you persistency – and your interest in Vectorblade in general.
Of course you are right – somewhere there must be a cause.
Two words on stack corruption:
- a stack bug is really a “simple” bug (a bitch – but simple in itself), I would highly expect it to be shown in an emulator – never once has there been a crash in an emulator
- there is no “long term” test per se. In my excel sheet I spoke of “reset stack pointer”, literally the first line in my main loop is:
main12:
lds #MY_STACK ; CBFC ; correct the stack to default address – so it is set completely anew!
The longest time, the stack is active, are the first couple of lines in my main program :-).
That being said – I totally agree with you, that the most probable cause for the crash is (generalization) a pointer going astray (at the moment “any” pointer comes to mind, not only the “S” register, but maybe “U”, “X” or “Y” – whatever register I take as a index based addressing).
This still constitue two problems:
- where
- what is the root cause?
Meaning, a pointer does not go astray all by itself.
My main problem indeed with the whole situation is, that it is (or seems to be) not replicable.
– I have no means to reproduce it reliably on the hardware
– I have not been able to even reproduce it ONCE in VideThe last point worries me most because it hints a possibility that it is NOT a coding bug, but some unkown “feature” of the vectrex.
I honestly am thinking about programming my bankswitching scheme into MAME/MESS to have a second emulator run Vectorblade. MAME/MESS has proven excellent emulation of VIA and 6809.
…
For know … I going hiking with my girlfriend… and try to clear my head a little bid.
Cheers
Chris
literally the first line in my main loop is:
main12:
lds #MY_STACK ; CBFC ; correct the stack to default address – so it is set completely anew!I think that is indeed a very good reason to rule out stack pointer corruption as a cause.
Will focus on other unlikely theories now 🙂
I also did some more stack tests.
In game (played about 25 levels with the emulator) the stack does not come “near” any the player shots.
(near being relative – it’s 4 bytes away, but that is 1/3rd of the comeplete stack 🙂 )Out of the game (achievments, shop etc) it goes 4-6 bytes “into” the player shot. But there never are player shots in this program part – and they get “reinititalized” befor the main game.
I did another “play through”, and had another crash, again in the first level (after roll over).
Suspicious:
That is the 3rd crash at exactly the same location (but it also often does NOT crash there).
The stack (after NMI investigation) pointed to $fc07 – which is utter nonsense, and since that is in the ROM area I could not even find the location, where the NMI took place.I again investigated all lists – this time the bonus list contained an “illegal” location, a bonus behaviour pointed to $c203, which I am quite confident … can lead to a crash.
I also observed during the game “interesting” things. The UFO (which can programmatically drop only “ranks”, dropped at one stage a “20” (money) – which points to a “corruption” as well.
I don’t know if I am getting paranoid – or if these “corruptions” were in there all the time and I did not notice them – or if I put them in there with my debugging codings.
I keep looking.
Next I am going to play a few “hours” emulator games only.
It would be an incredible coincidence if the emulator could also “detect” the crash situations – but hasn’t as yet.
But I’ll give it another (couple of) shot(s).Cheers
Chris
Very interesting, indeed. “Good luck” while hunting the bug! I have some more things to discuss. I will try to write you an email later this evening (right now I am occupied), so be prepared for being disturbed while playing 😉
One down – probably more to go!
I found one bug, that could corrupt the bonus list. This could and defenitly has caused crashes.
Thing is, this bug could only happen AFTER one roll over. Actually, after the “black hole”, the list was not re initialized – so bad pointers were present.
This was a good find – but could not possibly cause any crashes, that happened BEFORE level 100!
Exciting times!
Never distrust Vide!
I wrote a special function, to watch all RAM pointers. Stupid boring function:boolean checkRAMPointers() { int[] toCheck= { // enemy shots 0xc903+0*12, 0xc903+1*12, 0xc903+2*12, 0xc903+3*12, 0xc903+4*12, 0xc903+5*12, 0xc903+6*12, 0xc903+7*12, // BONUS 0xc963+8*0, 0xc963+8*1, 0xc963+8*2, 0xc963+8*3, 0xc963+8*4, 0xc963+8*5, // stars 0xc993+0*13, 0xc993+1*13, 0xc993+2*13, 0xc993+3*13, 0xc993+4*13, // enemies 0xc9d4+0*21, 0xc9d4+1*21, 0xc9d4+2*21, 0xc9d4+3*21, 0xc9d4+4*21, 0xc9d4+5*21, 0xc9d4+6*21, 0xc9d4+7*21, 0xc9d4+8*21, 0xc9d4+9*21, 0xc9d4+10*21, 0xc9d4+11*21, 0xc9d4+12*21, 0xc9d4+13*21, 0xc9d4+14*21, 0xc9d4+15*21, 0xc9d4+16*21, 0xc9d4+17*21, 0xc9d4+18*21, 0xc9d4+19*21, // player shots 0xcb78+0*10, 0xcb78+1*10, 0xcb78+2*10, 0xcb78+3*10, 0xcb78+4*10, 0xcb78+5*10, 0xcb78+6*10, 0xcb78+7*10, 0xcb78+8*10, 0xcb78+9*10, }; for (int i=0; i<toCheck.length; i++) { if (getPC() == 0x53a) // main loop start { int ram = e6809_readOnly8(toCheck[i])*256+e6809_readOnly8(toCheck[i]+1); if (ram < 0xc800) { breakpointExit=EMU_EXIT_BREAKPOINT_BREAK; CSAMainFrame frame = (CSAMainFrame) Configuration.getConfiguration().getMainFrame(); DissiPanel dissi = frame.checkDissi(); if (dissi != null) { dissi.printMessage("Vectorblade RAM corruption: "+String.format("$%04X", toCheck[i])+"->"+String.format("$%04X", ram), DissiPanel.MESSAGE_INFO ); } return true; } } } return false; }And played… and played… (in Vide).
In level 96, the “breakpoint” triggered!
There was a RAM Pointer corruption in the player shot object!
(PlayerShot 8 to be exact – nowhere near the stack)Silly me, I switch off “stepping” back, so I could not figure out what happened (inspite me having a save game only 10 seconds before the fault).
But this mean:
- there is another bug, that I CAN figure out using Vide! – if I am patient
- perhaps that is the final!
- I might add a new feature to Vide – to save states automatically every XX round…
- I defenitly will not switch off “take steps back” the next time.
CHEERS
Chris
- The forum ‘Vectorblade beta test’ is closed to new topics and replies.