|
|
Post by Malban on Jul 16, 2024 15:00:53 GMT -5
Hm.
I am a bit dubious about a fix - when no "clean" bug was discovered and it now works because you swapped a few lines.
Certainly a "jsr DP_to_C8" at the wrong position can mix things up and produce errors.
Two ways that can go wrong:
a) There are additional functions that follow and need DP set to D0 - and it is not...
b) If Vide "thinks" the DP is still set to D0 - but in the actual assembler code it points to C8... it then may still generate code that uses direct addressing for accessing VIA Registers - but during execution they actually access RAM locations
Both variants are nearly guaranteed to produce unpredictable behavior.
Your using the "jsr DP_to_C8" shortly before Wait_Recal() might prevent that... but I would feel more comfortable to actually KNOW what went wrong :-).
Cheers
Malban
|
|
|
|
Post by Peer on Jul 16, 2024 15:07:49 GMT -5
... but I would feel more comfortable to actually KNOW what went wrong :-). Hehe, agreed, seems that we both were writing and posting in parallel. |
|
|
|
Post by D-Type on Jul 16, 2024 16:02:58 GMT -5
scotthuggins If you're not already familiar with the VIDE debugger functionality, I suggest learning it. Given one probably spends (guess) 3 times as much time debugging a program than actually writing it, it has the potential to save you a lot of time. For various reasons, I mostly use the MAME debugger, mainly because I'm not writing much Vectrex assembly and it has other specific functionality I use, but when I do need to debug, it's essential.
|
|
|
|
Post by scotthuggins on Jul 16, 2024 16:13:09 GMT -5
I like both your suggestions at being sure the U register is set directly before both the init explosion and the Explosion_Snd() calls happen. I've already put that change in as well - so far, everything's real solid. The game has 20 levels and I can get thru about 10 of them before I lose all my ships. It's been stable so far. I have a RAM breakpoint set in Vide (greatest feature ever!) to let me know when Vec_Rfrsh gets written to. So far, it's stayed solid. I also have a "word watch" set in the debugger for Vec_Rfrsh so I can keep an eye on it that way as well.
If it's real important to know exactly what the deal is.....I can put the code back and send it (in PM) as a .zip file. I do nightly backups on this PC now (lesson learned the hard way!), so restoring it and reproducing it will be pretty easy to do.
Thanks to all the comments so far. Very enlightening.
|
|
|
|
Post by D-Type on Jul 16, 2024 16:44:49 GMT -5
I do nightly backups on this PC now (lesson learned the hard way!)...  OMG, get your code on GitHub and quash the worry. When I finish a coding session, I type: git s (aliased to "status" i.e. look at what files were changed) git dty (aliased to "difftool -y" i.e. look at the changes in details) git au (aliased to "add -u" i.e. add updated files to staging area) git cm "Description of changes" (aliased to "commit -m" i.e. commit staged file to repo with a message) git pom (aliased to "push origin main" i.e. push to GitHub) That's it, done, it takes seconds. Or if you're using VSCode, you can do it with mouse clicks. (I'm not using it for editing, but I do use it as a Git-aware file browser.) Obviously you need to set up the repo first, but the benefits you get by looking at the log and being able to make test branches etc. are the best Ctrl-Z Undo ever! Excellent git intro: youtu.be/ZDR433b0HJY?si=Wov2untf-aFWuQcP |
|
|
|
Post by scotthuggins on Jul 16, 2024 21:36:05 GMT -5
LOL! Github for Vectrex code. Nice! I do like the idea of labeling the versions for easier retrieval of certain features, etc.
|
|
|
|
Post by Peer on Jul 17, 2024 1:58:12 GMT -5
LOL! Github for Vectrex code. Nice! I do like the idea of labeling the versions for easier retrieval of certain features, etc. 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. |
|
|
|
Post by Peer on Jul 17, 2024 2:05:47 GMT -5
... If it's real important to know exactly what the deal is.....I can put the code back and send it (in PM) as a .zip file. I do nightly backups on this PC now (lesson learned the hard way!), so restoring it and reproducing it will be pretty easy to do. I would indeed be interested to know the exact cause of the corruption of Vec_Rfrsh. Especially if it is some flawed(?) using of other BIOS routines that maybe leads to this?
Right now, I do not have the time to do a lot of play-testing. Is there a reproducable testcase that quickly leads to the corrupted situation?
|
|
|
|
Post by D-Type on Jul 17, 2024 2:11:20 GMT -5
If it were on GitHub, Peer (or anyone else if you made it public) could simply "git clone url.git" and "git difftool non-working-hash working-hash" to see the differences that were applied that took it from not-working to working. Indeed, you could actually do all that on GitHub.com without downloading anything. But alas, it's not on GitHub. Oh well.  |
|
|
|
Post by Peer on Jul 17, 2024 2:26:38 GMT -5
If it were on GitHub, Peer (or anyone else if you made it public) could simply "git clone url.git" and "git difftool non-working-hash working-hash" to see the differences that were applied that took it from not-working to working. Indeed, you could actually do all that on GitHub.com without downloading anything. But alas, it's not on GitHub. Oh well. If I understood Scott correctly, then we only know that the symptom disappeared from version X to version X+1 by reordering some lines. But we do not know the exact version X-n when the symptom was observed for the first time, and also not the exact version X-(n+m) that introduced the cause. Correct? |
|
|
|
Post by D-Type on Jul 17, 2024 3:24:32 GMT -5
That's how I read it, but Scott holds the truth.
|
|
|
|
Post by Malban on Jul 17, 2024 4:56:05 GMT -5
I always like to snoop around other peoples code... So yes, I would not mind to tear your code apart :-)!
(Probably not as much as Peer though...)
Malban
|
|
|
|
Post by Peer on Jul 17, 2024 5:55:31 GMT -5
I always like to snoop around other peoples code... So yes, I would not mind to tear your code apart :-)! (Probably not as much as Peer though...) Malban I thought you were completely busy and occupied extending Vide to Hitachi 6309 emulation?  |
|
|
|
Post by Malban on Jul 17, 2024 6:12:46 GMT -5
@peer
Don't know if that will ever happen :-)
But I still have to implement the last thing you reported... you know... the one I have not replied to yet...!
|
|
|
|
Post by Peer on Jul 17, 2024 7:04:59 GMT -5
@peer Don't know if that will ever happen :-) That's fine As I already wrote in the other thread, where D-Type asked about 6309 support in Vide, such a thing is certainly not a mass-market feature, and there are better ways to spend your time with than implementing this. I had some more thoughts on that one. I will send them to you later by email. |
|
OMG, get your code on GitHub and quash the worry.
