|
|
Post by Peer on Feb 3, 2023 13:23:16 GMT -5
And even more digital archeology...
In a more general discussion of Vectrex wobble and flicker (see here), Malban mentioned that several of the original GCE games deliberately set the refresh timer to a value other than 50Hz. One of those games is Bedlam, running at ~30Hz, which results in a noticeable flicker on real consoles. I became interested in why that specific framerate was chosen in Bedlam. Especially, because in comparison to other games, there are not that many things drawn on the screen. So why such a low framerate?
I ended up with a complete disassembly of the cartridge and an in-depth analysis of the code. The details can be found here:
Many Cheers, Peer
|
|
|
|
Post by VectorX on Feb 3, 2023 14:46:26 GMT -5
Especially, because in comparison to other games, there are not that many things drawn on the screen. So why such a low framerate? I'm not a tech person, nor a programmer, but as a guess maybe it has something to do with the later levels when they start pulsating and rotating? |
|
|
|
Post by limitzer0 on Feb 3, 2023 22:47:51 GMT -5
And even more digital archeology...
In a more general discussion of Vectrex wobble and flicker (see here), Malban mentioned that several of the original GCE games deliberately set the refresh timer to a value other than 50Hz. One of those games is Bedlam, running at ~30Hz, which results in a noticeable flicker on real consoles. I became interested in why that specific framerate was chosen in Bedlam. Especially, because in comparison to other games, there are not that many things drawn on the screen. So why such a low framerate?
I ended up with a complete disassembly of the cartridge and an in-depth analysis of the code. The details can be found here:
Many Cheers, Peer
Wow, great research. I didn't realize the original games were not set for 50 Hz. Like you said in your first theory, I would guess it was their way of tweaking the speed. Great job on the 50hz version as well. It is a great training exercise. I'm really enjoying your deep dives into the code lately. |
|
|
|
Post by kokovec on Feb 4, 2023 14:05:41 GMT -5
Bedlam is one of my favorite games on the Vectrex. This is an amazing analysis of the code. I truly enjoyed reading it. The fixed version runs too fast for my tired brain and old hands  |
|
|
|
Post by Peer on Feb 12, 2023 5:23:15 GMT -5
Fun fact:
Hyperchase uses the very same explosion effect as Bedlam. Just check it out, try Bedlam, then try Hyperchase. It is not just the same effect, but also the very same code that is used in both games. So there was definitely some code sharing between the programmers at WT. I am pretty sure that the same code is also used in Cosmic Chasm, and Rip Off, and maybe even more games. I did not check the code itself, but only did a quick visual comparison.
You can find further details about Hyperchase here:
Many Cheers, Peer
|
|
|
|
Post by Chainsaw on Feb 12, 2023 7:29:56 GMT -5
Wow, also thanks for this great analysis.
Text in the analysis: "I never noticed that until I saw it in the code. As long as the zap weapon is still available, there is a small dot drawn inside the cannon."
-> I also never noticed that.
Text in the analysis: "The small life-icons are actually drawn at different scales (4,3,2), depending on how many lifes are left (3,2,1). However, at such tiny scales, this goes (almost) unnoticed, and I wonder, if this was intended, as the corresponding part of code is unnecessarily complicated and also contains redundant instructions."
-> Maybe I missed this in the text (I just read it fast now - will read it again later) but is this point with drawing the life-icons at different scales possibly the result of a very very annoying bug? At least I have this bug in my European version, and also noticed it in other versions during Vector War some years ago.
The bug that I mean is: If you collect 6 or more lifes, the game starts to slow down and starts stuttering. Also not every keystroke is accepted anymore (fire or ZAP) and the game is nearly unplayable. Also ZAP doesn't kill anymore every enemies on the screen, but only a few of them during this problem. After loosing some lifes, and having only 5 lifes left, the game is working normal again. Maybe the bigger rendering of the life-icons is doing this problem? Or if you have 7 or more lifes, only 6 are shown totally, but maybe the program code is doing strange things then what is slowing down the speed of the game? Sorry, it is difficult to explain for me, but I think everybody knows this slowdown bug / problem, after having 6 life or more?
Didn't test yet, if your 50Hz version is working without this problem.
|
|
|
|
Post by Peer on Feb 12, 2023 9:38:40 GMT -5
... -> Maybe I missed this in the text (I just read it fast now - will read it again later) but is this point with drawing the life-icons at different scales possibly the result of a very very annoying bug? At least I have this bug in my European version, and also noticed it in other versions during Vector War some years ago. The bug that I mean is: If you collect 6 or more lifes, the game starts to slow down and starts stuttering. Also not every keystroke is accepted anymore (fire or ZAP) and the game is nearly unplayable. Also ZAP doesn't kill anymore every enemies on the screen, but only a few of them during this problem. After loosing some lifes, and having only 5 lifes left, the game is working normal again. Maybe the bigger rendering of the life-icons is doing this problem? Or if you have 7 or more lifes, only 6 are shown totally, but maybe the program code is doing strange things then what is slowing down the speed of the game? Sorry, it is difficult to explain for me, but I think everybody knows this slowdown bug / problem, after having 6 life or more? I did a quick test by patching the binary to start out with 8 lifes right from the beginning (no other patches active). The game behaves absolutely fine. The 8 life icons are drawn in a larger scale (I can send you a screenshot if you like), but other than that everything is just the same as when starting out with the regular 3 lifes.
I have not yet experienced the bug you described myself, but to me it seems that this could rather be related to the higher level/speed/difficulty/score at that point, when you achieve the 6 lifes. Do you possibly know such details?
I do not have the time right know, but later I will try a god-mode patch with collision detection disabled, and then play until obtaining 6 lifes. Maybe that will give some more insight.
Many Cheers, Peer
|
|
|
|
Post by Chainsaw on Feb 12, 2023 13:29:32 GMT -5
I'm not sure, if I play normal (without any extreme highscore chase) I think I reach 6 lifes in level 2 or level 3 but not alrady in level 1. Normally I start directly in level 3. Also I don't have time to test this at the moment, maybe sometimes next week. But I know, my version of Bedlam is only drawing up to 6 lifes at once, even if I have 7 or more lifes, it is only drawing 6 lifes on the screen. But I also have the effect, that the lifes are drawn larger, the more I have.
PS: I have no good camera or stative for the smartphone, but maybe I will try do record a video of the issue.
|
|
|
|
Post by Peer on Feb 13, 2023 2:27:23 GMT -5
I'm not sure, if I play normal (without any extreme highscore chase) I think I reach 6 lifes in level 2 or level 3 but not alrady in level 1. Normally I start directly in level 3. Also I don't have time to test this at the moment, maybe sometimes next week. But I know, my version of Bedlam is only drawing up to 6 lifes at once, even if I have 7 or more lifes, it is only drawing 6 lifes on the screen. But I also have the effect, that the lifes are drawn larger, the more I have. PS: I have no good camera or stative for the smartphone, but maybe I will try do record a video of the issue.
I have read a bit about this bug on the internet, and I think I know what is going on here. I did not yet find the time to confirm this in the code or by experiments, so this is to some degree based on speculation, but I am pretty sure that the explanation lies in the interrupt scheme which is used in the code and which I have described in my analysis.
The code uses a main loop, and an interrupt handler which does all the rendering and drawing. If the execution of the interrupt handler routine takes too much time, then it will interrupt itself. I stumbled across this in my very first Bedlam experiment. I simply forced the value of the refresh timer (which triggers the interrupt) to the standard 50Hz / 30.000 cycles. This way too short for the interrupt handler (as implemented) to finish. The result was that the game halted after a few seconds. The graphics were still being drawn, but nothing else happened. This was bit lucky. The interrupt occurred inside the interrupt handler "in a good place", meaning not causing a crash.
The same situation can happen also with the original refresh timer value (30Hz, ~50.000 cycles), if the interrupt handler routine takes more than 50.000 cycles. In the higher levels, the on-the-fly computations of the rotations of the playfield consume a lot of cycles, but the total amount is still slightly below the 50.000 threshold. The drawing of each life icon consumes some additional number of cycles. If now the number of life icons becomes too large, then this can tip the scales, and the interrupt handler starts interrupting itself. Since the total amount of cycles to some degree varies from frame to frame, this will cause some sort of stuttering, if the number of cycles oscillates around the threshold, sometimes being still below it, and sometimes exceeding it.
So, this phenomenon should not happen in the 50hz version I created, as that one does not use an interrupt scheme. But it will definitely be harder to get that far in the game, due to the increased speed. I will try to check while playing in god-mode.
A fix of the original code could be to either make the interrupt handler interrupt-safe, so that it cannot interrupt itself (best), or to put a maximum on the number of life icons being displayed (not so good, as the problem can still occur if other things take up too many cycles). I will give this a try, once I find the time.
You pm me your email address, or send it to my vectrex university address (see project web page), and I can send you some patched binaries, so that you can play around with them, if you like.
Many Cheers,
Peer
|
|
|
|
Post by Chainsaw on Feb 13, 2023 16:25:32 GMT -5
I also tried now the 50Hz version of Bedlam. Also here it's amazing, how the screen flicker is reduced. But... It is way too fast now for me. Anyway, also it's intersting to hear the alternative melody and sounds that were not used in the original. After reading the analysis text again, it's also intersting about other unused RAM areas, the 7 character string for the level, or this counter in steps of 10. Maybe there were other game features planned and not done, or they were removed from the final game. Who knows...
About the bug with slow downs with more than 6 lifes: Was not able to reproduce this with the 50Hz version, the game is too fast to collect 6 lifes or more. Or at least it's not possible without a lot of practise of the 50Hz version. But yes, it is exactly looking / behaving like interrupt problems.
Also: Could this be the reason, that not more than 6 life icons are shown / drawn on the screen, even if I have 7 or 8 lifes? So that the game wants to draw 7 or 8 life icons, but the interrupt is stopped or "interrupted" too early? Or is the game code is only drawing 6 icons at all, and the game is running into another problem when I have more then 6 lifes? Ahhh or was it 7 lifes? Have to try this again...
Yes, will contact you later if you have some patched binaries to test / play around. Otherwise a good patch would be intersting also for the whole Vectrex community. (But you don't have to do this, if you don't want - I just gave my comment and my ideas.)
|
|
|
|
Post by Peer on Feb 14, 2023 2:39:05 GMT -5
I was able to reproduce the bug you described, and it is indeed caused by the interrupt handler scheme, once the cycle count per frame exceeds the 30Hz limit. I had to go to some length in order to trigger this (god-mode, 9 life icons, level text artificially printed twice, and the level forced to 5+), so there must be many things going on at the same time, which eat up a lot of cycles, for this to happen. It is not specifically related to the life icons, just to the overall number of cycles need per frame. 9 life icons displayed fine in my experiments. I found another bug described on the internet, the zapper sometimes being not effective or not killing all enemies. This is also caused by the very same situation as above. The interrupt handler again is the bad guy, interrupting the code which handles the zapper stuff. I played with unlimited zappers to test this, fun!  The only way I found to fix this was to completely remove the interrupt scheme. Making the code sections interrupt-safe worked only when I made them all interrupt-safe, meaning, always keep the interrupts disabled, except for the cwai instruction only. Which puts using interrupts at all ad absurdum. So, the 50Hz version indeed fixes these bugs, and I can easily create a fixed 30Hz version in the same way, if there is interest. In general, I am happy to provide any patches asked for. Just let me know which combinations (framerate, alternate melody / sounds) are desired.
Many Cheers, Peer
|
|
|
|
Post by Chainsaw on Feb 15, 2023 12:51:51 GMT -5
Thanks for these very interesting information and testings about this bug. Yes, I think I also only got it in level 3 or higher (levels with rotation) and 100% I got it only with 6 or more lifes. This with the zapper yes, I also experienced.
Oh wow, a version with unlimited zappers sounds funny, but then you will need a lot of coffee. Just sitting in front of your Vectrex and easy pressing the button 2 without stress to eliminate the enemies... What's next? An automatic Zap function, and you need only button 2 anymore to turn on or turn off the automatic-every-second-zapper.
Also here, yes, I would be interested in a bug fixed version, but the normal "30Hz version". Not for the 50Hz mode, I think I will not run into the problem there, to collect so many lifes, that this error will occur.
|
|
|
|
Post by Peer on Feb 16, 2023 4:03:15 GMT -5
Thanks for these very interesting information and testings about this bug. Yes, I think I also only got it in level 3 or higher (levels with rotation) and 100% I got it only with 6 or more lifes. This with the zapper yes, I also experienced. Oh wow, a version with unlimited zappers sounds funny, but then you will need a lot of coffee. Just sitting in front of your Vectrex and easy pressing the button 2 without stress to eliminate the enemies... What's next? An automatic Zap function, and you need only button 2 anymore to turn on or turn off the automatic-every-second-zapper. Also here, yes, I would be interested in a bug fixed version, but the normal "30Hz version". Not for the 50Hz mode, I think I will not run into the problem there, to collect so many lifes, that this error will occur. The unlimited zapper feature was just convenient to quickly advance in the game for testing purposes. Of course it completely takes any challenge out of the game. But the 50Hz version becomes much more playable if zappers can be saved and accumulated (get one new zapper per stage, do not use the zapper in one stage, and then have 2 zappers available in the next stage, and so on).
I have sent you the patched 30Hz version you asked for by email for testing. Let me know if this truly fixes the stuttering-bug and the zapper-bug. If so, I will happily make that version available for everyone.
Many Cheers, Peer
|
|
