Ms. Pac-Man gets a facelift

[Nukey Shay]

Dots and walls have been altered to use the arcade's seperate colors. In addition, flicker coding provides red color for Ms. Pac's bow and lips. All sprites have alternate frames/colors, in fact...but editing the others may make them look odd when multiple sprites are sharing the same rows...so I left them alone.

 

BTW the original game was good already...so I didn't alter the maze layouts or their order. Having the upper levels repeat x 4 gets a little monotonus for this game, IMO.

 

 

There's only a couple of unresolved bugs (copyright text not kicking in right away and a slight timing error on it)...but it shouldn't affect gameplay. Also, the eating dot sound effect remains active in the demo for some odd reason.

MsPac_Man_multicolor_.zip

[Wickeycolumbus]

Looks good so far

[Corby]

[Bakasama]

I do notice one bug. This seems to happen when the fruit first appears, the game just slows down alot.

[Vic George 2K3]

So what system is this for?

[Wickeycolumbus]

So what system is this for?

 

2600

[+TrekMD]

This looks great! Thank you!

[Nukey Shay]

So what system is this for?

 

Funny...I thought that the forum name was self-explainatory

[sandmountainslim]

Great lookin hack Nukes

Wp

[Vic George 2K3]

So what system is this for?

Funny...I thought that the forum name was self-explainatory

When the message appears as the top-responded message in the Game Programming forum when you're cruising through all the main forums for top-responded messages, it could be from any of the subforums in that one.

[Bakasama]

So what system is this for?

Funny...I thought that the forum name was self-explainatory

When the message appears as the top-responded message in the Game Programming forum when you're cruising through all the main forums for top-responded messages, it could be from any of the subforums in that one.

 

That's understandable but it's hard to miss this near the top of this page:

 

"AtariAge Forums > Game Programming > Hacks > Atari 2600 Hacks"

[Foxsolo2000]

Nukey, a little off topic but as you have probed the code on this game was there any truth in the rumour that if you achieved a particular high score that the Vaguard copter would make an appearance somewhere in the game?

[Vic George 2K3]

So what system is this for?

Funny...I thought that the forum name was self-explainatory

[

When the message appears as the top-responded message in the Game Programming forum when you're cruising through all the main forums for top-responded messages, it could be from any of the subforums in that one.

That's understandable but it's hard to miss this near the top of this page:

 

"AtariAge Forums > Game Programming > Hacks > Atari 2600 Hacks"

 

If one only clicks on the current message and focuses primarily on that instead of scrolling up to the top of the page, it can be easily ignored.

 

But enough said on that. Let's just focus on the topic at hand, shall we?

Edited July 5, 2009 by Vic George 2K3

[DEBRO]

Hi there,

Nukey, a little off topic but as you have probed the code on this game was there any truth in the rumour that if you achieved a particular high score that the Vaguard copter would make an appearance somewhere in the game?

I haven't seen this. IIRC the Vanguard graphics are in the ROM (it's been a long time since I've looked at it) but I didn't see a way to trigger them. They look like garbage data. As a side note I think Galaxian graphics are in the Centipede ROM.

[Foxsolo2000]

Hi there,

Nukey, a little off topic but as you have probed the code on this game was there any truth in the rumour that if you achieved a particular high score that the Vaguard copter would make an appearance somewhere in the game?

I haven't seen this. IIRC the Vanguard graphics are in the ROM (it's been a long time since I've looked at it) but I didn't see a way to trigger them. They look like garbage data. As a side note I think Galaxian graphics are in the Centipede ROM.

 

Amazing. Proof at last that an urban legend I heard back in 84 does indeed have some truth behind it.

[Atari~e]

Hi there,

Nukey, a little off topic but as you have probed the code on this game was there any truth in the rumour that if you achieved a particular high score that the Vaguard copter would make an appearance somewhere in the game?

I haven't seen this. IIRC the Vanguard graphics are in the ROM (it's been a long time since I've looked at it) but I didn't see a way to trigger them. They look like garbage data. As a side note I think Galaxian graphics are in the Centipede ROM.

 

Amazing. Proof at last that an urban legend I heard back in 84 does indeed have some truth behind it.

Thank you. I love Ms. Pac-Man. It's my favorite classic video game...

[Atari~e]

I did'nt mean to put this in this remark. I wanted to post it alone. Sorry. My mistake :0).

[DEBRO]

Hi there,

Hi there,

Nukey, a little off topic but as you have probed the code on this game was there any truth in the rumour that if you achieved a particular high score that the Vaguard copter would make an appearance somewhere in the game?

I haven't seen this. IIRC the Vanguard graphics are in the ROM (it's been a long time since I've looked at it) but I didn't see a way to trigger them. They look like garbage data. As a side note I think Galaxian graphics are in the Centipede ROM.

 

Amazing. Proof at last that an urban legend I heard back in 84 does indeed have some truth behind it.

Also, the Vanguard graphic data is only present in the PAL version.

[atwwong]

Nukey's hacks are always worthwhile to play...

[NE146]

Wow this kicks ass Nukey 2600 Ms. Pac is an all time favorite of mine so this just makes it that much cooler. I just played it on Stella (with the nifty "tv" effects) and it is vewy niiiice

 

BTW the original game was good already...so I didn't alter the maze layouts or their order.

 

Yknow I've always thought that'd be another good hack.. to have 2600 Ms. Pac with alternate mazes ala Ms. Pac Attack or others. Might even be fun to have AA members design some mazes using whatever constraints there are. I dunno.. I think it'd be nifty

 

Heck, it could even be done on original 2600 Pac, or Hack em for that matter. (After all of course "A Better Pacman" was originally ms. pac) so it seems the sky's the limit on mazes. So why not?

[Nukey Shay]

Because then it becomes a different game The objective was just to make the existing game look better...as was done with PacMan8k (although I did alter that game slightly so that the ghosts enter and leave through the top of the center box instead of the side, and more faithful bluetimes added). It's fortunate that this game had so much garbage rom that I didn't have to increase the number of banks (I had to add seperate dot tables for each maze, since the walls no longer hide inaccessible ones).

Still trying to scrape up enough cycle time to flicker the fruit sprites only when one is eaten...so that the alternate shapes hold point values instead. There's probably some ram that can be saved too, since the edge dots only use 2 bit positions out of 14 ram bytes.

 

As far as custom mazes go, these are edited pretty easy if somebody wants to make their own. In the original game, the data for the walls is stored in the first bank at $DC00 to $DCA7 (42 bytes per maze...following the pattern PF0,PF1,PF2 for 14 lines each). A Y-position table exists in the 2nd bank at $FD52 that holds the vertical locations of the 4 tunnels for the 4 mazes (so the fruit "knows" where to appear). The rules for movement is in the 2nd bank at $FE27 to $FF76 (84 bytes for each maze)...using 6 bytes for each of the 14 lines. Except for the first nybble in each group, each successive nybble is used for the rules for each successive dot position...from the left edge to the middle of the screen. The trailing nybble is basically just a duplicate of the one that preceded it (i.e. rules for being between the 2 center positions). It could be that the initial nybble for each line was intended for moving offscreen (i.e. allowed directions when the sprite is left of the edge), but it makes no difference what it's value is AFAIK.

 

The bit values for valid directions is up, right, down, left (= bit positions 8,4,2,1 respectively). Take a look at the first maze. Going from left to the center of the screen on the first row of dots, the valid movements are:

 

First nybble unused...nybble value %0000

No movement (the edge wall)...nybble value %0000

Right + down...nybble value %0110

Right + left...nybble value %0101

Right + left...nybble value %0101

Down + left...nybble value %0011

No movement (vertical wall)...nybble value %0000

Right + down...nybble value %0110

Right + left...nybble value %0101

Right + left...nybble value %0101

Right + left...nybble value %0101 x 2

 

 

Then you just stick 'em together:

%00000000 = $00

%01100101 = $65

%01010011 = $53

%00000110 = $06

%01010101 = $55

%01010101 = $55

 

There's the movement rules for the first line...as a dump shows:

.byte $00 ; | | $FE27

.byte $65 ; | XX X X| $FE28

.byte $53 ; | X X XX| $FE29

.byte $06 ; | XX | $FE2A

.byte $55 ; | X X X X| $FE2B

.byte $55 ; | X X X X| $FE2C

 

 

Figuring out dot position values (in the hack) is a bit trickier. A table at $FFC5 in the original game just dumped all pixels to ram (except the pixel positions inside the box). Because walls would cover up any imbedded dots and each screen has the box in the same exact spot, this wasn't a problem. I had to break it down and use seperate tables in the hack. Imagine that the first row of dots (left to right) is labelled a though r. Dots a and r are the edge dots, so they go in the first byte of the table, following the pattern -a-r---- (all other bit positions are irrelivant here). The next two bytes hold the bit positions of all the rest...and they follow the pattern bichdgef for both (since the maze is a mirror image). I was able to cut each 3rd line because it is a mirror image...dunno why that wasn't done originally A 4-byte table at $F315 in the original game holds the total number of dots+energizers in each screen (so the game knows when to move up a level).

 

Kind of a long description, but that is how custom mazes are created. Really time-consuming to do it by hand. I'd imagine that an app could be written to translate bit positions into table values.

Edited July 8, 2009 by Nukey Shay

[e1will]

Well done! I like the separate dot / maze colors.

 

--Will

[Animan]

Maybe he thoght the Atari 2600 itself is hacking? who knows.

 

Looks great (in my mind, since i can't test this in Scotland )

[+TrekMD]

Nukey, I'm no programmer but I have a question out of curiosity. Could this programming have been done in the 80's or is this something that is possible now because of new knowledge of how to program these games? It looks fantastic and it's too bad it didn't look like this back then!

[Nukey Shay]

This could have been. There are no special coding techniques used...I just removed the ORA instructions that merge dot data (held in ram) with maze data (held in rom) on scanlines that display them...that is why the black playfield lines extend all the way through maze walls. Other than adding seperate dot initialization tables, all the rest is unchanged. Would it have been done? Almost certianly not, because management was dead-set against using black backgrounds at the time for some reason or another...likely because they wanted to showcase the Atari color palette in particular (and image burn-in was still a recent issue...so color-shifting of the entire screen was a necessity - at the cost of ram). It's one of those things that programmers lost on when arguing with management.