[Peer]

… you loose your settings after the Minestorm sequence.

<nagging>

Now I might sound like the old Cato in the senate of ancient Rome:

“Ceterum censeo struem esse investigandam!”

😉

A ram setting getting lost (or overwritten/corrupted?) after Minestorm?

“I once more insist that the stack must be investigated!”

And maybe also the Rot_VL_Mode target buffer…

</nagging>

[Peer]

PEER!

This was a stack bug. The bug which occurred in BOSS 2!
Last version you asked for a version where the stack was 2 shortened. I forgot to UNSHORTEN the stack.

Ready to take the blame. I am just a no-good-for-nothing scientist 🙂

So at least now we know what can happen :-).

Thanks for unintentionally doing this experiment for me. That was exactly what I wanted to take a look at. But it “seems” to me, that THE BUG at least manifests in a different way? Jeez, a stack issue would be such a nice explanation…

Still, the contra-position evidence would be to have a 2+ larger stack with THE BUG not occurring. If only that damn thing would be reproducible…

[Peer]

That’s nice…
Vectorblade is crooked. I’ll throw it in the bin and never look at it again.

Now I am beating you with your own weapons:

You can’t throw it away. Why? Well, let me cite from the diary of a certain V. Tiberius Rex…

Bugs are invading our system! Wave after wave they are coming.
My training is not complete yet – but it must suffice. The Vectorblade can fly, and basic weaponry is installed.
Better fight with a “sting” than not to fight at all. Rumors have it, the bugs are stealing our technology – don’t know what they want to do with it – can they read? Can they in any way make use of the stuff they rob? Never seen a bug using mechanical/electronical implements of any kind. I hate them!

You conjured them up. Now fight them! Just like Tiberius Rex would!

🙂

[Peer]

@Peer: I checked those RAM locations, and they get repopulated correctly after a minestorm.

Did you also check the “maximum stack requirement: 9 bytes” of Rot_VL_Mode?

Cheers,
Peer

[Peer]

Some more digging. I just read a bit in RAMLayoutStatic.asm, and now I am collecting my thougts here.

Rot_VL_Mode internally uses 0xc834 – 0xc83b, and probably also 0xc83c. As far as I can see, in VB those are mapped as follows:

	org      _Vec_Str_Ptr                 ; Vec_Counters ; $c82e 17 byte 
c82c	levelTimer          ds       2                            ; 
		tmp_div1 
c82e	bonusSpawnPosition  ds       2 
		; following 5 definitions are the jmp (on stack) addresses back to the main game loop
		; from the 5 different linked lists
		; these can be set in RAM, since lists can be reused in different game sections
c830	STARS_DONE_A        ds       2                            ; 
c832	ENEMY_DONE_A        ds       2                            ; 
c834	SHOTS_DONE_A        ds       2                            ; 
c836	BONUS_DONE_A        ds       2                            ; 
c838	PLAYERSHOTS_DONE_A  ds       2                            ; #handle_after 
		STARS_DONE          =        STARS_DONE_A-2 
		ENEMY_DONE          =        ENEMY_DONE_A-2 
		SHOTS_DONE          =        SHOTS_DONE_A-2 
		PLAYERSHOTS_DONE    =        PLAYERSHOTS_DONE_A-2 
		BONUS_DONE          =        BONUS_DONE_A-2 
		; reuse!
		FW_PARTICLES_DONE   =        ENEMY_DONE 
		FW_PARTICLES_DONE_A  =       ENEMY_DONE_A 
c83a	OBJECT_LIST_COMPARE_ADDRESS  ds  0                        ; compare value to above 5 addresses - these must be greater than above addreses, 
																  ; compare is used to decide whether list is empty or not 
c83a	warpSpeed           ds       0 
c83a	bonusAnimCount      ds       0 
c83a	lightningOn         ds       1                            ; BIT FLAG when an enemy is hit by bullet - but not destroyed - the enemy "flashes", this indicates a current flash (reset by next normal colored enemy) 
c83b	shotYRadius         ds       1                            ; is allways negated value -> easier/faster compare! 
c83c	levelEnemyCountUID  ds       1                            ; during level intro - each "permanent" enemy receives a UID, this is the counter for that 
c83d	_Vec_Rfrsh          ds       2                            ; $C83d / $C83e when using Wait Recal -> than this is 

I failed to check this myself, but could it be that during the dodger sequence (MineStorm) one or some of the values are destroyed by Rot_VL_Mode, and afterwards the values are not properly reinitialized or restored before being used the next time?

Cheers,
Peer

[Peer]

@Jerome and @GeoAnas: Thanks for your input and the messages you sent me.

One possible explanation for these crashes could be reversed roles of bad guy and victim here: Maybe it is not the stack corrupting some ram data, but some ram data (namely the shot data) corrupting the stack, and thus the program counter?

@Malban: Chris, just for info, I am too dumb to get the VB 47 binary to run in Vide…

[Peer]

@GeoAnas: Great, thanks! With flashy graphics appearing it is definitely not an endless wait-for-timer2-loop. A loop yes, but we can rule of the timer-2 thing. Which is at least one more insight.

[Peer]

A black screen with a continuous sound (same frequency, no modulation) could be a hint so an unintended endless loop (no update of the sound routine, no screen update). If, for example, the sync-to-50Hz-mechnism (waiting for timer-2 to expire) for some reason would not receive the information that the timer-2 counter has counted down to zero, then such a thing would happen. I was chasing down this road, but I just cannot see how this specific timer-2 scenario could ever be possible due to some VB software bug???

@GeoAnas: Just for the sake of completeness, how long has your console been up until the crash? Another very unlikely theory is some thermal effect in a VIA latch, causing the latch not to update anymore. But having experienced crashes on four different console makes such a hardware-issue even more unlikely than very unlikely…

[Peer]

What I would like to know:

How exactly does the crash manifest? Sudden blank screen? Weird drawings and flashes? Sound garbled, or cut off?

Also, how long has your console been operating until the crash occurred? Not how far you got into the game, but how long since you switched the console on and started playing the first game? Switching off between games just for a few seconds doesn’t count.

Sorry can’t explain, no time right now.

@GeoAnas: Great to see you again! Sorry for the long silence. Played around with the great C64 stuff you sent me, but never got around to dig deeper into it so far, unfortunately. Always life, the universe and everything interfering…

Cheers to you all,
Peer

[Peer]

Interesting, thanks for the explanation. I did not find the reason why this is done, but I could imagine that on transistor level something like (adr ^= adr) is done (xor-selfie) in order to save some transistors on the circuit.

[Peer]

I kept reading yesterday evening and tried to refresh my knowledge about 6809 asm. The following is most likely not related at all to our current crash, but anyway:

I learned that the CLR instruction in combination with extended addressing, does in fact also read the addressed memory location. I do not know whether the read occurs before the zeroing or afterwards, but I found it explicitly mentioned that this could potentially cause trouble when used on memory-mapped IO-ports.

I could not come up with any hypothetical VB or general Vectrex situation where this would be hazardous, and I am sure that you (Chris) already know this detail about CLR, but I just wanted to mention it anyway, so that you can confirm that this is irrelevant in our context.

Cheers,
Peer

[Peer]

Weird question: What would happen if a stack-underflow occured in VB? That is, a pop from an empty stack. Or in other words, a pull instruction is executed when the stack is at stack_base. Is there any important data at stack_base+1?

[Peer]

…thanks Peer for supporting Chris with help and ideas…

Just trying to cover up the fact that I am lousy player and beta tester 😉 I still suck at playing the game and hardly ever find the time for long-run attempts.

i tried the RAM checker : no problem for me; same result with the “endless” version. All worked well.

Thanks a lot, Jerome! Once my student confirms that the same checker binary correctly detects his faulty RAM hardware, we can definitly put that theory to rest.

May be we can imagine something to “connect” VB to the future Major Havoc game: for instance a “secret tip” (to find on VB) opening hidden levels on Major Havoc.

Nice idea, Jerome 🙂

[Peer]

Thanks! So, faulty RAM ruled out, and my mind is at rest. Almost. @Jerome: please try the RAM checker on your crash-console.

Vide single jar is perfectly fine. And no rush here.

Cheers,
Peer

[Peer]

… going to voting mode:

Major Havoc? This is a hard choice, but my favorite choice is “no, go for the changing fighter appearance”. That would indeed be cool. Do Major Havoc as a stand-alone game later 🙂

… going to query mode:

Can you also create VB version, where STACK_BASE is (OLD_BASE – 1)? Or even (OLD_BASE – 2)? That is, a version that is deliberately prone to cause a stack issue. Would be interesting to know if that would result in a crash, or just in some minor faulty behavior (wrong score, wrong bonus drop, and the like).

… going to greedy mode:

Is it possible to get an updated Vide version with your latest fixes before you leave? Especially the “12 cycles / 13 cycles” fix, see previous discussions.

… going to unlikely pestering mode:

Try the RAM checker!

😉

… going to cheery mode:

Many Cheers,
Peer

[Author]

Posts