Malban
Forum Replies Created
-
Posts
-
Vectorblade_B48.bin – 4th Mai 2020
and the same as VecFever variant:
Vectorblade_B48.V4E – 4th Mai 2020
The crash I removed was NEW – and due to size optimization, instead of a “LSLA” I accidently wrote a “LSRA”, which for a list/pointer access could be fatal.
I could not test the new binaries longer than 1/2 an hour or so… can’t concentrate – I hope these are “better”.
@Peer: I checked those RAM locations, and they get repopulated correctly after a minestorm.Cheers
Chris
Hi.
writing from near the baltic sea :-).
I dug out my laptop and started Vedi and Vectorblade.
I can confirm – the bug is visible in Vedi. I shouldn’t have come up with a not fully tested version – I am sorry about that.
As said – I have seen the crash – but not investigated yet.
But sadly I strongly suspect that bug is a “new” one… probably related to the 3 bytes of RAM I freed.Thx for all your efforts and involvement. I will investigate further once I am back in Duesseldorf.
Cheers
Chris
Thx for all reports.
since the High Frequency of the crashes – I suspect this is a new bug.
My fingers are itching to investigate – but I cant here…
So for this week – you must do all Investigations on your own!
I hate you!
😏
Any more information?
Did you have scoopies? Picking up something?
As said … I didn’t have a crash in a long time…
well – anyway … vectorblade is on hold for a week now…
Ah shit …
yes – to much hectic to day.
It’ll work but not save anything.
I forgot to switch the VecFever flag. This is actually the Flash version. It runs – but does not persist anything…
Sorry – can’t change it now, I’m on my way already…
Chris
Vectorblade_b47_normal.bin – 25th April 2020
Vectorblade_b47_stack2larger.bin – 25th April 2020
Vectorblade_b47_stack2smaller_danger.bin – 25th April 2020 (for Peer experiments!)
and the same as VecFever variants:
Vectorblade_b47_normal.V4E – 25th April 2020
Vectorblade_b47_stack2larger.V4E – 25th April 2020
Vectorblade_b47_stack2smaller_danger.V4E – 25th April 2020 (for Peer experiments!)
Preferable the “normal” one should work.
If have not found THE bug yet. But changed many things… so your are all welcome to try again.
If “normal” crashes – please try the stack2larger variant (although I can’t imagine why it should work better).I haven’t had a crash in a long time – but that doesn’t mean much.
Due to time constraints and an upcoming holiday, I could not really “finalize” this version – but I hope it will be all right.
Following changes (in my own strange notation) have been implemented (and partially removed).
; done: Wheel spin adjusted for hardcore, added "TIME" / "SCORE" instead of "LOCK" / "LIVES" ; done: adjustment to mothership for hardcore ; done: bonus drop adjustment for hardwcore (no cash, no cashbomb) ; done: after game over sequence, bonus structure was not initialized, due to reuse by black hole, this could cause a crash! ; done: free 3 bytes of RAM ; done: EXTRA letter to "short" ; done: shots were not correctly initialized for boss fight - dangerous! ; done: multi shots with swarm boss were not behaving... ; done: perhaps Biggies can be hit by scoopies AND main - default is only ONE shot hits... ; done: can a scoopy on the utter right side hit by a shot on the utter left side??? (yes, could happen!) ; done: difficulty inscription in pause == in option! ; done: pause text a little bit further left (so high officer ranks are more fully displayed) ; done: Very high timer values - get not "translated" correctly to ascii? (> 655 $7fff...) ; done: demo not working? No Not working! (if statement was not working as intended) ; done: Level 75 pattern moved down ; done: shop moved down ; done: bug "range" moved down ; done: moved HS and EXTRA down to the side ; done: Moved saucer and mothership ; done: shop is unscalable ; done: desktop scale corrected ; done: calibration scale corrected ; done: if screen is smaller - than desktop icons are not correvtly placed! - shop dito ; done: gameover reinitiates $80 gamescale? ; done: to add "size" value to size calibration, and limits, also allow grow ; done: hardcore mode -> no shop? No cash ; done: star wars boss further down ; done: highscore skill replace ; done: Secrets->no secrets found yet message ; done: laser rank missing ( achievment list) ; done: keeping, is cool! scoopyshield activated -> also for scoopy caught aftwer??? -> wrong! ; done: officer rank OOB -> message, no free positions to next rank! ; done: achievements title -> lower (overlay) ; done: help for mode missing ; done: ? or bug Saucer can NOT drop rank? could happen if xPos == 0 ; done: biggy could not drop rank: can still happen if 2 biggies are destroyed in the same round -> only 1 bonus spawn possible per round! ; done: super diamonds - small diamonds look "crooked!? ; done: CRANKY STUFF - VecFever test ; done: Spin the wheel success message out of bounds! (secret)only non vecfever? or only faulty vectrex? ; done: Desfription of Achievements still name "old" level modes! ; done: in shop playerMaxShotInAir can reach "B" on a real vectrex ; this is due to starting with 10 bullets in test, and the NMI restriction to only have 8 ; done: yes can ...warp failur on hard -> can not kill enemies? ; done: Boss test -> whole game! ; done for cranky VIA: ; done: minestorm diamonds look bad ; done: final boss explosion looks bad ; done: superbomb looks bad ; (new calibration "size" not done for crabky via!) ; done: calibration: box around the BUZZ no BUzz - in emulator also ; done: Pause mode - Pause first line not shown - not in emulator ; done: in game, left right not working (only when button pressed!) - not in emulator ; done: in between levels not working at all - not in emulator ; done: in shop total money not in correct place ; done: up and down in calibration not working ; done: after minestorm crash - enemies can not be hit anymore? - Shots not "created anymore?) ; done: in minestorm not at all working ; done: in minestorm asteroids not shown- in emulator also
Chris
Yes, I know about that one. Vide also emulates it.
Can’t IMHO cause crashes – but it can leave unwanted “artefacts” on screen.
e.g.
Fill Shift register (for pattern drawing) with something like: %10101010 (a dashed line).
Draw the line (the last zero enables blanking) and move to a new location.
If at the new location you would start with a “CLR SHIFT_REG”, than
you would see an “unwanted” dot – since the shiftregister starts shifting with the “read” of the clear instruction (and thus outputting the first “1” before zeroing the shift reg).The read happens before the CLR.
(happened to me in the past 🙂 )
Cheers
Chris
PS
Emulation code:
case 0x0f: ea = ea_direct (); vecx.vectrexNonCPUStep(PRE_CLR_STEPS); inst_clr (); read8(ea); // clear reads! important for shift reg emulation! e.g. vecx.vectrexNonCPUStep(POST_CLR_ADDSTEPS); write8 (ea, 0); cycles.intValue += 6; break;Default stack address is (usually) $CBFC.
“Reading” from there doesn’t destroy anything, writing again after reading – would.
not used yet: $cbfc
chosenStartLevel = $cbfd
isDemoMode = $cbfe
realEnemyCount = $cbffAfter that it gets dangerous, because the addressing logic for RAM “rolls over” -> YM buffer is “next”.
Enemy count would be “strange”, probably a level could not be finished. usually the level is finished, when enemyCount is zero…
RAM Checker:
Tried on 4 consoles -> no error
RAM Checker “endless” tried for a minute of so on same above four consoles -> no error
Vide
I can do a “single” jar for you, no full release thoughStack.
Can do…
Either today or tomorror – as time permits…
Chris
Hi,
after my latest “negative” finds – I did lots and lots of testing (including the watchdog in Vide).
Real console proof of much testing: see image
As much as I like Vectorblade – there comes a stage where you get sick of playing hours on end.
I also played in parallel (ok, ok sequentially) in Vide.
No crash. In either the real and emulated game.
While theoretically it is wonderful to have no crash – the already found bugs can not explain all “old reported” crashes, so I must assume some bug still resides, but does not show itself at the moment.
From Saturday onward, I will be out of town for 8 days, so I will not be doing ANY Vectorblade during that time. Actually that “natural” pause is quite welcome at the moment.
I surely intend to keep on bug hunting afterwards – but to keep my sanity I also want to do some more “visible” things.
- finish the instruction booklet
- order packing material
- order the instruction booklet
- make changes to the game to “fit” the overlay better
also…
Major Havoc
While the “additional” extra game has (IMHO) a very cool and unique engine (soft scrolling with “soft” clipping, (animated) tile based levels, collectibles and extra “moveable” adversaries etc… ) – I still suffer from the same syndrome the engine started with:
a) do not really know what to do with it
b) I just can’t bring myself to further work on it (just now)Sooo…
I put this to the vote with you guys:
– do you want me to continue on this path? Than I will force myself to do something with it… and being forced I am sure I will come up with something nice– or not.
(short message yes/no is sufficient – but you are allowed to elaborate)If the vote is “No” – I will have a couple of kB free space – which I would probably fill with some other additional stuff.
At the moment I am toying with the idea to change the fighter appearance with the amount of installed enhancements.
That would cost lots of space – but IMHO it would be cool if the fighter reflected e.g. the kind/number of shots you have available.Or… a special “reward” for an achievement could be an new fighter “skin” (just another appearance).
Before my “holiday” I will built another beta binary… that you can test if you find the time.
I will build a non debug binary, as in no NMI “controller”, no test mode. All levels, all “normal” game features, since that is the way the game should “work” as.As an additional safety measure I will try to free “two bytes” in RAM for the stack (@Peer: just to be on the save side).
In my current debug setting I have more stack, and at least up till now – no more crash.
So perhaps there IS some weird place the stack goes nuts. … well … just to be save.And I know there are some bytes, that only use a couple of bits – I just have to join these…
Sooo…
This is my current “stand”.
Regards
Chris
🙁
False alarm… didn’t find anything “new” 🙁
Gee I feel dumb sometimes. Perhaps double checking befor posting would not be a bad idea…
Exciting times!
Never distrust Vide!
I wrote a special function, to watch all RAM pointers. Stupid boring function:boolean checkRAMPointers() { int[] toCheck= { // enemy shots 0xc903+0*12, 0xc903+1*12, 0xc903+2*12, 0xc903+3*12, 0xc903+4*12, 0xc903+5*12, 0xc903+6*12, 0xc903+7*12, // BONUS 0xc963+8*0, 0xc963+8*1, 0xc963+8*2, 0xc963+8*3, 0xc963+8*4, 0xc963+8*5, // stars 0xc993+0*13, 0xc993+1*13, 0xc993+2*13, 0xc993+3*13, 0xc993+4*13, // enemies 0xc9d4+0*21, 0xc9d4+1*21, 0xc9d4+2*21, 0xc9d4+3*21, 0xc9d4+4*21, 0xc9d4+5*21, 0xc9d4+6*21, 0xc9d4+7*21, 0xc9d4+8*21, 0xc9d4+9*21, 0xc9d4+10*21, 0xc9d4+11*21, 0xc9d4+12*21, 0xc9d4+13*21, 0xc9d4+14*21, 0xc9d4+15*21, 0xc9d4+16*21, 0xc9d4+17*21, 0xc9d4+18*21, 0xc9d4+19*21, // player shots 0xcb78+0*10, 0xcb78+1*10, 0xcb78+2*10, 0xcb78+3*10, 0xcb78+4*10, 0xcb78+5*10, 0xcb78+6*10, 0xcb78+7*10, 0xcb78+8*10, 0xcb78+9*10, }; for (int i=0; i<toCheck.length; i++) { if (getPC() == 0x53a) // main loop start { int ram = e6809_readOnly8(toCheck[i])*256+e6809_readOnly8(toCheck[i]+1); if (ram < 0xc800) { breakpointExit=EMU_EXIT_BREAKPOINT_BREAK; CSAMainFrame frame = (CSAMainFrame) Configuration.getConfiguration().getMainFrame(); DissiPanel dissi = frame.checkDissi(); if (dissi != null) { dissi.printMessage("Vectorblade RAM corruption: "+String.format("$%04X", toCheck[i])+"->"+String.format("$%04X", ram), DissiPanel.MESSAGE_INFO ); } return true; } } } return false; }And played… and played… (in Vide).
In level 96, the “breakpoint” triggered!
There was a RAM Pointer corruption in the player shot object!
(PlayerShot 8 to be exact – nowhere near the stack)Silly me, I switch off “stepping” back, so I could not figure out what happened (inspite me having a save game only 10 seconds before the fault).
But this mean:
- there is another bug, that I CAN figure out using Vide! – if I am patient
- perhaps that is the final!
- I might add a new feature to Vide – to save states automatically every XX round…
- I defenitly will not switch off “take steps back” the next time.
CHEERS
Chris
One down – probably more to go!
I found one bug, that could corrupt the bonus list. This could and defenitly has caused crashes.
Thing is, this bug could only happen AFTER one roll over. Actually, after the “black hole”, the list was not re initialized – so bad pointers were present.
This was a good find – but could not possibly cause any crashes, that happened BEFORE level 100!
I also did some more stack tests.
In game (played about 25 levels with the emulator) the stack does not come “near” any the player shots.
(near being relative – it’s 4 bytes away, but that is 1/3rd of the comeplete stack 🙂 )Out of the game (achievments, shop etc) it goes 4-6 bytes “into” the player shot. But there never are player shots in this program part – and they get “reinititalized” befor the main game.
I did another “play through”, and had another crash, again in the first level (after roll over).
Suspicious:
That is the 3rd crash at exactly the same location (but it also often does NOT crash there).
The stack (after NMI investigation) pointed to $fc07 – which is utter nonsense, and since that is in the ROM area I could not even find the location, where the NMI took place.I again investigated all lists – this time the bonus list contained an “illegal” location, a bonus behaviour pointed to $c203, which I am quite confident … can lead to a crash.
I also observed during the game “interesting” things. The UFO (which can programmatically drop only “ranks”, dropped at one stage a “20” (money) – which points to a “corruption” as well.
I don’t know if I am getting paranoid – or if these “corruptions” were in there all the time and I did not notice them – or if I put them in there with my debugging codings.
I keep looking.
Next I am going to play a few “hours” emulator games only.
It would be an incredible coincidence if the emulator could also “detect” the crash situations – but hasn’t as yet.
But I’ll give it another (couple of) shot(s).Cheers
Chris
No worries, thanx for you persistency – and your interest in Vectorblade in general.
Of course you are right – somewhere there must be a cause.
Two words on stack corruption:
- a stack bug is really a “simple” bug (a bitch – but simple in itself), I would highly expect it to be shown in an emulator – never once has there been a crash in an emulator
- there is no “long term” test per se. In my excel sheet I spoke of “reset stack pointer”, literally the first line in my main loop is:
main12:
lds #MY_STACK ; CBFC ; correct the stack to default address – so it is set completely anew!
The longest time, the stack is active, are the first couple of lines in my main program :-).
That being said – I totally agree with you, that the most probable cause for the crash is (generalization) a pointer going astray (at the moment “any” pointer comes to mind, not only the “S” register, but maybe “U”, “X” or “Y” – whatever register I take as a index based addressing).
This still constitue two problems:
- where
- what is the root cause?
Meaning, a pointer does not go astray all by itself.
My main problem indeed with the whole situation is, that it is (or seems to be) not replicable.
– I have no means to reproduce it reliably on the hardware
– I have not been able to even reproduce it ONCE in VideThe last point worries me most because it hints a possibility that it is NOT a coding bug, but some unkown “feature” of the vectrex.
I honestly am thinking about programming my bankswitching scheme into MAME/MESS to have a second emulator run Vectorblade. MAME/MESS has proven excellent emulation of VIA and 6809.
…
For know … I going hiking with my girlfriend… and try to clear my head a little bid.
Cheers
Chris
