Malban
Forum Replies Created
-
Posts
-
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”…
Just some info.
I let VB play with dunno 10 different seed, always well over 100 levels – to no avail.I tried playing manually – but honestly – today is not my play day. I did not manage to reach the first boss (usually I rollover more than once).
Thx for your offers! I consider them… but somehow I am not “content” with the current version yet.
But I seem I can’t concentrate on coding… (probably same concentration “genes” as with playing 🙂 ) – so nothing really “new” today.
But still – I could not let it rest… I’ve written down my current “knowledge”… some images….
No.
We have a deterministic VB, that crashed while playing manually.
Now I go on the hunt to find a random seed that crashes (preferable within the first 100 levels). If I find one, I will investigate further. For now I leave VB playing and hope.
If I don’t find a seed – I will rethink the strategy 🙂
Ok, just forget I ever sent the “changes done to sync” message.
I take it all back. I removed some Vide bugs and it works now.
http://vectrex.malban.de/tmp/DualPlayer.mp4
(it goes slightly out of sync after some time, the underlying sync mechanism is only milli seconds… to be more exact I’d need nano resolution…)
Somehow a Vectorblade “Care paket” found its way to me.
Thanks you very much! I am sure the bug will soon be found now (or so….)…
… and in the larger picture of things…
PS
@Peer, I will build a new Vide version – but I want to still test some things out…Cheers
Chris
My Vide version (in respect to instructions used in Vectorblade) emulates 100% cycle exact.
Now.
All timers are 100% (well… sort of – see below) correct all the time. Each instruction now seems the exact same as on my vectrex (vectri – I tried 3 different ones).
Changes done:
Changes done in Vide for 100% cycle exact execution of VB
– T1 timer one shot, was not “reset” with latch values after reaching 0, including one cycle “duration” of reset
– reloaded value is shown “false” in vecxi since it shows “value+” the real VIA shows hi ff, lo 0 and than the “real” value appears next round – >there is a delay of one cycle!
– t2 needs one cycle to START the actual timer, befor it counts down
– values read with “lda” kind of instructions are read AFTER all instruction cycles are processed (however strange that may be)
– 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, $DF
– STB direct, value is written after 3 of 4 cycles (STA after 4 !?!?!?)Falsly shown in Vide:
– State of CB1 (also interrupt flag CB1), vectrex has NO CB1
– half carry is “uncertain” emulated
– as mentioned above, the “intermediate” timer reset value $ff00 is shown as (resetValue+1)
With above changes… Vectorblade demo runs exactly the same!
Not that I am closer to finding the crash – but this is at least a semi “success” – making Vide better 🙂
As to your last questions:
- the “non debug” stack starts at $cbfc, and thus overwriting all vectors
(defined in commonGround.i – quite at the top)
Depending on the debug mode the stack starts at a different location (SWI and NMI need their interrupt vector in place)
(The crash can happen regardless, if the stack starts lower than $cbfc – than I have to “free” more space!
Most easily been done by allowing e.g. only 9 shots for the enemies, instead of 10)
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. - I also use memory locations $cbfc, $cbfd, $cbfd and $cbff (see RAM static file)
- 0 RAM free means, I have NOT A SINGLE BYTE of RAM which is not used in game.
The stack is exactly as long as needs be – I do not call many subroutines. I measured it some time ago.
I do not have records of that – and that was measured manually. So there IS a certain risk here.
Proof is a hard word – no, I have no PROOF. Other than I measured it.
Dynamic lists.
These are not “dynamic” growth lists, only “dynamic” occupied.
The include “RAMInGame” – defines how large each list can at maximum be. If the maximum is reached, the allocation routine returns null, and thus informing the caller, that there is no more space left.
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.
🙂
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
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…
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…
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
- the “non debug” stack starts at $cbfc, and thus overwriting all vectors
