- This topic has 522 replies, 8 voices, and was last updated 3 years, 4 months ago by
.
-
Posts
-
Ok.
Cosmic rays asside. This is like a “Matryoshka doll” – always something else tinier inside.
… and I don’t really think it will lead to the crash bug.But anyways, perhaps to a better emulator.
Newest “doll”…adjustStars()
Hehe – Peer you were right in pointing out “dynamic” changes :-)…
The adjustStars() function removes or adds stars in relation to the amount of free time in one vectrex-round.At the moment in “in level 4, after the 8th dropped bonus, after 49 additional rounds… ” – the vectrex emulator has 5 (*256 cycles) left and the real vectrex has 8 (*256) cycles left.
This causes the emulator to “remove” one star – while the vectrex keeps all stars – and thus during the next “position” generation of out of bounds stars, calls additional RANDOMs.
So …
The next question is WHY are the emulator and vectrex 768 cycles apart?
The easiest answer would be: “Because the emulator does its cycle counting wrong”.
I have to check that (again) – but during writing the thing I checked that OFTEN.
And the same cycle information is displayed in dissi – and that is “usually” right.I will do that next – but I kind of don’t believe in it.
The speed of the VIA and the speed of the 6809 are fed by the same Quartz, so the behaviour between those two should be completely in sync…
I’ll be back…
Chris
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!
😉
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?
I just discovered a new hobby I didn’t know I wanted…
Checking 6809 opcodes for correct cycle count values in the offical specs.
So far I found 4 opcodes with different cycle counts on at least one of my vectrex.
This will keep me busy for some time…
Right now I am checking only one of my vectrex.
My emulator (I checked) had all “official” timings.
The Vectrex 6809 differs from official timings – that’s why the emulator and the vectrex go out of sync…
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…
At the moment it seems like I found:
variants of: LDD/STD/STU
Exactly the codes:
$ec, $ed, $fc, $fd, $ef, $af, $ffThey seem one cycle faster than what the manual says. But I am not finished yet.
No as of now, I have no simple code check, I measure it with the current interrupt handler I use.
Basically:
- start timer T2
- do instruction
- read timer T2
- output T2
- If vectrex.T2<emulator.T2
than cycle difference
The cycle difference for these instructions is “1” cycle. And it is linear cumulative, meaning, one such instruction takes 1 cycle longer, 10 such instructions take 10 cycles longer.
As of now, I do not systematically test. I time a “round” of vectorblade… I place my swi somewhere and check for T2.
If there is a difference to the emulator I “close in”.
This is very tedious… but I guess so would be a systematic test. I don’t know how many instruction variations there are, but I wouldn’t be surprised if there were quite a few hundred (with all the different adressings).Chris
… 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?
No – it certainly doesn’t – since the “ldd” of the timer, also takes time.
But nonetheless it is the DIFFERENCE in the result that I am looking at.
And exactly the same sequence of instructions should end up in exactly the same timing – since the clock timing of both the 6809 and VIA have the same source. This is a purely “digital” part of the vectrex. No analog differences anywhere in sight.
I might quote a fellow vectrexian…
I firmly believe that program execution is deterministic.
🙂
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
- The forum ‘Vectorblade beta test’ is closed to new topics and replies.