Can Montezuma levels be modified?

[Scott Stilphen]

I'm trying to modify this screen, so that I can reach the other side, but I haven't been able to. Can anyone do this?

 

[Mindfield]

I'm sure it's possible. It's just a matter of figuring out how the levels are laid out internally and then altering 'em. The first step is figuring out the internal dimensions of each room. Now, there are a few ways that this might be handled.

 

Method 1:

 

When designing game levels, you generally take a "tiled" approach -- that is, internally, each room is made up of blocks represented by a single byte that defines the static object contained in that block -- a section of wall, a segment of ladder, a portion of floor, etc. Then, usually, a secondary descriptor layer defines the placement of dymanic objects and enemies -- diamonds, torches, keys, swords, doors, snakes, and the starting points of skulls and spiders. These would be kept in a numeric array of four-byte sets containing the object or enemy, the screen it appears on, and its internal X and Y coordinates. When Monty enters a room, that list is referenced in order to populate the room with objects and enemies Monty can interact with, and updated according to that interaction (a diamond is taken, a spider is killed, etc.)

 

Method 2:

 

Same as method 1, but the aforementioned list is hard-coded into the level design itself. That is to say that rather than using this reference list to populate levels with interactive objects on the fly, those objects are included in the level layout itself and dealt with according to object type upon entering the room. When an object changes state (from present to missing) it's simply removed from the address space of that room.

 

Given the restricted addressing space of the VCS carts, method 2 is probably more likely, as method 1 requires more space (level layout plus object list)

 

Basically what you'll want to do is go through the ROM with a hex editor and look for long strings of repetative patterns that contain a lot of nulls (or some other byte that represents areas where there is no object, since Monty is a game with a lot of empty space in its level design. Usually this is represented by a null - character $00, but there's no accounting for a developers' particular quirks) Once you've found that, try and find the beginning. This will probably be room 1 -- where you start out, and try and fit the strings together so that they formulate the numeric equivalent of what the room would look like on-screen. Once you've done that you've got the room dimensions, and so can go ahead and de/reconstruct each level.

 

Hell, I may give this a shot myself. :-)

[moycon]

Go Mindfield!! Go!!!!

[Scott Stilphen]

I tried using showgfx. All the items/enemies and such are easily found, but the backgrounds aren't (to me, anyway). I think part of the problem is the room layouts are all mirrored, and most of the 24 rooms are the same such as the rooms left and right of the starting room- the programmer probably used a small block of graphics and then repeated it to fill in the lower part of the screens?). Probably not the best project to try and modify for the first time If you or anyone else wants to try, please do!

[rasty]

You may want to try my RomHack utility, it can be quite useful trying to identify graphics inside a rom.

 

It also features a hex/ascii display, 6502/z80 disassembler and a few more things..

 

Get RomHack from my homepage (freeware of course!).

 

Take a look at the docs first, since there are several display modes available. To search for Backgrounds or Sprites, I'd suggest using the "F6" or "F7" modes.

 

Let me know if it helps..

 

greets,

Rasty.-

[Scott Stilphen]

Ran into another problem. If I change so much as one pixel and convert it back to a bin, the game won't run! Now what?

[Scott Stilphen]

Thanks for the program, Rasty! *Much* more versatile to use than some others. It's already "paid" for itself! (see my E.T. post)

 

All it needs is an option to flip the screen (since most graphics are displayed upside-down normally). And the future option of being able to compare 2 ROM images would be awesome! (I know Tempest would like that feature).

 

[ 11-08-2001: Message edited by: Scott Stilphen ]

[Tempest]

Who me? Nah... What a useless feature that would be.

 

Tempest

[slapdash]

Scott: find the Osama/Kabul thread -- the problem is that the emulator doesn't recognize the game once you've changed it. But there are apparently ways to set up the particular emulators to recognize new games.

 

Or just BIN2WAV it and run it into the Cuttle Cart...

[Scott Stilphen]

I've messed around with hacking other games, and they all ran fine. What is it about Monty that Z26 is so picky about?

 

Btw, I created a super-easy version of Solaris, just so I could get a screen pic of the ending for my Easter egg site.

 

 

If anybody wants it, you can download it here.

[Mindfield]

What about emulators like PCAE? It doesn't natively recognize ROMs; you have to set everything up yourself as to cart size (which includes bank switching methods), broadcast type, controllers used, etc. Wouldn't a modified Monty run on that?

 

If not, then is it possible that Monty's protected with a simple checksum?

[Ze_ro]

quote:

---

Originally posted by Scott Stilphen:

Btw, I created a super-easy version of Solaris, just so I could get a screen pic of the ending for my Easter egg site.

---

 

By the way, I've noticed that all the pics you've posted in your threads are .bmp files. I'm not sure about some of the latest versions of IE and such, but my browser can't read these properly, so they show up as broken links. I'd suggest you convert your images to jpegs or png's or something (This also saves disk space and bandwidth)

 

--Zero

[Albert]

quote:

---

Originally posted by Ze_ro:

By the way, I've noticed that all the pics you've posted in your threads are .bmp files. I'm not sure about some of the latest versions of IE and such, but my browser can't read these properly, so they show up as broken links. I'd suggest you convert your images to jpegs or png's or something (This also saves disk space and bandwidth)

---

 

They show up fine in IE 6.0, but I can't vouch for previous version. I haven't tried Netscape, Mozilla or Opera, though. We use PNG for all the screenshots on AtariAge (not including the ones that are taken with a camera, those are saved as JPGs).

 

..Al

[Scott Stilphen]

I'm using IE 5.5 - what version do you have?

 

I'll use JPG's in the future.

[rasty]

Thanks Scott, I'm glad RomHack has been useful! (that's what I made it for afterall )

 

Curious how I planned to have the roms compare feature since the start, too bad I never got to actually code it.

 

Concerning new features, anyway, there may be some issues. I did RomHack in 1997 and it was a DOS program. Now, I don't even have the same C compiler anymore (Watcom C). Of course, if there is enough interest, I may go ahead and port it to win32 to further develop it.

 

I'm also willing to send the source code to anyone who is serious about doing that in my place (I've more than once sent it to people who voulonteered but never came back to me!).

 

Again, thanks for appreciating my little program and let me know if you achive some more results!

 

greets,

Rasty.-

[Eckhard Stolberg]

quote:

---

Originally posted by Scott Stilphen:

I've messed around with hacking other games, and they all ran fine. What is it about Monty that Z26 is so picky about?

---

 

The other games would work with the default settings like Atari's F8 bankswitching for 8K games or joysticks as the controller. If your game uses anything non-standard, you have to enable it yourself with the command line. Montezuma's Revenge for example uses Parker's E0 type of bankswitching. This is enabled with the -g3 command line switch. So at the DOS prompt type something like

 

z26 -g3 MontyPat.bin

 

and it should work. For released games we try to identify the ROM with a checksum and enable everything automatically, but for hacks you are on your own.

 

 

Ciao, Eckhard Stolberg

[Scott Stilphen]

Thanks for the info, guys.

[Scott Stilphen]

Apparently, it takes a little more than just making the platform "look" solid...

 

 

...as the gaps are still there. Now what?

[Mindfield]

Pure speculation, but perhaps there's two sets of data -- one table for what graphic element goes where, and one that defines what each graphic in the first table is. I don't know why it'd be done this way as such a secondary table would be redundant since, from a programming standpoint, the first table would be self-defining (object 1 is a floor section. Is Monty standing on object 1? Yes, so don't go to the fall routine. Otherwise your code would have to do further comparison. i.e. Object 1 looks like this. Definition 1 is a floor section. What's Monty standing on? Object 1. What's Object 1? Definition 1: A floor section. Ergo, Monty does not fall.) From a VCS programming standpoint, where you want code to be as compact as possible, this doesn't seem prudent or likely -- but you never know.

 

Another possibility is that the object you used in your example isn't, in fact, a floor section, or perhaps was meant to be a floor section you can fall through, but was never used. Is there another tile like that in the set? Or is there another unique tile (like the "blinking" floors) you can use to test with?

[Nukey Shay]

I believe it was due to the game not using the collision-detection registers (does this speed up execution?)

[Scott Stilphen]

I simply made the graphics for the platform long enough that they filled in the spaces.