Malban
Forum Replies Created
-
Posts
-
I can’t sleep. Vectorblade is circling in my head… Geee…
Anyway – I thought of a “cool” way, which might give us more clues. With the removal of Major Havoc, I have ATM about 15kB more space available … and one thought led to another.
1) … I can use space in bank 0 to write to the flash
2) I need a flash internal bank of 4kb (that is the block size that can be erased)
3) I can “save” a game state there, so the player can turn off/vectrex in a “pause” situationwhich than led to…
I can save the gamestate when I press the NMI…
Which than led to – I can have 3 saved games.
- one “manual”
- one NMI
- one “each level”
One such game save is 1024byte + 4 (all RAM + U and S register) – so in 4k I can save 3 games.
If I play, and save each level, plus when I deem necessary “manually” and when a crash really happened. Than I have three states that I can examine, which may lead me to an answer.
If I save the data to the flash – I can READ the flash with my (if not broken) EPROM programmer and actually LOAD the states in Vide!!! (Ok – still some programming to do for that)
But that way I can actually access data generated by a real vectrex. Provided the “autosave” of each level works… I can RESTART at the exact level, where the crash occured.And since WaitRecal (also my own version) adds a counter each round I even know (provided I play exactly the same – which actually is pretty impossible) after how many “rounds” in the level the crash occured.
I must build a prototype of that tomorrow and add to Vide a “load RAM” feature… :-).
VecFever variant:
Vectorblade_B51.V4E – 12th Mai 2020
Only difference – VecVox removed (still with a big stack).
@Jerome:
Thank you very very much for your extensive play. I know it is very tedious to play one game over and over again.And I am very sorry – if this overplaying is robbing you of the fun Vectorblade should be.
I’ll next remove “VecVox” support.
But sometimes it not only rains – it pours. As of this hour my Eprom programmer is broken – it does not work.
I still have warrenty (5 years) – but I don’t know when I will be able to burn my next flash – who knows the circumstance the warrenty will take.Nonetheless I will make a VecFever version without VecVox soon.
Cheers
Chris
Did you per chance play some more?
I have yet to play myself some more hours. I’d just like to know the relation…played hours : no crash
(or if you encountered a crash)
If you have a life apart from Vectorblade… thats of course Ok too 🙂
Cheers
Chris
These things “should” be emulated correctly. The shadowing is emulated.
Write to ROM can be enabled/disabled in settings. I actualy DO write to ROM – this is used, when accessing the
FLASH Rom
a) initiating writing sequences
b) actually WRITING to the flashBut “chances” are certainly always there…
But there are also some instructions I do not emulate – if Voldemort “uses those” when “hitting” – this might also explain some things.
See: 6x09_Instruction_Sets.pdf (last page – especially the HCF)
The “what is not to be named” watching in Vide is (as stupid as it sounds) more complicated than “easy”.
The thing is I used the “what is not to be named” in game quite frequently for other things – than pure “storing intermediate data”.
AND
Sometimes I explicitly allow the end of the player shots to be overwritten – when I know there are no shots on screen.
(e.g. achievment fireworks…)
I’d have to rule out all those situations…… and there is the small thing, that the actual crash NEVER yet happened while playing in Vide!
The “ever” increasing “what is not to be named” I actually totally rule out. Remember? – First thing in my game round that thing is always reinitated to a fixed base value…
VecFever variant:
Vectorblade_B50.V4E – 9th Mai 2020
Minestorm “resize” fixed.
Alltogether 16 bytes more stack (instead of 6 bonus at the same time on screen, now only 4).
This is a STACK test bin. If the crash does not happen – it’s a stack thing!
(I recently had some “crunching” ideas. I could save about 50 bytes of RAM – so if it IS a stack thing, I have a size solution – but it needs some programming…Also – first changes to the fighter look…
If the crash happens, I will remove Minestorm, if it still happens, I’ll remove the scoopies, if it still happens… I’ll think of something more.
We must somehow circle in on this thing…Cheers
Chris
Hi,
if you are able to provide me a link to the movie I wozkd ike to see it – not only right before the crash, but preferable a large potion of the game leading to it.
Apart from that I will do a version with two less player shots – so there will be 24 byte MORE stack (plenty of reserve).
If that one also crashes – I do not want to hear the word “stack ever again” :-).
I have to do some finishing touches first though…
Vectorblade_B49.bin – 7th Mai 2020
and the same as VecFever variant:
Vectorblade_B49.V4E – 7th Mai 2020
Corrected the Stack “extend” – and additionally freed 5 bytes of stack usage when calling vecVox routines. There just were to many subroutine calls in there anyway.
If you got time… pls do another test round. Thx!
Cheers
Chris
Gee. Again… this was stupid.
PEER!
This was a stack bug. The bug which occurred in BOSS 2!
Last version you asked for a version where the stack was 2 shortened. I forgot to UNSHORTEN the stack.
So at least now we know what can happen :-).The Stack was to short, when the BOSS 2 fired its “words” and those words were put into the VecVox.
VecVox routines are called with a sub routine – so here the STACK was too small. But this crash also only occurs if there are all 10 possible bullets in the air at the same time (which doesn’t happen with autofire) – you have to smash wildly button 4.Anyway… I will fix this soon… and than we can go looking for the REAL bug again :-).
Cheers
Chris
Just played a game on VF. Boss fight two – same thing happened. Probably also a new bug.
Isn’t it wonderful… since I can’t find the old bug, I just insert new once… just for a change…
I’ll be back…
