Peer
Forum Replies Created
-
Posts
-
Although we are considering a faulty RAM cell as an unlikely cause for the VB crash, let us just try to rule it out.
I have re-implemented my RAM checker. See here:
Anyone of you who finds the time, please try it on as many real (physical) consoles as you can, and please let me know your results. Also a short “no errors on my console” is valuable information. Only if we have some numbers of how many tests were performed on how many console, the reliability of the checker can be assessed.
I am still looking for a real console with faulty RAM. I do hope that all your consoles are ok, but having such a test sample would of course be good. A student of mine, who is from Electrical Engineering and who also owns two consoles, will inject some physical RAM errors in his console over the weekend and thus do some more meaningful tests.
Sidenote: Emulated faults can also by injected on the fly in Vide.
Cheers,
PeerNo, it only once more shows your dedication and enthusiasm for this project.
Personally, I think your idea of adding a watch-dog to Vide was brilliant! I could bang my head against a wall for not having thought of such a thing myself. In my mind, Vide is static, and I only went in the direction of what could be done on the VB code side. Even if the watch-dog approach did not reveal anything new in this example, it might still come in very handy in some next attempts.
And posting about the things you do keeps us informed and is always inspirational. Please continue to do so, even if things turn out to be a dead end. Every tiny bit helps completing the picture and might lead to new ideas.
Cheers,
PeerVery 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 😉
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 🙂
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!
PeerAnd 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…
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?
One remark in respect of lines 37-39:
If the stack goes too deep due to some call of a routine f(), and thus overwrites (corrupts) heap data D, the crash must not neccessarily occur during f(), but only when the corrupted data D is used the next time. This can be much later, and in a different piece of code.
Create a binary where the seed can be initially configured by hand. Send it to us testers, and we all can (agree upon and) try different seeds and let our consoles run. What about such kind of parallelization?
Also, I have reactivated my RAM checker which tries to detect write-read mismatches for the RAM cells. That could be tried on the “crash”-consoles. Probably to no avail, but wouldn’t hurt. Just let it run?
So, to summarize, am I correct in that as of now we have a “deterministic” VB demo version, that already has crashed on a real console, and you have now a fixed and “synced” Vide, but the VB demo has not yet crashed in the emulator?
Sorry, my head is spinning with so many things and my memory is blurring…
I am slightly confused. Maybe I am missing something here:
certain instruction of the 6809 are seemingly 1 cycle faster than any documentation, I have not “tried” every single instruction variant, I was content to find all, that matter for VB to run cycle exact:
$EC, $ED, $FC, $FD, $EF, $AF, $FF, $D0, $BF, $9F, $DFI checked in some books I have. $FD is “std” with extended addressing, and the cycle count is 6, according to my books. Also a quick internet search says 6 cycles. Are you saying that it takes 5 cycles?
I modified my C test program and added a simple std dummy write between the two readings of t2:
t2_0.w = VIA_t2; asm volatile ( "std %[DUMMY]\n\t" :: [DUMMY] "m" (xdummy) : "memory"); t2_1.w = VIA_t2;The annotated asm, generated by gcc6809, lists 6 cycles for the std.
All ParaJVE, DrSnuggles, my_console_a and my_console_b now output 00018, which is exactly 6 more than the previous 00012.
My Vide outputs 00020, which is 7 more than the previous 00013.
So, my Vide version thinks that the std takes 7 cycles, while the reality seems to be 6 cycles. Which is what I found in the documentation.
Do you have any documentation that says 7 cycles, or did your experiments show 5 cycles?
The “one cycle faster than any documentation” is confusing me here.
I will build a new Vide version – but I want to still test some things out…
No hurry, take your time.
Cheers,
PeerCongratulations, great work! And thanks for all the explanations. Now I see a bit clearer. In some spots, at least.
Any chance to get your current Vide version? Just to avoid that I am chasing down dead alleys. I am using the latest official 2.51, but at some point in the past (close to January 28th, 2020) you sent me a patched Vide.jar that contains some fixes. I forgot which. So my version is “somewhere inbetween”.
