Peer testing notes / findings / suggestion etc

Home Forums Vectorblade beta test Peer testing notes / findings / suggestion etc

Viewing 15 posts - 16 through 30 (of 78 total)
  • Author
  • #3096

    QuadBankTest behaves identical on all four machines: If button n is pressed, then “Bank n” is shown on the screen (n = 0,1,2,3).


    I am very unhappy about this.

    I am building a new binary now with more detailed “printf”s…


    Uploaded “MoreSteps.bin”.

    Please test.
    This is still only debugging – no clue what could be wrong 🙁


    Tested MoreSteps on all machines. The other three all go:

    01,02,03,04,05,06,07, then in broader font 09,0A,0B,0C,0D, then again in normal font 14, from here on the sequence goes back to 04 and seems to loop.

    The no-buzz lab machines goes:

    01,02,03, and then freezes with a dark screen.


    That is totally nuts!

    It comes back from the title screen in bank 0 to bank 2, displays number 3, enters a “normal” display loop (starting at title_0_0), and does not even reach the end of WaitRecal.


    Gets even weirder – since the debug display of numbers – starts with a WaitRecal:


    Ok, I do not understand all the details. I take it that PRINT_NUMBERS_D_AT prints the respective number and waits for a button to be pressed (and released?).

    After displaying number 3, there are two calls RANDOM and RANDOM_A2. I guess it from the comments that these procedures in some way also wait for a button to be pressed (and released?).

    Are we sure that the calls to the random functions return?


    No they are macros with 5 lines of code, no loop nothing.

    They are just called “every” round TILL someone presses a button and starts the game…

    RANDOM_A            macro    
                        lda      random_seed 
                        bcc      noEOR\? 
                        eora     #$d4 
                        sta      random_seed 
    RANDOM_A2           macro    
                        lda      random_seed2 
                        bcc      noEOR\? 
                        eora     #$d4 
                        sta      random_seed2 

    Tell you what – I compile another version with

     PRINT_NUMBERS_D_AT 3, 0, 0 , 1 ; button 1
    title_0_0                                                 ;#isfunction  
    ; MCHANGE                    jsr      PLY_PLAY                     ; the ym song only using channel 1 
    ;;;                    RANDOM_A                              ; random number of random inits (till player hits a button) 
    ;;;                    RANDOM_A2  
    ;;;                    clra     
    ;;;                    dec      buttonWait 
    ;;;                    bpl      bwok 
    ;;;                    clr      buttonWait 
    ;;;                    sta      <VIA_shift_reg 
                        JSR      Wait_Recal                   ; Vectrex BIOS recalibration 
     PRINT_NUMBERS_D_AT 4, 0, 0 , 1 ; button 1
                        ldx      #0                           ; playAKSMusic 
                        jsr      jsrBank1_fromBank2_T1 
     PRINT_NUMBERS_D_AT 5, 0, 0 , 1 ; button 1

    … should be exactily the same …
    (needs only be tested on the trouble maker)

    Name is “Stupid1.bin”

    • This reply was modified 4 years, 4 months ago by Malban.
    • This reply was modified 4 years, 4 months ago by Malban.
    • This reply was modified 4 years, 4 months ago by Malban.
    • This reply was modified 4 years, 4 months ago by Malban.

    The value of register a is zero. What is the effect of:

    sta <VIA_shift_reg

    right before the:

    JSR Wait_Recal


    Gee now you are digging deep :-)…

    See – some print routines I do with a shift register initialization like:

     lda #%11111110
     sta <VIA_SHIFT

    Than for 14 cycles the BLANK signal is switched off and than automatically (when the zeros are shifted out) turned on (BLANK).
    Thus I do not need to explicitly set the Shift reg to zero, the shifting does it all by itself.

    The WaitRecal does somewhere deep inside a
    CLR <VIA_shift_reg ;Clear shift regigster

    The CLR instruction READs the Shift register first. Reading the shiftregister starts shifting. If it starts shifting with above value, blank will be off again for a couple (2?) of cycles – and a bright dot appears in the middle of the screen.

    If I set the shift register to 0 then blank will always be on!


    Ok, I did the stupid test on that stupid machine. It gets a bit weirder, but probably also a bit clearer.

    This time, after flashing the pcb, my first test was on the trouble maker. All the other times I had tested on one of the other machines before going over to the trouble maker. Meaning, all the other times the very first mandatory initial calibration was done on one of the other machines. This time, this calibration should have happend on the trouble maker. But:

    Power on machine, Vectrex square logo comes up, Vectorblade Beta 9 cartridge header screen comes up, then for a split-second the word “calibration” flashes up on the screen, then the machine resets and goes back to the Vectorblade Beta 9 cartridge header screen. This continues. Also when pressing the reset button by hand. Calibration is not possible.

    Switched the machine off, then calibrated the pcb on one of the other machines, and went back to the trouble maker. Now, as in the previous experiments, all goes well until the 01,02,03 sequence. However, this time, after the 03, I experienced different behaviors. In the first go, I had a blank screen and freeze after the 03. Reset by hand. In the second go, the machine reset by itself after the 03. In the third go, after the 03, “some vectors” briefly flashed up, before the screen again went blank and everything froze. Reset by hand. Now I got the Vectorblade Beta 9 cartridge header screen, but strangely bright and with one extra horizontal vector line drawn in the upper part of the screen. At that point I switched off the machine as this looked really strange and I did not want to damage anything.

    Does the “no initial calibration” issue tell you anything? Or is this a ghost chose, and everything happens due to some hardware defect on my machine?


    I don’t know.
    I have no good explanation.

    It makes no sense that the machine crashes at those points:
    a) where every other machine (that we know) works
    b) that these are at least two different locations
    c) that the behaviour is different (uninitalized RAM could account for that though – if I somewhere would have such)

    This would point to some hardware “uncertainties” – maybe RAM, VIA or some “address line” or whatever.

    What totally speaks against that theory is, that other games/cartridges work.

    If you have some time left – you might try a round of “Release”.
    That game (I know) uses all RAM, and is 32k – thus uses all ROM space (but no bankswitching).

    If that works fine I am even more at a loss.

    Than unwanted bankswitching is always a good crash cause…
    Do you have any other 64k carts?
    VectorPatrol? (AWESOME – if you don’t have it – get it 🙂 )
    Another one from John Donzilla also has 64K I believe…

    Thanks for your time helping finding things out.

    But I am really sort of tempted to “let it go”.
    I can’t do much from here – and unless we find another Vectrex that crashes I might give “the vectrex has a defect” a try…
    (Although I am still quite unhappy about the whole affair).

    Perhaps I should look for more beta testers, to broaden the vectrex we can test on…


    Agreed, you should definitely give this no priority.

    I will try Release tomorrow. And no, I do not have any of those other games 🙁

    I will run more tests on that machine. More original games, and I will also probably write my own RAM checker. I would be happy for you if it turns out that this has nothing to do with Vectorblade, but at the same time I hope that the machine is fine as I am relying on it in class. I always thought of it as the one of my consoles which is in best condition. 🙁


    Perhaps you could also run the Test Cartridge.
    At least it could output a ROM checksum – there are 3 different ROM versions… not that this should make any difference…

    If you don’t have it – you can use the VecFever to “load” it…

    So that you can easily find it – I put it in the privateBeta directoy: “TestRev4.bin”


    Yea I can see the two sides you describe. Personally my favorite would be (in decreasing order):
    – your vectrex is ok, and we can find whats wrong
    – your vectrex is not ok, I have no bugs
    – your vectrex is ok, I have bugs in VB and can’t find them…

Viewing 15 posts - 16 through 30 (of 78 total)
  • The forum ‘Vectorblade beta test’ is closed to new topics and replies.