Galaga Crashing All the Time

[65Gamerguy]

A question if I may. I understand that there have been some issues with this game, so forgive me if I am not clear on everything. I have attempted to order Galaga twice through the web site and have only received a notice saying that I will be contacted at a later date. I have no problem with waiting I just wanted to check and see if this game is, or will still be, available in the future.

 

Many Thanks for any info you can provide me with.

[coleco_master]

A question if I may. I understand that there have been some issues with this game, so forgive me if I am not clear on everything. I have attempted to order Galaga twice through the web site and have only received a notice saying that I will be contacted at a later date. I have no problem with waiting I just wanted to check and see if this game is, or will still be, available in the future.

 

Many Thanks for any info you can provide me with.

 

PM sent

[iesposta]

Please, someone with a direct like to Toby please tell Toby (and Collectorvision) that I do have the REV A Galaga.

Sorry for thinking and insisting I never got it mailed back.

 

I remember mailing it, but I truly don't remember getting it back, but there it is in my cartridge organizer!

(I had pretty bad "holiday depression" for the first time.)

[coleco_master]

Please, someone with a direct like to Toby please tell Toby (and Collectorvision) that I do have the REV A Galaga.

Sorry for thinking and insisting I never got it mailed back.

 

I remember mailing it, but I truly don't remember getting it back, but there it is in my cartridge organizer!

(I had pretty bad "holiday depression" for the first time.)

Don't worry Micheal.... Mistake can Happen. As long as you found it ... Now enjoy the game

[parkfun101]

Hey guys, from my experience with the dreaded nmi issue that Colecovision has, it is easily reproducible if you know how nmi works. Tank Challenge and Light Cycle Racing that I'm currently working on during testing both had the nmi issues just displaying the level graphics. I could start a level 10 times and randomly about 1-3 times out of 10, some of the wall graphics would be missing. After I implemented the fix for this, I could run it 300 out of 300 times and never get the issue. The code fix I used was this:

 

disable_nmi();

delay(1);

//draw your graphics here

//do your vram stuff here

enable_nmi();

 

These issues can be hard to test in certain situations. In some cases, the developer has to alter their code just to be able to test for the bug if they know where it could be occurring. Let's say in Galaga, that the bug occurs when your ship gets captured (for example). In order for the developer to know for sure if this is the problem area of the game, they might have to code the game to start up and immediately capture your ship. Then, they would have to restart the game about 100+ times just to make absolutely certain that it is indeed the cause of the bug. This is what I've had to do for my games. Sometimes, I would run it 100 times and only see the bug 6 times.

If you report a bug for any game, make certain you let the developer know what level you were on, where you were on the screen, what you were doing with the controller, etc, etc,. The more info you can provide, the quicker the fix can be implemented. For a programmer, if they can figure out how to "BREAK" the program, then they can easily fix it. Knowing is half the battle! Yo Joe!

[+5-11under]

Does the delay inside the NMI slow things down?

[Kiwi]

Delay just wait for the screen to finish drawing. Pause and delay command doesn't work in nmi(). Stuff in nmi() starts upon new frame, then it'll process the code in the non nmi(). I put the controls in nmi() in Spunky's Supercar so it'll work at 60 fps and doesn't lag when there's many objects on screen. It'll work while disable_nmi since I disable the nmi when it is drawing tons of put_frame stuff, which takes a few frames to process. That was back when I was still new to Colecovision programming.

 

I usually don't put stuff in nmi(), unless I need something working while I'm on pause() statement. It's like a dual processor. My structure is

while(game=1){
paper(2); Changes border back to green, the gray tells you how much of your code have been process. and the green tells you how much z80 cycles you have left on this frame. I believe both the z80 and the vpd run the same speed.  
delay(1);
paper(14); Debug processor trick give VRAM command to change border to gray
updatesprites(0,64); 
small vram update, like updating HUD and stuff.
Then the code that the z80 can do without touching the video chip.
}

[youki]

disable_nmi();

delay(1);

//draw your graphics here

//do your vram stuff here

enable_nmi();

 

 

Hum.. are you sure it works?.. because i thought delay command need the nmi enabled to work.

 

 

My technic to avoid nmi issue is , now, kind of the opposite of kiwi 's one.

 

I try to put all that access to VRAM in the nmi routine. I just make in sort that i do can be done before the next one occurs.

 

and for all that i did not manage to put here , then it depends i use also the delay(1) technics or a nmi detection flag.

[parkfun101]

disable_nmi();

delay(1);

//draw your graphics here

//do your vram stuff here

enable_nmi();

Well, during testing when I was having the glitch about 3 out of every 10 times, I added the code above. After that, I could run it 300+ times and never get the graphic glitches. I had tried it without the delay and it would seem to still have the problem.

 

Putting the access to VRAM in the nmi routine is also a solution from what I have heard. I guess in that case, you would just set a flag to run your code that is in VRAM.

 

I think I may make a couple complete code examples that show both with and without the nmi fix so people can use them for future reference. I have some code already that I used for creating levels for Tank Challenge that I can post.

[Pixelboy]

I had similar problems with Jewel Panic recently, and I fixed them by putting disable/enable_nmi calls around all functions that interact with VRAM. The reason why this is necessary is because an NMI may happen right in the middle of a function doing a VRAM read or write operation, and if the NMI function itself calls any VRAM-related functions, then this leaves VRAM in an uncertain state where the interrupted function is concerned. This is usually the source of NMI-related graphic glitches.

 

I'm currently trying to develop a way to render VRAM functions "NMI-safe" for BasicVision. One idea I've had is to allocate space in RAM for a couple of flags. The first flag will be set whenever a VRAM-related function is called in the BasicVision library, and when a screen NMI occurs, the called NMI function will check this flag before doing anything else. If it's set to 0, then the NMI function will perform its duties immediately. If the flag is set to 1, it will postpone its execution and set another flag to 1 before returning control to the main program. All VRAM-related library functions will check this second flag, and call the NMI function themselves if the second flag is set to 1 before exiting. This "NMI delay" system will ensure that VRAM is not accessed in a disorderly way. There may be some technical problems with this solution which will need to be addressed, but I think it's a pretty good solution, and best of all, the BasicVision programmer won't need to worry about these NMI issues.

[parkfun101]

youki, after some testing, it seems there are times you don't need the delay(1) or even the disable_nmi() or enable_nmi(). I did some tests just now and if you use the screen_off() and screen_on() those other functions may not be needed.

[parkfun101]

Awesome Pixelboy! I was also thinking of making functions that fix this issue, but it sounds like you've already put a lot of work into the fix! :thumbsup:

[Pixelboy]

A lot of work? Not really, I haven't really begun working on BasicVision. It's just an idea so far.

 

And by the way, screen_on() and screen_off() are not good for handling NMI stuff. I've tried it before myself: screen_off() shuts off the VDP, which means a totally black screen. If you use screen_off() and screen_on() repeatedly, you'll get a display that alternates between a black screen and a non-black screen, which I'm sure is not what a programmer wants. screen_off/screen_on should be reserved for large VRAM updates during which a black screen is acceptable, like loading a complex title screen in VRAM after turning on or resetting the console.

[+5-11under]

Anyone ever have a problem where some of the character data is overwritten with sprite data when it's not supposed to? I am using the standard getput1 commands for sprites and characters. For updating the sprite I am using "update_sprites(1,0x1B00);" .

 

[youki]

I had similar problems with Jewel Panic recently, and I fixed them by putting disable/enable_nmi calls around all functions that interact with VRAM. The reason why this is necessary is because an NMI may happen right in the middle of a function doing a VRAM read or write operation, and if the NMI function itself calls any VRAM-related functions, then this leaves VRAM in an uncertain state where the interrupted function is concerned. This is usually the source of NMI-related graphic glitches.

 

 

 

But there is something to keep in mind. Even if you called disable_nmi you can still have the issue and glitches.

 

Because , correct me if i'm wrong , but the disable_nmi only disable the interrupt handler from Daniel 's libraries. so in clear, it just mean that the nmi() function won't be called. But it does not prevent the real NMI to occurs. the NMI is by definition NOT MASKABLE. On colecovision you can do all what you want ,you will have the interrupt triggered. and if it occurs when VRAM is accessed you can have glitches....

 

So all the methods , like Delay(1) or set some flags ...etc...etc... are never a perfect solution.

[Pixelboy]

But there is something to keep in mind. Even if you called disable_nmi you can still have the issue and glitches.

 

Because , correct me if i'm wrong , but the disable_nmi only disable the interrupt handler from Daniel 's libraries. so in clear, it just mean that the nmi() function won't be called. But it does not prevent the real NMI to occurs. the NMI is by definition NOT MASKABLE. On colecovision you can do all what you want ,you will have the interrupt triggered. and if it occurs when VRAM is accessed you can have glitches....

 

So all the methods , like Delay(1) or set some flags ...etc...etc... are never a perfect solution.

The "real" NMI cannot be prevented, as you say, but it's up to the programmer to decide which function is called when the NMI happens (in assembly language, I mean). With the Coleco libraries in C language, part of the NMI processing is done in the background, so to speak, and the programmer has no control over that hidden part. That's the real problem, I would say, and I'll try to fix that with my flag system when I get around to programming the BasicVision compiler. Of course, I won't know if my flag system works properly until I've tested it.

[Pixelboy]

Anyone ever have a problem where some of the character data is overwritten with sprite data when it's not supposed to? I am using the standard getput1 commands for sprites and characters. For updating the sprite I am using "update_sprites(1,0x1B00);" .

Does your software have any interactions with VRAM within the nmi() function (or some sub-function called from nmi())?

[+5-11under]

Does your software have any interactions with VRAM within the nmi() function (or some sub-function called from nmi())?

 

Not this game. It only has an update_sound command within the nmi.

[Pixelboy]

Not this game. It only has an update_sound command within the nmi.

Hmmm... Strange... Have you tried wrapping your getput1 calls in disable_nmi() and enable_nmi() calls, just to see if it fixes the problem?

[+5-11under]

Hmmm... Strange... Have you tried wrapping your getput1 calls in disable_nmi() and enable_nmi() calls, just to see if it fixes the problem?

 

Yes, I've done that. I've combed through all the code ensuring that. Note that I'm not really getting the type of glitch where just a few items on the screen get messed up (temporarily, until re-written).

 

What is happening is that the actual character set is being re-written permanently. It happens in BlueMSX and on a real ColecoVision. The blue car should look like the pink car, just in the opposite direction. You can see some of the characters (numbers 15-18... 15 is blank, 16 is blank, 17 looks like part of the sprite, 18 I don't recognize). The last I recall, it sometimes happens to other characters also. The only way to get the proper characters back is to reload them, which usually only happens at the set-up stage of the program (at the beginning).

 

 

Here's a few small portions of the code:

#include <coleco.h>
#include <getput1.h>

extern byte PATTERN1[];
extern byte PATTERN2[];

extern byte SPATTERN0[];
extern byte SPATTERN1[];

screen_mode_2_text();

change_pattern(0,PATTERN1,128);
change_pattern(128,PATTERN2,128);
for(aa=0;aa<256;aa++) {change_multicolor(aa,COLOR1+aa*;}

change_spattern(0,SPATTERN0,4);
sprites[0].pattern = 0;
sprites[0].y = ygrid*24+56;
update_sprites(1,0x1B00);

Edit: maybe I need to manually set up the locations of the character and sprite data in VRAM somehow?

Edited February 16, 2015 by 5-11under

[Pixelboy]

There's a note in Daniel Bienvenu's C programming guide, on page 43:

 

Note: If you use Getput-1 library and you don't know well how to use update_sprites, you must use updatesprites.

So there are two sprite update functions, one with the underscore and one without. Perhaps you're using the wrong one?

[+5-11under]

There's a note in Daniel Bienvenu's C programming guide, on page 43:

 

 

So there are two sprite update functions, one with the underscore and one without. Perhaps you're using the wrong one?

 

I just tried that (again?) and it still fails. I sometimes change the sprite (pointing arrow) from solid to hollow (and back)... I'll try it without changing it, and see if that works.

[Pixelboy]

Could you snap a full picture of the screen with blueMSX? It might help in narrowing down the problem.

[+5-11under]

Could you snap a full picture of the screen with blueMSX? It might help in narrowing down the problem.

 

You've seen enough. PM en route.

 

Anyway, I think it's fixed, at least based on playing it for 5 minutes...

 

Usually I have all the key gameplay code within the nmi. This game isn't an action game, so I decided not to do that. What I did do in several locations was to update the sprites (after any change). I moved the update sprites command to the nmi, deleted all the other ones, and it seems to be working.

[Pixelboy]

Cool, glad to be of (some) help.