Downloadable Vectorblade versions

[Peer]

No, it only once more shows your dedication and enthusiasm for this project.

Personally, I think your idea of adding a watch-dog to Vide was brilliant! I could bang my head against a wall for not having thought of such a thing myself. In my mind, Vide is static, and I only went in the direction of what could be done on the VB code side. Even if the watch-dog approach did not reveal anything new in this example, it might still come in very handy in some next attempts.

And posting about the things you do keeps us informed and is always inspirational. Please continue to do so, even if things turn out to be a dead end. Every tiny bit helps completing the picture and might lead to new ideas.

Cheers,
Peer

[Peer]

Although we are considering a faulty RAM cell as an unlikely cause for the VB crash, let us just try to rule it out.

I have re-implemented my RAM checker. See here:

http://eitidaten.fh-pforzheim.de/daten/mitarbeiter/johannsen/vectrex_lab/projects/ram_checker/ram_checker.htm

Anyone of you who finds the time, please try it on as many real (physical) consoles as you can, and please let me know your results. Also a short “no errors on my console” is valuable information. Only if we have some numbers of how many tests were performed on how many console, the reliability of the checker can be assessed.

I am still looking for a real console with faulty RAM. I do hope that all your consoles are ok, but having such a test sample would of course be good. A student of mine, who is from Electrical Engineering and who also owns two consoles, will inject some physical RAM errors in his console over the weekend and thus do some more meaningful tests.

Sidenote: Emulated faults can also by injected on the fly in Vide.

Cheers,
Peer

[Malban]

Hi,

after my latest “negative” finds – I did lots and lots of testing (including the watchdog in Vide).

Real console proof of much testing: see image

As much as I like Vectorblade – there comes a stage where you get sick of playing hours on end.

I also played in parallel (ok, ok sequentially) in Vide.

No crash. In either the real and emulated game.

While theoretically it is wonderful to have no crash – the already found bugs can not explain all “old reported” crashes, so I must assume some bug still resides, but does not show itself at the moment.

 

From Saturday onward, I will be out of town for 8 days, so I will not be doing ANY Vectorblade during that time. Actually that “natural” pause is quite welcome at the moment.

I surely intend to keep on bug hunting afterwards – but to keep my sanity I also want to do some more “visible” things.

1. finish the instruction booklet
2. order packing material
3. order the instruction booklet
4. make changes to the game to “fit” the overlay better

also…

 

Major Havoc
While the “additional” extra game has (IMHO) a very cool and unique engine (soft scrolling with “soft” clipping, (animated) tile based levels, collectibles and extra “moveable” adversaries etc… ) – I still suffer from the same syndrome the engine started with:
a) do not really know what to do with it
b) I just can’t bring myself to further work on it (just now)

Sooo…
I put this to the vote with you guys:
– do you want me to continue on this path? Than I will force myself to do something with it… and being forced I am sure I will come up with something nice

– or not.
(short message yes/no is sufficient – but you are allowed to elaborate)

If the vote is “No” – I will have a couple of kB free space – which I would probably fill with some other additional stuff.

At the moment I am toying with the idea to change the fighter appearance with the amount of installed enhancements.
That would cost lots of space – but IMHO it would be cool if the fighter reflected e.g. the kind/number of shots you have available.

Or… a special “reward” for an achievement could be an new fighter “skin” (just another appearance).

---

Before my “holiday” I will built another beta binary… that you can test if you find the time.
I will build a non debug binary, as in no NMI “controller”, no test mode. All levels, all “normal” game features, since that is the way the game should “work” as.

As an additional safety measure I will try to free “two bytes” in RAM for the stack (@Peer: just to be on the save side).
In my current debug setting I have more stack, and at least up till now – no more crash.
So perhaps there IS some weird place the stack goes nuts. … well … just to be save.

And I know there are some bytes, that only use a couple of bits – I just have to join these…

Sooo…

This is my current “stand”.

Regards

Chris

 

[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

[Malban]

RAM Checker:

Tried on  4 consoles -> no error

RAM Checker “endless” tried for a minute of so on same above four consoles -> no error

 

Vide
I can do a “single” jar for you, no full release though

 

Stack.

Can do…

 

Either today or tomorror – as time permits…

 

Chris

 

[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

[vtk]

hey guys sorry about being quiet and to see the ongoing struggle with the mysterious bug  🙁   thanks Peer for supporting Chris with help and ideas   (as you can imagine for many of us here, we just dont know what advice to give for such a difficult hidden ‘bug’)   (assuming it’s a bug and not just the analog vectrex being to cope with malban’s super fast radical coding) .. the reason i say that is, why doesnt the bug surface in the emulation?  🙂

with the major havoc part, my vote is that it is no big deal to drop it from the game, and as Peer said,  maybe u could do something with it in the future on another project

stay safe

[Jerome Vince]

Hi Guys!

@Peer, @Chris: i tried the RAM checker : no problem for me; same result with the “endless” version. All worked well 👍🏻

About Vectorblade: i would follow Peer in his suggestions to work on the fighter appearance, and all the things you want to improve before the release of the game.

So as Peer and Vtk said,  i think it is a better idea to offer a specific Major Havoc project later (but not too much! 😉).

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.

Cheers,

Jerome

[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]

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?

[Malban]

Default stack address is (usually) $CBFC.

“Reading” from there doesn’t destroy anything, writing again after reading – would.
not used yet: $cbfc
chosenStartLevel = $cbfd
isDemoMode = $cbfe
realEnemyCount = $cbff

After that it gets dangerous, because the addressing logic for RAM “rolls over” -> YM buffer is “next”.

Enemy count would be “strange”, probably a level could not be finished. usually the level is finished, when enemyCount is zero…

 

[hcmffm]

Major Havoc is a simple answer for me:

In terms of gameplay, Vectorblade is the most complex game I know on the Vectrex. And Vectorblade will still be the most complex gameplay without Major Havoc. So I think you (Chris) should forget about Major Havoc and make a seperate game out of it.

If you still have ressources and energy, you could give all testers an indication and let them make suggestions. ATM, I don’t have a suggestion for Vectorblade on my mind, but I’m pretty sure that if I looked at the game today, I would find things that could be improved.

Linking the two games (VB and Major Havoc) in some way is a good idea,  e.g. VB could have an end sequence with the pilot getting of the space craft and climbing into a shaft. The end sequence could be the start sequence of Major Havoc. Or menu system could be similar. Or…

Just my 2 cents… Good luck in finding the bug(s) and I wish you (Chris) good and joyful VB free days!

[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

[Malban]

Yes, I know about that one. Vide also emulates it.

Can’t IMHO cause crashes – but it can leave unwanted “artefacts” on screen.

e.g.

Fill Shift register (for pattern drawing) with something like: %10101010 (a dashed line).

Draw the line (the last zero enables blanking) and move to a new location.

If at the new location you would start with a “CLR SHIFT_REG”, than
you would see an “unwanted” dot – since the shiftregister starts shifting with the “read” of the clear instruction (and thus outputting the first “1” before zeroing the shift reg).

The read happens before the CLR.

(happened to me in the past 🙂 )

Cheers

Chris

PS

Emulation code:

        case 0x0f:
            ea = ea_direct ();
            vecx.vectrexNonCPUStep(PRE_CLR_STEPS);
            inst_clr ();
            read8(ea); // clear reads! important for shift reg emulation! e.g.
            vecx.vectrexNonCPUStep(POST_CLR_ADDSTEPS);
            write8 (ea, 0);
            cycles.intValue += 6;
            break;

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

[Author]

Posts