Search

I've seen other games use the jmp tables as well, mainly Blaster Master.  From what I understand, it's a kernal table that makes the program easier to keep track of while coding.  Imagine if that they needed to go and tweak one of the subroutines, they could leave the JSR to one of those jmps alone, and just alter the jmp itself.  That way you are only making one edit, rather than several edits.  I don't think it would be wise to mess with that table, though doing so might free up alot of space.

I thought it was possible to change mappers.  I recall that DharkDaiz managed to change the mapper for SMB1 in order to implement his season changing effects.

Edit:  Unfortunatly rom hacking is not a thing that you can just pay people to do for you.  For one thing, this is a hobby, not a job, and second, people with the skills prefer to focus on work that interests them.  The only way that a really awesome TGL hack would come to fruition is if one among us is talented enough to make that happen, and is willing to devote alot of time, for free, to making such a game.  Sad to say that many classic NES games do not recieve the love and care that they deserve because not enough people with the skills know about or desire to hack the game.

Unfortunatly I don't posess the skills to make a really great hack of this game, but I am talent at data finding.  In fact I believe I was the first one to start hacking TGL, though others may have been first in writing notes or producing hacks and utilities.

Yeah but is it possible to expand the rom?

Should be possible, but probably not easy.  It's not much work to turn UNROM (128k) into UOROM (256k).  The problem is that the fixed bank is packed full so there's not much room to expand the existing fixed bank subroutines to support 16 banks instead of 8.  But if we could pull it off the hack possibilities are endless.  We'd have an extra 128k of space to do whatever we wanted to.

If I recall correctly, there would still need to be alot of recoding involved in order to make room for new code.  If $C000 to $DFFF could be swapped out, more room could be added.  You only need to have the main PRG bank running for things that must always be active.  There could also be the possibility to use the save ram area to hold extra data.  Games like Kid Icarus and The Legend of Zelda use the Save Ram area to temporarily place data, and it could even be technically possible to alter existing data on the fly in that area.

It would be interesting to see a group hack effort.  More importantly, if we could just expand the rom, I bet there could be alot more possiblities.  More complex rooms, better level design, more puzzles and ways to open corridors, stuff like that.

It would be very easy to do in the original game except for the lack of space.  Well, any event that takes place off screen.  On screen changes would take far more coding.

Well maybe you're right and I'm getting over my head, not giving myself enough credit and whatnot. 2x2 metatiles... That term could have helped. Guess that's what I get for being aloof in hacker circles over the years.

Anyway, something interesting to think about... corridor 21. Now there's a unique stage. I never really looked into it until a few days ago. Multiple enemies and bosses coexisting before the end of the level. And screens repeating over and over again. Maybe some of those uncertain opcodes are used there.

From a search I did, I think the game does a check to see if you are in corridor 21, and if you are, don't sound the klaxons or stop the screen from scrolling upon defeat of a boss untill a certain point.

Edit:  Been looking through the corridor data and metatiles have a certain pattern to them.

From what I've seen, 06 sets up the metastructures.  The next byte seems to determine how the tile operates.  I noticed that 40 causes the next 4 bytes to read as co-ordinate info and as tile repeater info, plus the pointers.  When 60 is set, it only uses 2 bytes for x/y and the pointers.  When it's set to 80, it seems to indicate the end of the metastructures for that specific area.  The second nybble of the second byte seeems to be the structure ID, and like it's been said, it seems to go up to 8 structures at a time.  Now for all the structures that are being loaded, it doesn't have to keep using opcode 06, but instead uses that second byte as the start of the next metastructure data.  I've seen this occur with a game called Equinox, which has a complicated object structure that "builds" off of previous structures and saves space by assuming x/y or z, block type, or other information based off of the previous structure.  It even reads information from the previous room, which can lead to fun puzzles.  Of course Equinox is an entirely different can of worms, and this is the TGL board.

The other thing is that the metastructure data also seems to be similar in the overworld section.  Only difference is that it doesn't use opcodes to set the data up, but just goes there from a pointer table.  Also instead of having an x/y in two bytes, it has it only in one.  The actual level data for the overworld is done entirely differently using pre-defined interiors plus objects.

Actually you are walking in every mode.  The difference is that the ship sprite is loaded instead, and the weapons are set to do different things when $30 is set to 50.  If you enable flying in an overworld room, it will start scrolling the background(as garbage), and if you do that in flying mode, it stops the screen.

Okay I've figured out the labyrinth exterior template data.

At $167C0 are pointers to the area's floor data.  The first byte is #05, and it's a length control byte.  The second byte is the X/Y location on the screen.  Since this is the floor data, it's set to zero.  After that is the metatile structure size.  For floor data, it means repeating tiles.  After those two bytes is the byte(s) of the tiles to use for the floor structure.

For walls and such, the pointers start at $167FA, and it's grouped into different metatile structures.  There are 4 for the 4 corners of the room, and 4 for the walls.  I assume that based on what bits are set in the map data, it will turn on and off the 4 wall structures.

ZEXALUPA

All the outer walls act as warps.  Certainly much easier than what you guys where doing.

I take it you've tried to decode the data before, right?  The data's not that hard to figure out, but it's hard because there's only so much space and even one screen with enemies takes up 4 bytes.  Perhaps this is why the game was critticized for being repetitive.

$15210 - room template data.  Each byte represents 8 tiles on the screen.  Note that this data overlaps with the actual level data, and that some template indexes actually reference this level data...incorrectly.  If the actual level data was moved, there would be more room for indexes.

Level data itself has no proper start address, and can technically be stored anywhere in the bank.  Base data is 2 bytes, one template index and it's tile type.  The game can use up to 32 indexes, or $1F.  How it works is that the basic index is from $00 to $1F, and for every $20 you add to that value, the game reads a three byte object.  For example, $20 to $3F adds one object to the screen.  $40 to $5F reads 2 objects, and so forth.  Each object has a tile type, a location on screen, and it's direction/quantity.  How that works is that the first six bits tell if the tile is on or off.  Each object can be six tiles long, and each bit represents the individual tile switched on or not.  The last 2 bits determine direction.  There is horizontal, vertical, diagonally up and diagonally down.  $C1 tends to be used for single tiles such as item pods since it matches up properly with it's on screen co-ordinates(so $C1 is akin to telling the game to just the x/y in the previous byte).

See what I did there?  Anyway, since somebody has figured out pretty much all the corridor information, I figured that I should get to work in describing the Labyrinth mode data because somebody beats me to it.

So to start off with, at $14A7E is the start of the game's map data.  The structure is variable length, with the first byte being the control code.  The first nybble of the first byte controls what type of room it is.  Here a list of what each bit does:

00 - empty room(except for possible enemies)
10 - adds pointer, which is read after enemy index or item index, if present, is defined
20 - adds item index after enemy index(if present)
40 - miniboss room, adds item index which becomes miniboss index
70 - used when you want to have a room with chips.  Prevents them from comming back unless you refresh the area
80 - indicates a room or corridor

The second nybble is the length of the room.  The greater the length, the more the room contains:

02 - contains only the basic map definitions such as exit directions/key usage, and area index
03 - like 02 but with enemies, or miniboss room with item/boss index
04 - room contains pointeres to level data
05 - room contains pointers to level data + enemies
06 - room contains item index + enemies + level data

For interior rooms, 82 is used for corridors and password rooms.  A3 is used for shops and info rooms.  In either case, adding 80 to the room type will transform it into a corridor from 00 to 127.

More to come...

Nice.  I should write up my information that I have on the game too.

Naju has been destroyed.  The Earth is saved from Naju coliding into it, but the battle is far from over.

Apparently Naju was just one of 10 intergalatic defense stars that were designed to act as strategic attack platforms against hostile planets.  The alien life forms have only begun to wrech havoc against the universe, and their plans are to infest the remaining 9 planets and use them to utterly destroy all human life accross the cosmos.

The planet that was first comendeered to smash into earth was Naju 1.  It was send into orbit many years ago, and since then the pilots of the star had created a world for themselves, with a diverse ecosystem.  When the aliens landed, they transformed the landscape in their conquest.  The residents tried in vain to stop them, but before the final decendant of the original crew made an attempt to set the self-destruct sequence, he radioed Earth for assistance.

Now there are 9 more stars out there, and all of them are in danger of having their weapons system activated.  You must go to each planet and prevent the aliens from conquring the universe!

The plan would be to have 9 worlds to explore, each with their own unique maps, environments, keys, weapons, and seal puzzles.  It would be designed for the worlds to be played in any order, however contained within the worlds would be clues that would ultimately reveal who the aliens are, their reasons for targeting the worlds, and how to stop them.  A big factor would be that you can choose to destroy the world or save it.  When you start each world, the game would be on an invisible timer, and the aliens will invade more and more as you progress.  The machine that controls the orbit of each world needs to be protected against the aliens.  If you can protect it, the world is safe.  If not, then you must then activate the self-destruct mechanism.  Saving each world means you can then use their technology on other worlds, but destroying them will ensure that the planet will never fall into the wrong hands again.

Also I guess this means my Link's Awakening project is on hold...like the same with my Megaman 4 hack, my Equinox hack, my Legacy of the Wizard hack...

Yes I do have ADHD, how did you guess?

I should post my notes on the overhead section of the game too.

Here's a game genie code that might make things a little bit more fun:  ZEXALUPA

It should work.  It better work since I actually went to all the trouble of testing it.