Downloadable Vectorblade versions

[Malban]

Thx Jerome!

[Peer]

As of now – the “tester” only tests once.
I can certainly do such a repeated “tester” – thing is… it just be, that there are very weird prerequisite, so that VIA might behave differently. Some IRQ at a specific falling edge of a cycle… Timer T1/T2 overflow… or whatever.

So while very interesting to do such testing – it might still be that such a tester does not show a useful result. Since I can not guarantee, that all “cases” are really tried out…

Yes, I know, it is just a shot in the dark. But, following your VIA line of thoughts …

Conjecture: The “Bug” might not be due to some “logical” and deterministic code-related situation, but due to some old and aged piece of hardware (some analog effects in some old capacitor, … ???) in combination with only certain types of VIAs. Thus, the bug appears only “randomly”, and possibly without any code-related cause. So if a deterministic ForeverWeirdTest, which just repeats the very same test over and over again, suddenly fires, then we know that we are screwed. If the test does not fire, we know nothing. Or maybe get a tiny bit of assurance that we are not dealing with such (age) effects.

If I were only half as bright as you are, and if I had your experience and knowledge, then I would try to write such a test on my own, and simply let it run. But alas, I am not 🙂

If your test basically consists of just one “subroutine” which can be called from any kind of code context, then you could send me the code, and I could rather quickly generate all sorts of context situations in C, and then just call your test code. Or call the test code within my past C game projects and just let them run. That would increase the number of code scenarios tested…

[Malban]

I let an endless VIA – test run overnight.

It does not do anything else, than test the VIA – and breaks if it finds a fault, and than gives out a message (otherwise no WaitRecal, no waits whatsoever, -> REALLY many tests over night!).

Ran about 9 hours – no fault. So I doubt  a “normal” stress test without any special VIA changes will show something :-(.

You are welcome to try though.
For easyness I translated the VIA test to “C” (and you will see – it really IS a complicated test) :-).

---

#define TRUE (1==1)
#define FALSE (1==0)
#define bool int


bool isWeird()
{
	dp_VIA_DDR_b = 0xdf;
	dp_VIA_port_b = 0x01;
	if ((dp_VIA_port_b & 0x40) == 0x40)
		return TRUE;
	return FALSE;
}

int main(void)
{
	while(1)
	{
		Wait_Recal();
		Intensity_5F();
		if (isWeird())
			Print_Str_d(0, -70, "WEIRD VIA\x80");
		else
			Print_Str_d(0, -70, "NORMAL VIA\x80");
	};
	return 0;
}

---

 

Cheers

Chris

[Peer]

For easyness I translated the VIA test to “C” (and you will see – it really IS a complicated test) :-).

Lol, yes, that is something even I understand 😉 Thanks for the code, I will start testing tonight.

And just to be sure: Does this C code fire for the infamous broken VIA I sent you?

Cheers,
Peer

[Malban]

Yep – it sure does!

🙂

 

[Peer]

Ok, here is another sub-theory of the “weird VIA” kind:

It is closely related to the ones we have been pursuing recently, and it is directly related to your post about the INC instruction (http://vide.malban.de/1st-of-june-faulty-via-vs-inc).

Phenomenon + hypothesis:

Sometimes, PB6 does not have the value that was expected, and as a consequence an unintended bank switch happens.

Potential causes:

a) A faulty VIA: reading PB6 does not yield the value that was previously stored.

b) A glitchy VIA: only every once in a while, for no apparent reasons, reading PB6 does not yield the value that was previously stored.

c) A normal VIA: reading PB6 gives the correct value, but some not yet identified cause has changed this value and so it differs from the one that is expected (i.e. the one that the VB code has previously stored).

My train of thoughts is following c) now.

I read the Rockwell 6522 data sheet. The upper section of page 4, called “Port A and Port B Operation”, among other things describes what is supposed to happen if PB6 is read while being configured as output. Basically it states that you get the “value that was last stored in PB6”, whatever “stored” does mean in this context (A store while being configured as output?, I have to admit, that I do not understand everything to the last detail here).

Malban’s post about the INC instruction pictures the following situation:

CLR VIA_port_b
<something inbetween>
INC VIA_port_b

The micro-code of the INC instruction reads and then writes to port b. It should read an 8-bit zero, and then increment that zero to an 8-bit one. Thus, PB6 should have value 0. What now, if that <something inbetween> alters the value of port b, so that the INC does not read an 8-bit zero? I am not talking about some hardware glitches or a faulty VIA, I am looking for some perfectly valid reason for this.

The Vectrex Programmers Manual Part 1 describes port b as follows:

Port ‘B’ Data – Vectrex Hardware Control [CNTRL]
Bit Description
0 Sample / Hold strobe
1 Analog multiplexer select, bit 0
2 Analog multiplexer select, bit 1
3 Sound generator, term ‘BC1’
4 Sound generator, term ‘DBIR’
5 Analog compare term (Input to 6522)
6 –
7 Integrator ramp

Some of those are possibly configured as inputs, the others as outputs. Now, when clearing port b, and then later on reading from port b, do we really get a zero? Or do we get “some” 8-bit value which is possibly quite different, depending on the whole configuration of the pins, and on the instruction sequence executed before.

If the INC reads a pattern like xx111111 (and right now I do not see any strict proof that the INC really reads the zero that was stored by the CLR), then the increment would change the value of PB6. So would a DEC if it reads a x0000000 pattern.

I do not fully understand PB3-5, but maybe some sound playing can alter the read values of all port b bits?

Yes, this is a shot in the dark, but the patterns mentions above would probably be corner case situations which might occur only under very rare circumstances while playing VB.

I do not know if this is possible, but can the <something inbetween> code part be interrupted? By a processor interrupt I mean? Could there be other instructions, maybe using addressing modes which, as a side effect, change the value of port b (post inc or dec)?

Does this make any sense?

Cheers,
Peer

[Malban]

Hi,

I know very well, that a keypart of ones own mistakes/produced bugs probably is hybris – like in
I know how that works and I didn’t make a mistake.
So all I will say in the following must be taken in the context of the above :-).

No.

In Vectrex relation the only method to change PB6 is:

Depending on input/output mode
– write a value to it from the vectrex side
– write a value to it from the cartridge side
AND
– change of the data direction “can” change the value, depending on previous value received/output.

If (from the vectrex side) the PB6 is in output mode it still – should – read the
last value you put into PB6. (the faulty one doesn’t)

There are other PB pins (7 e.g.) that can be “overwritten” by certain VIA behaviours.
E.g. PB7 can be overwritten by the Timer T1 (PB7 is in vectrex relation the RAMP signal).
So the RAMP can be either controlled by the timer (default) or by PB7
(to enable one must change the mode in the CNTL register).

In “input mode” (vectrex “receives” values from PB6) the read should always be “1” (pullup resistor, and
I don’t have any special circuit on the cartridge).

So….
Unless the <something in between> is not:
– write to PB6 (this also includes INC/DEC/COM/NEG)
– change of DDRB

NOTHING should change the value of PB6.

I don’t use 6809 interrupts, ever! – Otherwise the bankswitching would not be possible
– since I use the IRQ line for that. The 6809 interrupt only occurs if the “i” flag of the processor is
correctly set – which it NEVER is. So no, there can be no interrupt.

The other things you say…
It would be possible for UNDOCUMENTED/faulty behaviour internal to the VIA to cause trouble.

Like a VIA interrupt occurring at the falling edge of a cycle and a nanosecond later a special
voltage level on PB5 and/or at the same time the shift register doing one shift… or whatever.
We might never figure that out.

———

On that note – I will do another blog entry later.
Short summary…

I am (still) in a very bad vectorblade mood.

1) still the crash
2) I changed Vectorblade to be faulty “resistent”, this took me 3 days… and overall Vectorblade is
– hundreds of cycles slower!!!
– more bloated
3) I still have to debug the version thoroughly before releasing it
4) I got the overlays… they are IMHO the best looking vectrex overlays around…
BUT
They cover to much of the screen area, so parts of the action can not be seen.
5) I don’t know how to change VB to accommodate this.
If I add another calibration – it will cost AT LEAST another 1000 cycles per round.
And VB is already slower than I wanted it to be.

“Anti – Cheers” 🙁

Chris

[Malban]

PS

Also note:
There is no code, other than bankswitch related, which EVER changes the data direction of any line of port B!
Port A is regularily configure input / output… Since communication with the PSG needs switching.

But Port B is NEVER changed!

[Peer]

… ah, shoot, sorry to hear about all that 🙁

Oh, boy, if I only knew any way to cheer you up? What about a virtual beer tonight? Or a large box of virtual chocolate bars?

It might be in vain, but here is an after-thought to my last post:

Your example uses the (first CLR, then later) INC in order to effectively put a 1 into PB0. What if the <something inbetween> causes a condition so that the INC reads a 1 on PB0? Not because of any programming error on your side, but due to some internal VIA glitch/age/read-from-output/whatsoever effect? Then the INC would put a 0 into PB0. Could that lead to a crash?

I am trying to put the blame on PB0 rather than PB6.

Under the assumption that an INC (which does a read-modify-store on the micro-cycle-level) simply does not (always?) work correctly in combination with a VIA port.

I hope you know what I mean. Sometimes I find it difficult to put my thoughts into exact words, especially when it comes to the low-level Vectrex stuff…

[Jerome Vince]

Hi,

Just a little information about the circumstances of the 2 crashes i experienced today with the VB beta 44 VF version. I wanted to play it as a “normal” version to test it. I got the first crash (fastly) picking up the “Minestorm” bonus at the end of a level (all ennemies were killed).  There were numerous bonuses to collect at the same time.

I did not get a message after the crash, just the black screen and and a continuous buzz.

the second crash occured in similar circumstances at the end of the level 42 collecting several bonuses at the same time,  moving the ship from the left corner to the right side of the screen.

I was surprised to get 2 crashes in less than 30 minutes with similar conditions. The crashes i got before were very rare. I will try to reproduce it again and i will let you know.

(PS: i played the normal mode and the hard mode)

[Malban]

VB_FAULTY_45.bin – 11th April 2020

VB_FAULTY_45.V4E – 11th April 2020 – VecFever version

I played this version up to level 110 or so – just as a tryout – whether everything works alright.
It plays very well on the faulty vectrex. As of yet – no crash. But playtime is only about 1-2 hours.

Who ever has time and is willing… please test extensively – until anyone reports a crash – I will too.

(PS – Blog update with overlay images!)

Chris

PS
Also a couple of bugfixes/changes – and bosses should have more HP in higher difficulties.

[Jerome Vince]

Downloaded (VF version)!

[Malban]

@Peer:

Your example uses the (first CLR, then later) INC in order to effectively put a 1 into PB0. What if the causes a condition so that the INC reads a 1 on PB0? Not because of any programming error on your side, but due to some internal VIA glitch/age/read-from-output/whatsoever effect? Then the INC would put a 0 into PB0. Could that lead to a crash?

I am trying to put the blame on PB0 rather than PB6.

PB0 “only” enables/disables the MUX. Might have under the wrong circumstance “weird” effects – but IMHO should not lead to a crash. (Wrong sound/wrong intensity/wrong vector positions)

Under the assumption that an INC (which does a read-modify-store on the micro-cycle-level) simply does not (always?) work correctly in combination with a VIA port.

Oh, I think it works correctly – a flaw like that would probably be known.
I don’t think the VIA “knows” that it is read from a “inc” rather than a “lda”.
I am more worried about some internal VIA stuff, that we don’t know about.

Or perhaps things that “old” VIA (> 30 years – hahaha!) might first be effected by defects… and which are not obvious in “normal” circumstances…

You phrased that “micro-cycle-level” correctly – before you spoke of “microcode” – the 6809 is one of the few processors, that is not build upon micro code :-)…

I hope you know what I mean. Sometimes I find it difficult to put my thoughts into exact words, especially when it comes to the low-level Vectrex stuff…

I think I do – and “not exact words” (even if that is not the case) are better than no words at all.
And often times it just helps to talk things through… so thank you! All thoughts are welcome!

Cheers
Chris

[Malban]

@Jerome:
Thx for your input and your continuing efforts!

[Peer]

… I will play as often as I can over the weekend. And I will continue my own experiments / investigations of port b input-output behavior. There are some things I still do not understand. Could you shortly describe the “fix” you implemented to make version 45 faulty-tolerant?

Cheers and Encouragements,
Peer

[Author]

Posts