Jump to content
Nukey Shay

Missile Command Arcade

Recommended Posts

This hack provides 3 launchers. Both players share left stick to move, and left/down/right on the right stick to fire (trackball+Starplex button controller should make a good combo). The left stick fire button will pause the game at any point. Includes NTSC/PAL switching via the B&W switch (w/7800 autodetect), and is Supercharger-compatable.

Full list of changes listed in the assembly file :)

 

 

Buglist:

When beginning a 2-player game, "PLAYER2" will flash momentarily before it changes to "PLAYER1".

When pausing the game, the onscreen enemy missiles might be shown at incorrect positions. This will correct itself when the game is unpaused. Any current sound being played might also loop endlessly while the game is paused.

The left and right launchers have slightly glitched "hilltops". This is due to the same value being reused from the center hilltop. No cycles free in that loop, so unable to correct at this time :(

 

Edit: click here for latest version.

Missile_Command_arcade.zip

Edited by Nukey Shay
  • Like 1

Share this post


Link to post
Share on other sites

I got a few questions, how come the colors don't change with you advance to a harder level and are you going to add bombers and satelites to this hack?

Share this post


Link to post
Share on other sites

WOW! Very cool!

 

Would it be possible to make the turrets on the left and right side fire slower than the turret in the middle? That is how the real arcade game functions and adds to the overall strategy of turret choice when firing.

Share this post


Link to post
Share on other sites
I got a few questions, how come the colors don't change with you advance to a harder level and are you going to add bombers and satelites to this hack?

880931[/snapback]

 

Satellites wouldn't be possible I don't think, since there's no spare player sprite available. A somewhat-goofy-looking bomber plane might be possible using the ball (if the cursor doesn't) but even that would probably require a kernel rewrite.

Share this post


Link to post
Share on other sites

Really impressive hack here! These are exactly the kinds of hacks I like to see - to improve games that were slightly disappointing to me back in the day because features were left out. Missile command was fun, but I was a little bothered about the things left out of the game.

 

I've looked at the disassembly a little bit, and I could be wrong, but I think that satellites and planes are possible with some tradeoffs. The explosions use P1 only with 20 Hz flicker, the missiles use M0 only, so P0 is available.

 

The plane/satellite would have to be the same color as the missiles, and it can only be present when only using single copies of M0 or else there will be 2-3 planes/missiles, unless you add more flicker. And significant rewriting would need to be done if the plane or satellite is going to launch its own missiles. Would be a hard task.

 

Also, it might be possible to make the "crosshairs" into actual crosshairs. The crosshairs are actually the ball kept on for two scanlines, so maybe by keeping the ball on for 10 scanlines, but changing the width around and moving it back and forth a little would work. If you did this, there would be no need to flash it on and off. Maybe it could then flicker at 30 Hz and use the ball on alternate frames for some funky sort of ball-plane like Supercat said.

 

Of course, this all requires kernel time that might not be there at all.

Edited by batari

Share this post


Link to post
Share on other sites
The plane/satellite would have to be the same color as the missiles, and it can only be present when only using single copies of M0 or else there will be 2-3 planes/missiles, unless you add more flicker.  And significant rewriting would need to be done if the plane or satellite is going to launch its own missiles.  Would be a hard task.

:idea: If using an 8K+ cartridge, might it be possible to clear GRP0 immediately after the desired copy of the plane is drawn?

Share this post


Link to post
Share on other sites

I don't have a Starplex Controller yet, but I have a Track and Field Controller. Would it be possible to implement another controller scheme mapping the left button to the left cannon, the right button to the right cannon, when both are pushed simultaneously they fire the middle cannon?

Share this post


Link to post
Share on other sites
Well just in case Im ready for the game once its done^_^

881116[/snapback]

 

Nifty! It might be neat to take the marquee or control panel art and make a custom overlay for the Starplex Controller overlay with Missile Command art. :)

 

Marquee

 

Control Panel

Share this post


Link to post
Share on other sites
The plane/satellite would have to be the same color as the missiles, and it can only be present when only using single copies of M0 or else there will be 2-3 planes/missiles, unless you add more flicker.  And significant rewriting would need to be done if the plane or satellite is going to launch its own missiles.  Would be a hard task.

:idea: If using an 8K+ cartridge, might it be possible to clear GRP0 immediately after the desired copy of the plane is drawn?

881105[/snapback]

Yes, I think that might work, and would probably require 8k since several alternative kernel loops might be required to get the timing right for clearing GRP0 as the plane moves across the screen.

 

Come to think of it, this is also a good solution to an issue in smooth side-scroller (i.e., no playfield) I'm working on.

Share this post


Link to post
Share on other sites

Regarding the bomber/satellite idea, a simpler solution is to reuse the player code that is currently in place for the player's shots. It currently uses 3 frames (1 per shot), so that area of the code could even be cleaned up a bit by using a nice round number of 4 frames (i.e. frames 0-2 = explosions, frame 3 = bomber/satellite). The program is already allowing that player shape to appear anywhere on the playfield, so cycle time would be a non-issue. The remaining problems would be to add in redundancy to bypass the current collision routine so that this object would not affect the falling missiles and smart bombs, and add a new routine to handle the player's explosion/bomber for that frame. Secondary problems would be to allow for the enemy missiles to begin at the bomber's position rather than the top of the screen (the current kernal expects that they all begin at the top scanline), as well as working out any resulting trajectory problems. By itself, the bomber isn't much of an addition unless it's given the ability to fire missiles ;)

 

An alternate idea would be to try to implement playfield GFX for those objects (or maybe alter the current explosion objects to be using playfield GFX instead)...but since positioning is extremely limited for playfield pixels, the method listed above would be the better one IMO.

 

Needless to say, that kind of update would need to be an 8k rom ;)

 

 

 

I got a few questions, how come the colors don't change with you advance to a harder level and are you going to add bombers and satelites to this hack?
Because that part of the program was taken out completely. Saved half a page by doing so...and it's easier on the eyes anyway ;)

 

 

I don't have a Starplex Controller yet, but I have a Track and Field Controller. Would it be possible to implement another controller scheme mapping the left button to the left cannon, the right button to the right cannon, when both are pushed simultaneously they fire the middle cannon?
Yes, the program reuses the SWCHA data (the low nybble of that register holds the value of the right joystick). So just by checking for specific bitpatterns, it could be changed to use that method instead. Currently, it's just checking each bit one-by-one by using an LSR command. So what the routine would need to do is combine both INPT4 and INPT5's high bit (each controller's fire button) and determine the "current" silo based on the status of those. Tho that would take a bit more coding to accomplish in the 4k rom (there's currently only 1 byte free).

 

 

Would it be possible to make the turrets on the left and right side fire slower than the turret in the middle? That is how the real arcade game functions and adds to the overall strategy of turret choice when firing.
That would involve keeping track of seperate "deltas" for each of the 3 shots. More ram needed :P That could be done by upping the game to be 8k - where redundancy can eliminate stack usage (a few bytes of ram to be saved here), or combining variables to reuse ram rather than have dedicated locations.

A bigger issue is to tweak the enemy missile targeting a bit better. The original cart solved the problem of the missile cache being rarely targeted by including it's position twice in the target data (out of 8 possible values, 0-5 = one of the cities, and 6-7 = the center missile cache)...so the cache had twice as much chance of being targeted than a city. In this hack, it's 9 for 9...so it's a bit easier to keep your missiles than in the original cart.

Share this post


Link to post
Share on other sites
Regarding the bomber/satellite idea, a simpler solution is to reuse the player code that is currently in place for the player's shots.  It currently uses 3 frames (1 per shot), so that area of the code could even be cleaned up a bit by using a nice round number of 4 frames (i.e. frames 0-2 = explosions, frame 3 = bomber/satellite).

 

Explosions flickering is fine. After all, they're explosions. And 30Hz flicker on missle tracks is fine, since it's barely perceptible. But 15Hz flicker on an airplane or satellite would be intollerable.

 

Besides, if the code is expanded to an 8K+ cartridge and uses 7 copies of the display kernel (selected based upon the X coordinate of the plane/satellite) there should be no need for the plane or satellite to flicker.

Share this post


Link to post
Share on other sites

Nukey.... superb!!! Graphics, gameplay, everything, nice work.... I was looking at the asm, it would be interesting to implement the satellite/plane feature... so when are the carts going to be made :-)

 

 

 

Curt

Share this post


Link to post
Share on other sites
Yes, I think that might work, and would probably require 8k since several alternative kernel loops might be required to get the timing right for clearing GRP0 as the plane moves across the screen.

881127[/snapback]

That's why I'd think it would require an 8K cart, though actually I just had an even simpler idea (which would probably also require an 8K cart :-( since there's not a whole lot of code space) which would be to recognize that the whole point of a plane/satellite is to drop a missle, and so there'd be no point in having one come out when both "frames" of missles were already occupied. Thus, with 30Hz flicker the plane/satellite would be in-frame with a "single" missle.

 

If this could be done and still fit within 4K that'd be cool. On the other hand, since even that would probably push things beyond 4K one may as well bite the bullet and use multiple kernels to eliminate satellite flicker. Though I just had another thought on that subject: if one were really clever, one could have a single missile come down and be timed so that a plane/satellite would "drop" a second or third copy. The copy dropped by the plane would have to be the rightmost one unfortunately, but the effect could still be somewhat neat and it would make the gameplay less "wimpy" than only allowing one set of three missiles on screen when the plane/sat was on.

Share this post


Link to post
Share on other sites
Besides, if the code is expanded to an 8K+ cartridge and uses 7 copies of the display kernel (selected based upon the X coordinate of the plane/satellite) there should be no need for the plane or satellite to flicker.

881358[/snapback]

Just another thought: If this is done, you'd need to change the value that gets put into CTRLPF to change around the object priorities, so $23 should be put there instead of $21... Since GRP0 would be cleared, you would avoid the possibility of a plane-shaped hole appearing in the explosions ;)

 

This will also make the player's "crosshairs" drawn in front of the missiles and the explosions, but this makes more sense than the way Atari did it, anyway. The only problem is CTRLPF would have to be set to $23 before the beginning of every frame, because you have to change it back to $21 before the kernel starts drawing the missile caches or they would go behind the playfield :(

Edited by batari

Share this post


Link to post
Share on other sites
Regarding the bomber/satellite idea, a simpler solution is to reuse the player code that is currently in place for the player's shots.  It currently uses 3 frames (1 per shot), so that area of the code could even be cleaned up a bit by using a nice round number of 4 frames (i.e. frames 0-2 = explosions, frame 3 = bomber/satellite).

 

Explosions flickering is fine. After all, they're explosions. And 30Hz flicker on missle tracks is fine, since it's barely perceptible. But 15Hz flicker on an airplane or satellite would be intollerable.

 

Besides, if the code is expanded to an 8K+ cartridge and uses 7 copies of the display kernel (selected based upon the X coordinate of the plane/satellite) there should be no need for the plane or satellite to flicker.

881358[/snapback]

 

Talking to the wrong guy there...I don't know much about display kernals. And I disagree about 15hz flicker being intolerable, since the bomber/satellite isn't always on the display anyway. 15hz is still enough to notice when and where it appears, which is no more than twice per level IIRC. But the display issue is not as important as what it's supposed to do (which is launch enemy missiles from a much closer point to the ground). Without that function, there's no reason to add them in the game at all ;)

 

 

 

so when are the carts going to be made

Whenever anyone requests one ;)

Share this post


Link to post
Share on other sites
Talking to the wrong guy there...I don't know much about display kernals.  And I disagree about 15hz flicker being intolerable, since the bomber/satellite isn't always on the display anyway.  15hz is still enough to notice when and where it appears, which is no more than twice per level IIRC.  But the display issue is not as important as what it's supposed to do (which is launch enemy missiles from a much closer point to the ground).  Without that function, there's no reason to add them in the game at all ;)

881973[/snapback]

Pac-Man does 15Hz flickering, and it works, though it is a little annoying.

 

Maybe another option to make the plane more visible would be to make it 30 Hz and the explosions 10 Hz each, though the explosions might start looking pretty bad by then. Still, if you can fugure out how to get a plane on there, I'm sure you could also figure out how to make it fire missiles or even smart bombs :cool:

Share this post


Link to post
Share on other sites
Pac-Man does 15Hz flickering, and it works, though it is a little annoying.

 

Most people would regard it as intolerable; indeed, it's the primary reason the game is so despised.

 

Maybe another option to make the plane more visible would be to make it 30 Hz and the explosions 10 Hz each, though the explosions might start looking pretty bad by then.  Still, if you can fugure out how to get a plane on there, I'm sure you could also figure out how to make it fire missiles or even smart bombs :cool:

882197[/snapback]

 

As noted, the approach to get 30Hz flicker with the plane is simple. Have it only appear when it can drop a missile, which is to say when either (1) there is at most one group of missiles on screen, or (2) at least one of the groups of missiles on screen has only a single missile and it's targeting something other than the rightmost city/base, and the timing is right.

 

In the former case, the plane occupies the opposite frame from the group of missiles that's on the screen. A new missile is created which will reach the height of the plane at the same time as the plane reaches its X position; display of the missile and collision-detection for it will be inhibited on scan lines above the plane [alternatively, the height of the missile could be locked at the top of the screen until the plane reaches the right X coordinate, whereupon the height would be set to that of the bottom of the plane].

 

The latter case would be trickier, but might add some variety. Here, the plane would only appear once because NUSIZ would be zero. The plane would have to be timed to be 32 or 64 pixels to the right of the missile when its altitude reached the bottom of the plane. From that point on the frame downward, NUSIZ would be set to 1 or 2. This approach would be trickier than the first, since the timing on the plane would have to be correct. Could still be pretty cool, though.

Share this post


Link to post
Share on other sites
Just another thought: If this is done, you'd need to change the value that gets put into CTRLPF to change around the object priorities, so $23 should be put there instead of $21... Since GRP0 would be cleared, you would avoid the possibility of a plane-shaped hole appearing in the explosions ;) 

881618[/snapback]

I think I'm wrong about this suggestion... I was somehow thinking that COLUP0 would be cleared, not GRP0, which would also clear the missiles and not work anyway. So never mind, not all of my suggestions are right :dunce:

 

About the 15 Hz plane issue. I would rather see it with no flicker, but if it's a matter of Nukey doing a 15 Hz plane or no plane at all, I'd go with the 15 Hz plane.

Share this post


Link to post
Share on other sites
Just another thought: If this is done, you'd need to change the value that gets put into CTRLPF to change around the object priorities, so $23 should be put there instead of $21... Since GRP0 would be cleared, you would avoid the possibility of a plane-shaped hole appearing in the explosions ;) 

881618[/snapback]

I think I'm wrong about this suggestion... I was somehow thinking that COLUP0 would be cleared, not GRP0, which would also clear the missiles and not work anyway. So never mind, not all of my suggestions are right :dunce:

 

About the 15 Hz plane issue. I would rather see it with no flicker, but if it's a matter of Nukey doing a 15 Hz plane or no plane at all, I'd go with the 15 Hz plane.

882490[/snapback]

 

...and that leads back to the missile problem. Without a way for the bomber to fire missiles of it's own (i.e. possible for the display kernal to allow missiles to begin mid-screen instead of just from the top), finding a way to add the bomber is a non-issue. The first step would be to reorganize as much of the native ram as possible (combining variables wherever possible...breaking them down to use bits instead of full bytes).

Share this post


Link to post
Share on other sites
...and that leads back to the missile problem.  Without a way for the bomber to fire missiles of it's own (i.e. possible for the display kernal to allow missiles to begin mid-screen instead of just from the top), finding a way to add the bomber is a non-issue.  The first step would be to reorganize as much of the native ram as possible (combining variables wherever possible...breaking them down to use bits instead of full bytes).

882548[/snapback]

 

This is why I thought 30Hz flicker would be a good goal. Basically, to send out a bomber in frame 1, what you would do would be to create a single missle in frame 1 and set the frame 1 "bomber" flag and bomber X position (possibly Y position, if you can afford to make it variable). Before the display kernel, if the bomber flag is set for the current frame, if the X and Y positions of the missle are both less than those of the bomber, set the Y position of the missle to the bomber altitude minus a little bit.

 

Then during the kernel, set the player 1 position to the bomber's X coodinate. When about to draw the 'main' part of the frame, check to see if the bomber flag is set. If not, use the normal kernel. Otherwise, use a two-part kernel. First part shows players 0 and the ball normally, but doesn't show player 1 or missle 1. Middle part shows players 0 and the ball along with player 1 (the bomber). This then falls into the normal kernel which is used for the remainder of the frame.

 

Voila--now there's a plane that drops bombs. If the bomber is destroyed before the missile has become visible, the missile should be silently (and scorelessly) destroyed as well. If the bomber is destroyed after the missile has become visible, its horizontal position should be set to zero but the bumber flag should remain set until the missile is destroyed. Once the missile is destroyed, the bomber flag should be cleared when and only when the bomber is also destroyed or flies off screen.

 

A bit of magic, but it should be workable.

Share this post


Link to post
Share on other sites

Nukey, are you STILL sticking to your story that kernal programming is just too tough for you to take on in a "from scratch" title?

 

Don't get me wrong, as far as I can tell you are the KING of Hacks, and if that's just your thang, cool. But man, you have programming cajones that make some "published" homebrewers (myself included) look pale and weak. I mean, I can barely understand other people's well commented source, never mind a raw dissasembly.

Share this post


Link to post
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...

  • Recently Browsing   0 members

    No registered users viewing this page.

×
×
  • Create New...