Peer
Forum Replies Created
-
Posts
-
Depending on the game situations I use different RAM layouts. There is one layout, I call “static” ram layout – that (more or less) never changes. This is approximately from c800 to dunno lets say c950.
… at the moment (I) have exactly 0 bytes RAM free.
Does your stack pointer start at 0xCBEA? And what is the exact meaning of “exactly 0 bytes RAM free”? Do you have a proven situation of nested souroutine calls in which the current stack pointer points exactly to the top address of the ram variables that are in active usage in the current ram layout (thus 0 bytes left)? How can you be sure that the stack never ever overruns the heap? Not teasing, just trying to understand your reasoning about this.
Do you also use Vec_High_Score and Vec_Cold_Flag for your own purposes?
Did a quick test:
union word { struct { unsigned int h; unsigned int l; }; long unsigned int w; }; union word t2_0, t2_1, t2; int main(void) { t2_0.w = VIA_t2; t2_1.w = VIA_t2; unsigned int temp; temp = t2_0.h; t2_0.h = t2_0.l; t2_0.l = temp; temp = t2_1.h; t2_1.h = t2_1.l; t2_1.l = temp; t2.w = t2_0.w - t2_1.w; while(1) { Wait_Recal(); Intensity_7F(); print_long_unsigned_int(0, 0, t2.w); } }Vide: 00013, ParaJVE: 00012, DrSnuggles: 00012, my console A: 00012, my console B: 00012
… does reading timer T2 after the instruction give exactly the value the timer has the moment the instruction has finished? Or could it already have moved on “a tiny bit” while the read T2 is executed? Heisenbergs uncertainty principle? The closer you try to look the fuzzier the results?
Can you give an example of such instruction(s)? Do you have a simple binary to check this (the number of cycles for such instructions) on a real console? At some point in the past I asked if there are different versions of the 6809 around, but I forgot the answer. Would be good to definitly rule out different processor versions as the root of all evil. We could also open the consoles and take out the cpus or take pictures of them, and then compare the version numbers or imprints. Again, just trying to meticously check in every direction…
Headache. I have thought this over and over. And I have revisited our recent theories. I firmly believe that program execution is deterministic. We do not further consider faulty hardware theories. If I had to place a bet right now, I would put my money on uninitialized ram. I know, you do initialize your ram. Still, could generate a new Vide version that pre-sets all “uninitialized” ram cells to zero? Then do a time-warp run of the non-random-demo VB. It should behave 1000% exactly like the current Vide, where “uninitialized” ram is pre-set to the address low-byte. Does it?
Thanks for the code!
I don’t expect you to actually dig your way thru the source code.
And I don’t expect to understand anything of it. But then again, challenge accepted!
Maybe I get the meaning of some pieces. And maybe this leads somewhere. It’s again a shot in the dark, but if that’s the only thing I can do, I’ll happily try.
The source is not in a really good state either, since months of heavy debugging, did not really beautify it!
Don’t worry. I teach programming classes, I am used to horrible code 🙂
Only intermediate programmers write beautiful code. Beginners and experts write ugly code, and you are certainly no beginner!
Overnight a Neutrino hit my Vectrex.
Not neutrinos, alpha-particles. Did you launch your console to space? Or are you working from Orbit-Office?
Jokes aside, here comes “unlikely squared”: Is there possibly some device located close to your consoles that emits some sort of radiation? A microwave oven? Or some neodym magnets? On old CRT-TV? An MRT? A proton accellerator?
Not sounding all negative :-)…
Ha, so at least all the nonsense I wrote was good for something! 🙂
Hehe – Peer you were right in pointing out “dynamic” changes :-)…
Me opening a bottle of champagne right now… oh, wait, I don’t drink alcohol, let us save it for later.
The next question is WHY are the emulator and vectrex 768 cycles apart?
Now, that you mention it: at some points in the past, when working on my own projects, I sometimes had the feeling that the real console is “a bit more generous” than Vide, when it comes to reaching the 50 Hz barrier. I had some code, and Tracky showed me that I was slightly exceeding 30000 cycles, but on the real console everything still looked completely fine without any noticable wobble. I have to admit, I never cared then, and never asked you about that. I will see if I can dig out some old code.
I’ll be back…
Hasta la vista, baby!
😉
… after the 8th dropped bonus … in the star behaviour.
Do I remember correctly that the number of stars is adapted (reduced) according to how many other objects (bonusses?) are active, in order to remain within the 50 Hz framerate? Could there be some overflow/underflow/off-by-one in the star-data management? Is this again a dynamically linked list? In which part of the ram is the star data located? What data comes in front, what data comes after?
Please select: <Like> <Unlike>
The complete game runs in DP = d0. This never changes! – I never have to worry!
I guessed so. But I still asked, because you told us to question everything. Especially those things you are 100% sure of to be correct 😉
… in Vide Fastboot
I know that I can be a pain in the back, but I am used to checking meticulously in each and every direction. Can you just once set Vide to one of the non-fastboot roms and confirm that the difference is still there?
… no ROM at all
And again I am playing advocatus diaboli: Objection, your Honor! You are using the system’s power-up handler at F000, which is a rom routine. No, I am neither mocking nor teasing. Again just checking meticulously in every direction. The power-up and system initialization routines vary between the different rom versions. I had a look at those routines and tried to understand them. There are differences between 7931 and B796, but nothing looks suspicious in respect of VB. I did not (yet?) check those routines in the fastboot rom.
Here comes another question: You said you are using the complete ram. Can you still give me some details? What is the first ram address, and what is the last ram address you are using? What are the ram cells specifically used for? I am kind of dancing in the dark here as I do not have any code snippets in front of me.
It first happens: in level 4, after the 8th dropped bonus, after 27 additional rounds… in the star behaviour.
Great, that is at least a trace to follow! Good thing that it is level 4, and not 400 😉 What about a complete ram dump after (for i = 27; i >=0; –i) rounds, to find the first frame where the rams differ? Yeah, laborious, but …
Many Cheers,
Peer… another, though highestly unlikely, yet still possible cause for ram corruption:
use direct addressing instead of extended addressing, when DP is known
Wrong DP value, e.g. writing to VIA under the assumption that DP is D0, while in fact DP is C8.
Or the other way around. Accidently writing to VIA while accessing ram under the assumption that DP is C8, when it is in fact D0?
Could there be even the tiniest chance, that such a situation is possibly hiding somewhere?
– When running VB in Vide, which ROM version do you use? Fastboot? 7adb? 7931? B796? All of them?
– Which ROM version(s) have the consoles that showed the crash / difference in demo mode?
I know that you do not use any ROM routines. Still I would be interested in this. I just do not want to rule out any possible explanation for the observed difference too early.
And for the sake of completeness, do you use any ROM data? E.g. vector-lists from Minestorm? Sine/cosine tables? Frequency tables? Startup tunes? ADSR data?
I am back now, and I have had some time to think inbetween. What about the following approach (loosely related to my previous posts):
a) Count the calls/invocations of your pseudo random number generator (rng), so that you have a way to determine the n-th random number. This will require additional debug code and some ram cells for storing n, so the whole attempt might be prone to cause Heisenbug effects.
b) For some very large m, stop the game execution and display the m-th generated random number. If (the Vide-number differs from the console-number) or (the display looks different), repeat the whole process with a smaller m and try to find the minimum m for which you get either type of difference.
c) Once you have such a minimum m, good!
d) If for this m, the m-th Vide random number differs from the m-th console random number, then there must be some reason why the rng suddenly behaves differently. Check the cone of influence of the rng logic.
e) If for this m, the m-th Vide random number is equal to the m-th console random number, but the display is different, then “the point” must be somewhere before the m-th call of the rng. Check the call trace. Which part of the code is calling the rng?
In essence, use the sequence of calls of the rng as a marker to narrow down “the point” where suddently Vide and the console behave differently.
Unlikely Cheers,
PeerIsolate the code for the random number generator, and check if the generated sequence is the same in Vide as it is on the real machine. Yes, yes, I know, (++(highly unlikely))++, but I think it would still be worth to check. Especially at or after the “wrap around”, if your are using an LFSR. Just check the number after the 100.000 th iteration, or so.
