- This topic has 77 replies, 5 voices, and was last updated 4 years, 10 months ago by
.
-
Posts
-
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).
Uploaded “MoreSteps.bin”.
http://vectrex.malban.de/privatBeta
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.
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 lsra bcc noEOR\? eora #$d4 noEOR\? sta random_seed endmRANDOM_A2 macro lda random_seed2 lsra bcc noEOR\? eora #$d4 noEOR\? sta random_seed2 endmTell 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”
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_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!
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 🙂 )
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…
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…
- The forum ‘Vectorblade beta test’ is closed to new topics and replies.