Malban
Forum Replies Created
-
Posts
-
Nope.. Ramp wouldn’t cause a crash…
One other thing that I can think of… (VIA related)…
If for whatever reason, interrupt flags are not set – that would cause endless loops – where I wait for them.That did happen in the past… can’t remember what caused that.
It had something todo with timer T2 (the wait recal timer).
It was a programming error – not a VIA bug. Like clearing the flag and than waiting for it without starting the timer again… or something similar.Although the timer keeps runing (and reaches 0) – no “second” interrupt will be issued after the first “0” reach. So waiting for the flag to change will never happen.
Darn – I didn’t write that one down.
Cheers & happy easter to you too!
Chris
Thx for playing!
Since you play from the VecFever, and I didn’t change the savegame – name, you still have the “old” settings stored.
That also means the “life” achievement is still active :-).4 shots – have always been more difficult with the first boss – it’s because they are so “wide spread” – they tend to hit more insects….
Happy easter!
Chris
PS
Perhaps interesting for you:
Has a short passage about Vectorblade :-).
… 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?
“easy”:-)
More or less what was hinted in the blog article…1) Remove ALL “INC/DEC”
in regards to VIA_PORT_B (I don’t use NEG/COM with VIA, who would???)2) This also means do not use ANY of those BIOS functions:
;Wait_Recal EQU $F192 ;
;Joy_Analog EQU $F1F5 ;
;Joy_Digital EQU $F1F8 ;
;Recalibrate EQU $F2E6 ;
;Moveto_x_7F EQU $F2F2 ;
;Moveto_d_7F EQU $F2FC ;
;Moveto_ix_FF EQU $F308 ;
;Moveto_ix_7F EQU $F30C ;
;Moveto_ix_b EQU $F30E ;
;Moveto_ix EQU $F310 ;
;Moveto_d EQU $F312 ;
;Print_Str_hwyx EQU $F373 ;
;Print_Str_yx EQU $F378 ;
;Print_Str_d EQU $F37A ;
;Print_List_hw EQU $F385 ;
;Print_List EQU $F38A ;
;Print_List_chk EQU $F38C ;
;Print_Ships_x EQU $F391 ;
;Print_Ships EQU $F393 ;
;Mov_Draw_VLc_a EQU $F3AD ;count y x y x …
;Mov_Draw_VL_b EQU $F3B1 ;y x y x …
;Mov_Draw_VLcs EQU $F3B5 ;count scale y x y x …
;Mov_Draw_VL_ab EQU $F3B7 ;y x y x …
;Mov_Draw_VL_a EQU $F3B9 ;y x y x …
;Mov_Draw_VL EQU $F3BC ;y x y x …
;Mov_Draw_VL_d EQU $F3BE ;y x y x …
;Draw_VLc EQU $F3CE ;count y x y x …
;Draw_VL_b EQU $F3D2 ;y x y x …
;Draw_VLcs EQU $F3D6 ;count scale y x y x …
;Draw_VL_ab EQU $F3D8 ;y x y x …
;Draw_VL_a EQU $F3DA ;y x y x …
;Draw_VL EQU $F3DD ;y x y x …
;Draw_Line_d EQU $F3DF ;y x y x …
;Draw_VLp_FF EQU $F404 ;pattern y x pattern y x … $01
;Draw_VLp_7F EQU $F408 ;pattern y x pattern y x … $01
;Draw_VLp_scale EQU $F40C ;scale pattern y x pattern y x … $01
;Draw_VLp_b EQU $F40E ;pattern y x pattern y x … $01
;Draw_VLp EQU $F410 ;pattern y x pattern y x … $01
;Draw_Pat_VL_a EQU $F434 ;y x y x …
;Draw_Pat_VL EQU $F437 ;y x y x …
;Draw_Pat_VL_d EQU $F439 ;y x y x …
;Draw_VL_mode EQU $F46E ;mode y x mode y x … $01
;Print_Str EQU $F495 ;(didn’t look at more exotic functions)
3) Tweak the game till it runs again, and looks good
Chris
PS
As you would expect of me – Vide now also features a “faulty” switch… 🙂@Jerome:
Thx for your input and your continuing efforts!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
ChrisVB_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.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!
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 DDRBNOTHING 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
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
The WeirdTest binary you wrote for checking the type of VIA, as far as I understand, does some sort of “test”. Does it do this “test” only once, and then come up with an answer, or is the “test” done repeatedly?
What if you created a “while(1) {test}” ForeverWeirdTest binary that just keeps on checking the VIA (no VB stuff)? If your theory is correct, that some VIAs behave weird only every once in a while, then shouldn’t this be a way to chase such behavior?
As of now – the “tester” only tests once.
I can certainly do such a repeated “tester” – thing is… it <might> 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…
New theory.
Since my standard test – vectrex is at Thomas place, my second standard test vectrex runs the bankswitch ordeal…I fired my third vectrex up and tried some more testing there.
After some experimenting it seems that my “third” Vectrex has become “weird” as in:
http://vide.malban.de/1st-of-june-faulty-via-vs-inc
Gee – sometimes it doesn’t just rain, it pours.
Anyway – it occured to me, that the faulty behaviour seems to be quite similar to the “crashes”.I know it sounds strange – but what if…
… what if some VIAs are faulty, some are not faulty… but some are faulty only once every 1000 accesses or so?
Since I don’t have any other straw to cling to – I will take this one.I will (as mentioned in the above link) rewrite the routines to be “faulty” insensitive. This will take a bit of time, so probably no update for some more days. But once I finish the “insensitive” version – you guys (Jerome?) can go crash hunting again.
Cheers
Chris
