Downloadable Vectorblade versions

[Peer]

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?

[Malban]

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.

[Peer]

Congratulations, 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”.

[Malban]

 

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

[Peer]

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, $DF

I 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,
Peer

[Malban]

Gee!

I think I made a big mess… I must investigate.

[Malban]

LOL

Thx for double checking. I made a big booboo. Off going to repair 🙂

[Peer]

Always at your service 🙂

[Malban]

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…)

 

[Peer]

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…

[Malban]

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 🙂

[Peer]

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?

[hcmffm]

Sounds like a good strategy. If there was a binary with a configuration for the random seed I could let it run on several Vectrex consoles. VB could perhaps even run in several instances of ParaJVE (blush – not using Vide, yet) – not sure how much CPU ressources emulation requires.

[Malban]

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….

 

 

 

[Peer]

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.

[Author]

Posts