|
|
Post by scotthuggins on Jul 17, 2024 22:59:51 GMT -5
Malban, you already have helped me so much with Cavern Rescue, that's why I am trying by "incredible amounts of brute force and determination" to forge my way thru these road blocks. Partly because I am learning more and more by doing so, but mostly because I don't want to overstay my welcome (I don't want to become a burden to you or anyone else).
So two things: Once I did the RAM breakpoint in Vide, it showed the exact line that caused the corruption: jsr Explosion_Snd. Commenting that one line out just to see (I only use it in one place in the code) caused the corruption to stop.
So...wondering if it's really that or how I am using it, I moved the call directly after dp_to_c8() and put both of those called as the final thing before wait_recal is called:
jsr dp_to_c8
ldu #expl_player_ship_snd
jsr Explosion_Snd
jsr Wait_Recal
It could be exactly both of your suggestions, moving the U register population to right before the call to Explosion_Snd that truly did it. Makes sense that if you have garbage in the U register, it might be the cause of it all.
I'll revert it back and share it. Yea, D-Type, I might be getting "cozy" with github after all (I do use regular git with Visual Studio Professional and VS Code at my day job for version control). And a nice idea you had to use VS Code as the front-end for you to do your commits with check-in messages, etc.
It's still working as of now...and I've gotten 4-5 hours of play testing in so far.
Peer, reproducing it is pretty straightforward once I restore the code back to that point. Will take about 58 seconds for it to surface once you begin the game. I will explain how.
|
|
|
|
Post by Peer on Jul 18, 2024 1:08:03 GMT -5
... So...wondering if it's really that or how I am using it, I moved the call directly after dp_to_c8() and put both of those called as the final thing before wait_recal is called: jsr dp_to_c8
ldu #expl_player_ship_snd
jsr Explosion_Snd
jsr Wait_RecalIt could be exactly both of your suggestions, moving the U register population to right before the call to Explosion_Snd that truly did it. Makes sense that if you have garbage in the U register, it might be the cause of it all. ... That looks good. Those are the (minimum) requirements for calling Explosion_Snd(). See "Entry Values" on page 71 auf the Vectrex Programmers Manual Part 2. Or check "ENTRY" for Explosion_Snd() here. You will find such requirements for all BIOS routines in both documents (careful, the latter one contains some minor flaws). It is also worth noting the EXIT conditions of the BIOS routines in those documents, as they show the side-effects of calling them.
It is good that this now works, but...
My personal bane is that I hate and cannot stand not knowing the exact cause of a problem ( Malban can probably sing songs of me pestering him this way). Your reordering of the code removed the "symptom", i.e. the corruption of Vec_Rfrsh. But Vec_Refrsh got corrupted due to a corruption of Vec_Expl_Chans. If Vec_Expl_Chans is corrupted (bit 7 set to 1), then calling Explosion_Snd() will corrupt Vec_Rfrsh. And we still do not know the "cause" for the corruption of Vec_Expl_Chans. That cause might still be hiding somewhere else in the code and might cause some other trouble in some other cornercase situation in the future. |
|
|
|
Post by Malban on Jul 18, 2024 2:30:36 GMT -5
Haha! I again second the notion of Peer - to know what exactly went wrong. IMHO the reordering can not really be the "solution". It might work now - but in the background something else may go awry - which we cannot see yet. Calling of the Explosion function in the order:
SETUP (once)
lda #-1
sta Vec_Expl_Flag
ldu #expl_snd_ply_ship ; point to explosion sound data
jsr DP_to_C8
jsr Explosion_SndLoop ... do "whatever" you want
jsr DP_to_C8
jsr Explosion_Snd
... do "whatever" you want
jmp loop
Regardless of any U-Register or following code... Can not possibly alter the the VecRefreh timing.
The crucial part is "whatever you want". If in the "whatever" part the explosion data is in changed, or different DP values are expected - then things may go wrong.
With your changes of just placing the call to Explosion_Snd at another location - it now seemingly works... But the actual CODE that caused the corruption is still in the "whatever" part. And we just don't know if it is still corrupting other parts of the RAM... which you don't see yet.
---
You are not overstaying your welcome, as you say. I am nearly always willing to help. The exception may be, if people ask really "dumb" question which could be answered by just opening google... and even then I'll help the first few times :-) Or if I recognize, that people are themselves not putting any effort into their "question" and are not willing to learn... then I may also tire...
But that is not you... Remember I "pulled" you (at least you said so) back to your Cavern Rescue...
Hehe... I also need some pulling... to get back to Vectrex more...
Peer is pulling all the time...
You can gladly pull also...
Debugging strange behaviour... it is not really "work" or something I must be forced to... it is more "Oh there is a riddle to solve... let's tackle it..."
Haha - Peer can relate to that too...
Cheers Malban
|
|
|
|
Post by D-Type on Jul 18, 2024 3:22:22 GMT -5
A key to this could be ensuring your calls to BIOS/RUM functions don't corrupt memory or registers. Using the stack to preserve registers is a good way of doing this, but needs care if the called routine modifies the stack contents (luckily there are two stacks available!). The stack effects of all the BIOS & RUM routines are documented, but do differ in places, so I created a cross-reference/easy look up of the routines in an Excel spreadsheet that might be of some use: github.com/phillipeaton/VecForth/blob/master/VecForth/Vectrex/Reference/RUM%20BIOS%20Cross%20Reference.xlsxBTW, there are some errors in the stack effects details, in the Bruce Tomlin ROM documentation, I fixed them in my cross-ref document. |
|
|
|
Post by Peer on Jul 18, 2024 5:40:29 GMT -5
... Peer is pulling all the time... It is not (just) me. We all know that the Vectrex is a singularity. You are feeling its gravitational pull. And we both have travelled beyond the event horizon, so it is impossible to ever get out. Better accept it  Oh yes, it is impossible to resist a good puzzle... |
|
|
|
Post by Peer on Jul 18, 2024 5:43:06 GMT -5
... BTW, there are some errors in the stack effects details, in the Bruce Tomlin ROM documentation, I fixed them in my cross-ref document. There are additional errors, inaccuracies and flaws in that documentation. I will check out your cross-ref and compare it to my annotated BIOS listing (wip). |
|
|
|
Post by Peer on Jul 19, 2024 4:59:32 GMT -5
@ scotthuggins , @ Malban : I think I know what is likely happening here, and why Vec_Expl_Chans got corrupted. I do not have Scott's code though, so this is just a theory.
Vec_Expl_Chans (0xc854) is also the low-byte of the two-byte Vec_Music_Ptr (0xc853). If you use bios tunes AND bios explosions, then you must assure that Vec_Music_Flag and Vec_Expl_Flag are always mutually exclusive (never both set at the same time). The bios routines cannot play tune and explosions in parallel. The respective routines share the same working-buffer piece of RAM (overlaid memory-mapping), but use the cells each to their own purpose.
Vec_Music_Ptr is set by the Init_Music_xxx routines(), and Vec_Expl_Chans by Explosion_Snd(). Each routine screws up the buffer data for the other.
So, if you want to use both bios tunes and bios explosions, then, if you want to start a tune, disable Vec_Expl_Flag and enable Vec_Music_Flag. If you want to start an explosion, disable Vec_Music_Flag and enable Vec_Expl_Flag. Thus, starting a new tune stops a potentially present explosion sound, and starting a new explosion stops a potentially present tune.
I hypothyze that the reordering of the code by mere chance prevented both flags from being set at the same time for this case, but there might still be other situations where this can still happen.
So, are you using both bios explosions and tunes?
|
|
|
|
Post by scotthuggins on Jul 19, 2024 9:57:51 GMT -5
.....so I'm still having issues with explosion_snd(). And I'm thinking of reorganizing the sound part of this new game. Any reason not to do things this way?
.
.
.
; process all currently "queued up" sounds
jsr DP_to_C8
ldu #expl_player_ship_snd
jsr Explosion_snd()
ldu #background_snd
jsr Do_Sound
jsr do_ym_sound
-- OTHER SOUNDS --
jsr DP_to_D0
jsr Wait_Recal
.
.
.
; queue up a new sound
lda #-1
sta Vec_Expl_Flag
ldu #expl_snd_ply_ship ; point to explosion sound data
jsr DP_to_C8
jsr Explosion_Snd
jsr DP_to_D0
.
.
.
The reason I'm thinking of putting ALL sound processing together is so that I can do one single DP_to_C8, process each sound that is queued up already, and then only do ONE jsr DP_to_D0 and be done with it all....then back to normal game logic and drawing vectors, etc.
And in the second block above, when we queue up a sound (ie: start up a new sound), wrap that around jsr dp_to_c8 followed by a dp_to_d0. Might not be very efficient to do it that way, extra cycles for dp_to_c8 and then dp_to_d0.... but if that ensures the sounds are properly initialized and then processed, this approach might be necessary?
|
|
|
|
Post by Malban on Jul 19, 2024 10:34:30 GMT -5
I am confused.
1) Are you saying you still HAVE issues - as in you experience issues?
Or
2)
Are you answering Peer and saying... that because of what he said you think you still have issues?
As to answer Peers last comment - from the snippets above - I will dare to say, that Scott does NOT use BIOS functions to play music - and that these then also do not interfere with the Explosion_Snd() - and can not have caused the corruption.
The "disruptive Code" - is still somewhere in the code... and we have not tackled that yet at all...
---
That being said - apart from the fact the the game loop is a "cycle" as Peer mentioned... it is worth noting, that the
Explosion_Snd()
and
do_ym_sound() (If I remember correctly)
Both copy sound data to the shadow registers in Vectrex RAM
and the Do_Sound() - actually puts these to the sound chip.
Therefore a "correct" order would always be to do "Do_Sound()" last.
The order of Explosion_Snd() and do_ym_sound() sets the priority between explosions and the music...
The last one "wins" - in your case as I see it... the Explosion_Snd() wins...
|
|
|
|
Post by Peer on Jul 19, 2024 11:07:27 GMT -5
Ceterum censeo, coleopteram esse delendam!
I concur with Malban . Stop trying to randomly cure the symptoms, and instead identify the root cause of the problem.
I suggest that you:
1. Go back to that initial version in which Vec_Rfrsh first got corrupted. 2. Use the RAM breakpoint to get to that very moment, when this happens. 3. Check if the code which is executed in this moment is indeed (that last part of ) Explosion_Snd. This is the only part of the BIOS code which can corrupt Vec_Rfrsh.
4. Check the current value of Vec_Expl_Chans. Is either of the two most-significant bits set?
That would confirm our theory about Vec_Expl_Chans.
5. Use the same RAM breakpoint technique to identify the moment when some code writes to Vec_Expl_Chans. The only part of the BIOS that intentionally writes to Vec_Expl_Chans is Explosion_Snd, but that routine assures that the top 5 bits are always zero. So continue until you find some other code that writes to Vec_Expl_Chans. And that should be the culprit.
|
|
|
|
Post by Peer on Jul 19, 2024 12:08:06 GMT -5
... Any reason not to do things this way? Four reasons a) The "ldu #background_snd" right before "jsr Do_Sound" is pointless, because the u-register is overwritten and used by Do_Sound(). I do not know, if u is required for do_ym_sound? In that case it must be set after calling Do_Sound.
b) Do_Sound requires dp to be set to 0xD0! The above snippet definitely should not work, as dp is still 0xC8 here. c) The "jsr DP_to_D0" right before "jsr Wait_Recal" is redundant, because one of the first things Wait_Recal() does is calling DP_to_D0(). d) The "ldu #expl_player_ship_snd" before the first "jsr Explosion_Snd" might or might not be used by Explosion_Snd, depending on the value of Vec_Expl_Flag at this point. What is the point of using u here? Your comment says "queue up a new sound". There is no true queuing implemented here.
But again, I would recommend to rather proceed as suggested in my previous post.
|
|
|
|
Post by scotthuggins on Jul 19, 2024 21:16:54 GMT -5
>I am confused.
>1) Are you saying you still HAVE issues - as in you experience issues?
I'm saying explosion_snd() is causing problems still. As in, it was never fixed with me moving the code around...as you both warned me, it just took time and different actions during gameplay to get the issues to happen.
Alright, I'm gonna try to follow the suggestions and find the root cause of this. It'll likely take time, but I will do it. No more posts until I know more specifics.
Thanks again for helping steer me in the right direction.
|
|
|
|
Post by Peer on Jul 20, 2024 6:51:47 GMT -5
... Alright, I'm gonna try to follow the suggestions and find the root cause of this. It'll likely take time, but I will do it. No more posts until I know more specifics. Thanks again for helping steer me in the right direction. You are very welcome. Good luck for the bughunt, and good progress to your game! Please keep posting, as there is always something new and interesting to learn for all of us in these discussions. Also, it is great to keep these forums alive. |
|
|
|
Post by gtoal on Jul 24, 2024 3:01:17 GMT -5
When the students enter my programming class, they already know about Github and have already used it (and also continue using it throughout the course). We always do a fun session, talking about how software development and Vectrex development was done back in 1982, and they have to come up with ideas how to organize and do backups and version control without using modern Github or the like. That is always a very creative session. Actually we had rcs in 1982 and sccs before that. Personally I've not found any good reason to switch away from rcs since. G |
|
|
|
Post by D-Type on Jul 24, 2024 17:52:10 GMT -5
Actually we had rcs in 1982 and sccs before that. Personally I've not found any good reason to switch away from rcs since. G Git is a sledgehammer to crack a nut for personal use, but the benefits of it being distributed (push to GitHub every session and your backups are sorted), the integrated client editor tools (e.g. VSCode) for viewing the repo and that you can give anyone a URL to your code so they can see/get the code history themselves, are benefits that make it worth it on their own. Distributed source control is a completely different approach to sccs/rcs/cvs etc. If you have an hour to spend, maybe watch Linus tell you why it's so good. (Well he would, wouldn't he.) |
|
