[Malban]

Something amazing happened!

Overnight a Neutrino hit my Vectrex. Now the “changed” behaviour happens 22 rounds later, and not in the StarBehaviour anymore … seemingly in the “doIntro” sequence of the enemies.

I must close down fast now, before the next Neutrino comes along!

[Malban]

Today I will close in further on the exact location.

The whole “BIOS” thing, I find very unlikely (again). Since all things I use, I really init myself. Even the random seed I do myself, since I have an own random function. As it is, the only thing I “rely” on from the BIOS, is that it sets up VIA correctly upon start. And it obviously does that. Everything else I am doing myself.
“certainly” nothing that will appear first in level 4 :-).

Well… I’ll get back to that, once every other “more likely” option runs out.

RAM

Not an easy to answer question.
I can gladly send you the sources – but without a short introduction to VB (a couple of days might suffice) you will be quite lost I guess.
There is no “one” RAM layout.

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.

YES, I use BIOS locations too. There are only a small handfull of singular BIOS RAM locations I leave “unused” by myself.
(Refresh rate of WaitRecal, TextSize, PSG Buffer (which I also use) …).

But even in the “static” RAM, I double/tripple use some locations.
It is messy – but we only have 1024 bytes of ram!

Than there are a RAM layouts I use:

• in game
• in title
• during boss fights
• in minestorm
• during major havoc

These all “overlap” each other – and they are mutual exclusive.

I just copied the current sources to my FTP server, feel free to browse.
(ZIP file has it all)

vectrex.malban.de/tmp/src_vb46
If you want to actually run the game – be aware of some “SWI” I placed in the code for debugging
(SWI use the same vector as NMI, and I could place them liberally 🙂 ).

Easiest would be to load the project in Vide.
The 4 “main” files – well, are the main files (one main for each bank – start bank is 3!).

But the “real” starting point would be: http://vectrex.malban.de/tmp/src_vb46/commonGround.i,
which loads: http://vectrex.malban.de/tmp/src_vb46/inBothBanks1.i (from the time I only used 2 banks)
which loads all ram setups, e.g.: http://vectrex.malban.de/tmp/src_vb46/RAMLayoutStatic.asm

The “heads” of the linked lists are in the static RAM layout, the actual list data (since used in game) are defined in:
http://vectrex.malban.de/tmp/src_vb46/RAMLayoutInGame.asm

---

Yes, stars still “adapt”, but at least one set of stars must be present. All “linked” lists are handled identically (although in different functions, see the different “objectXXX” files.

Malban

PS

I don’t expect you to actually dig your way thru the source code.
I programmed it, did quite a lot of documentation – still, working 2 years with the code – and even I do not manage to follow everything. The most used function is “SEARCH”…
I am just showing off convoluted vectrex source code 🙂

PPS

The source is not in a really good state either, since months of heavy debugging, did not really beautify it!

[Malban]

From back to front…

c) The complete game runs in DP = d0. This never changes! – I never have to worry!

b) different roms (2 test Vectrex) –  dunno by heart the crc, the oldest and second oldest, but not the noBuzz, in Vide Fastboot, no no ROM at all (apart from Vectorlists for Minestorm) – but the crash never happened during a minestorm 🙂
startup tune is “music1” from the BIOS 🙂

a) it is not the RNG, the RNG is called more often on the vectrex than on the emulator. I am still figuring out why though.
It first happens:
in level 4, after the 8th dropped bonus, after 27 additional rounds… in the star behaviour.

This I figured out by many MANY manual tests using my vectrex. I still have to close in further, but I am getting kind of tired tonight…

[Malban]

In level 4 are the first “visual” differences:

Still the same

 

1/2 second later
(on the real vectrex, the ship starts to move right!)

 

Ehm.

Now what – how do I find the “code”/”bin” difference?
Have to think more 🙂

[Malban]

Yeah, this bug hunting is a marathon.

I just aquired a new intermediate target… I took out the “random” in Vectorblade – and I am working with a fixed seed.
So theoretically the emulator and the Vectrex should behave the same.

I let VB (demo mode) run for some time… checked after level 3 – and everything was fine (equal).

I checked after level 60 again (I have to work in between) – and its different.

So somewhere the emulator does NOT (!) behave like the real vectrex. Perhaps if I solve that “mystery” – I can use Vide better?

Chris

[Malban]

Nope.

Or nearly nope.
More or less the only two things done are:

• convert “long branches” to short counterparts – if that can be done
• convert “short” branches to long branches if necessary (and can be done)
• use direct addressing instead of extended addressing, when DP is known

Those options can be turned of in the configuration.
The “running” bin in Vide is nonetheless exactly the same as on eprom.

This I would like to classify as “highly unlikely” :-).

Chris

[Malban]

So you know what we are talking about…

http://vectrex.malban.de/tmp/crash_82.mp4

http://vectrex.malban.de/tmp/crash_101.mp4

 

[Malban]

– The crash still only occurs on the live system not the emulator

• – What is the difference between a human playing on the real console, and a 100 hours time-warped demo run in Vide

– What corner / extreme situation does a human easily reach while playing, but the demo mode doesn’t?

I also played “live” (not demo) in Vide. It is really boring – but one does what one has todo. I even played about 500 levels in one piece. This is all no guarantee, that a crash can not happen in Vide – just makes it “unlikely“.

– RAM corruption due to faulty hardware
– What about old and aged RAM chips?

Yes – this might be a cause. Although again I must say “unlikely“. Since the crash happened with at least 3 different consoles. Two of mine and Jeromes. Don’t know if any other crashes happened to any other beta testers.
Also – there are many other games, that use “full” RAM (at least all my other games). So I’d dare say, that if it is indeed a faulty RAM – it should manifest itself within other games too.

Usually RAM corruption is a typical coding bug!

… which should be detactable in Vide – that is what I wrote it for :-).
For the linked list – yes, that is a bitch. But still – it is code wise the same as I used in Release/Shongololo/ParticleDemo and others. It has been tested and proven ok over and over again… again – I find it highly “unlikely“.

RAM initialization (non-initialization)

Vide “pseudo” randomizes RAM contents. Per default RAM contains the low byte of the address.
so e.g. $c8a0 would contain $a0, $c8a1 contains $a1.

Dunno – what is the hardware spec of uninitalized RAM? If the BIOS initializes it -> so it would in Vide!
The 2114 RAM specification is included with Vide – but doesn’t say anything about uninitialized RAM (Static random-access memory – https://electronics.stackexchange.com/questions/248950/sram-isnt-blank-on-powerup-is-this-normal seems to suggest its contents is more or less “random”).

But also…
– I tend to initialize RAM, that I use 🙂
– Vide gives out a warning if you read uninitalized RAM (at least my version does)

… again I find it an “unlikely“… cause.

---

So…

Everything seems to be unlikely. Fine – than we don’t have a problem. Good that we cleared that up.

Wait … the crash is still there!

“How often have I said to you that when you have eliminated the impossible, whatever remains, however improbable, must be the truth?”
― Arthur Conan Doyle

My vote at the moment goes to…
Vide is dumb – and somewhere I made a coding mistake :-)!

 

 

[Malban]

Got a crash using the Beta 45.

Theory about faulty VIA cause rejected. Easter weekend wasted. Stopping for today… getting a headache.

Rollback of code will comence soon (old code is faster and shorter – so I will take all changes back).
Stupid thing is – I modified the code at so many places which had nothing todo with the faulty stuff – I can not just switch back to the old code… I must take the changes back one at a time manually…

[Malban]

@Peer:
The latest comments from EF to the blog entry:
11th of April 2020 – Vectorblade update

Might be interesting to you – about the 6522…

[Malban]

Why would VIA know if a “port b” request is “micro cycle” or “macro cycle”?

All there is – is a request on the BUS with address lines coded to “$d000”.

The internal address decoding logic ensures that “read request” is answered by VIA.

VIA is only interested in BUS requests… for all it knows the request could come from the PiTrex (hehe – which sometimes really   it really does!)

 

 

 

 

[Malban]

I actually don’t know if PB7 is latched.
If it is latched – VIA would remember what was last written and when switched with CNTL THAN the value would be available.
But otherwise – no, I don’t think it has any effect.

Actually…

I am pretty sure PB7 is latched – if I remember right – exactly this phenomenon happened to me while changing “to be faulty resistant”.

My printStr was one line off – that was, because the PB7 contained a zero (from a CLR) and when switching with CNTL – the beam automatically started moving vertically…
Took some time to find that rascal – wonder why I didn’t remember that some hours ago…

 

 

[Malban]

You only use DEC when PB is >0.

I have never seen it used when PB is 0 – you are right – that would provoke really interesting effects 🙂

 

[Malban]

So in other words, writing PB7 (when it is in its default state and when it is in output mode) does not have any effect at all?

I actually don’t know if PB7 is latched.
If it is latched – VIA would remember what was last written and when switched with CNTL THAN the value would be available.
But otherwise – no, I don’t think it has any effect.

And just for the sake of completeness, can you give me a code example where you used the DEC just like you used the INC in the VIA post?

Hm, just replace the inc with dec :-).

No – really!
Usually you do a inc/dec (with VIA port b) to switch off (sometimes on – than you certainly have to chose between inc/dec) the MUX.
Since the MUX enable bit is PB0, … in resepct to switching off (changing bit 0 to 1)
dec and inc do exactly the same :-).

Chris

[Malban]

PB7 is in its default state “overwritten” by Timer T1.

If timer is running PB7 is 0 (ramping ON), if timer reaches 0, PB7 reads 1 (ramping off).

As said, you can change that behavior with the CNTL register of VIA

[Author]

Posts