Malban
Forum Replies Created
-
Posts
-
Hm.
To me that more and more sounds like your PB6 is “not stable”, but that is a mere guess of someone who is not electornically versed.
PB6 is not used for anything in original cartridges, and on “modern” cards it is only used to communicate with cartridges (most of the time bankswitching)The question is now – how far are you willing to go?
The ultimate test would be to exchange the 6522 VIA with a known working one.
(either from another vectrex… or one form the “outside”).have done that a couple of times – but it obviously is necessary to open one or to vectrex.
And the only proof we MIGHT obtain is, when both vectrex than behave like the original other vectrex.Only if that is the case we really know more…
Damn it…
—
I have another weird test scenario…
I actually have a vectrex here, which behaved TWO times, like your “special” vectrex – but than never again.
You could try – to have your special Vectrex switched “ON” for quite some time. Than switch it of, and insert the vectorblade card, and see how far it goes (normal card, not the stupid things). With my vectrex nearly got the impression it needed to warm up… now it works…
*throwing arms in the air*
Yes, I more or less expected that – didn’t make sense, that all other games run.
I just don’t know how to circumvent the behaviour, because it absolutely makes no sense.
And will be quite hard to pinpoint the behaviour more exactly.I build a stupid2.bin.
Please try that directly on your special vectrex.
It will be unplayable – but it gives again “printf” statements during calibration.Vectorblade_Beta10.bin – 25th Mai 2019
– bug fix of crash possibilty, probably the one vtk reported with the big alien
– started “stars” in high score edit, also changed the high score font
– calibration: button 4 next calibration, joystick coarse tune calibration, button 1+2 fine tune calibration
– “arrows” on the desktop are slightly brighter– dunno there was something small, ive forgotten
Uploaded a “bigEnemyTest.bin” – that should have the bug fixed.
Starts on fifty. Big enemy appears from 51 on very often…
Regarding your crash.
Actually you are wrong – that one is worse!Peers “bug” can be reproduced (on one vectrex) and is more or less located. We know now when it happens and where, we just don’t know why.
Your “bug” can be “anywhere” (above level 25).
It is so seldom that in 2 weeks playtime (20 hours of playtime?) we have seen it only once. I’d say there is only a very, very slim chance for me to reproduce and find it.This is not your fault, mind you and I am not saying you shouldn’t report crashes – I’d just wish they would be more easy to locate :-).
There are two things we can do:
a) I can build a version where only scoopy bonus fall, that starts in a “higher level” (what region, Star Wars? Star Trek, Sinistar?), and where the big enemy occurs more regularly and where you have a blaster weapon, and than we play… and play …
b) when you play (and you have the equipment) FILM your gameplay. If nothing happens, fine free the space. IF something happens, we have “proof” on tape and can try to reconstruct via the film.
I probably won’t be able to test much until very much later tonight. Work in the garden, friends coming to visit…etc
… bla bla bla …
… bla bla bla …
… bla bla bla …(some time later)
Anyway… FOUND it!
(At least I found one bug, that MUST cause a crash).Will repair it possibly tonight.
As of now – when you have scoopies – do not let the scoopies be destroyed by the Big alien… that WILL crash the game!!!… later…
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…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 🙂 )
VectorPilot?
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…
Gee now you are digging deep :-)…
See – some print routines I do with a shift register initialization like:
lda #%11111110 sta <VIA_SHIFTThan 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 regigsterThe 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!
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 ;;;bwok ;;; sta <VIA_shift_reg JSR Wait_Recal ; Vectrex BIOS recalibration PRINT_NUMBERS_D_AT 4, 0, 0 , 1 ; button 1 REPLACE_1_2_playAKSMusic_varFromIRQ1_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”
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 lsra bcc noEOR\? eora #$d4 noEOR\? sta random_seed endmRANDOM_A2 macro lda random_seed2 lsra bcc noEOR\? eora #$d4 noEOR\? sta random_seed2 endmThat 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.
Uploaded “MoreSteps.bin”.
http://vectrex.malban.de/privatBeta
Please test.
This is still only debugging – no clue what could be wrong 🙁Hm.
At work right now too – so I can’t say what step 4 was.But quintessitially when you get to step 5 – and also can repeat step 5, you ARE already on the desktop screen…
Meaning past the stage where you before crashed.You can repeatedly press 1 – and you will see the scroll text “flicker up”… etc.
If you find the time perhaps test the T1 NOP binary too.—
I have three more vectrex stored away – perhaps I should get them out of their closet and try VB on them too.
