z1spec, source codes,dokumenty
[ Pobierz całość w formacie PDF ]
Zelda 1 Hack InformationTril <dem@tunes.org>$Id: z1spec.sgml,v 1.3 2001/08/05 21:12:30 dem Exp $Here are Zelda 1 map internals obtained by disassembling the NES cartrom. Included are the internal formats of the overworld and under-world map screens. There is no monster or item information yet.Palette and pattern info will be added later. Use at your own risk.______________________________________________________________________Table of Contents1. Introduction1.1 Where to get this document1.2 Disclaimer1.3 Before Reading This Document1.4 Numeric Conventions1.5 IMPORTANT Note about Offsets1.6 About this Document1.7 The Art of ROM Hacking2. The Overworld2.1 The Overworld Map Format2.2 The Overworld Map2.3 Overworld Screens2.4 Columns2.4.1 Column Data Format2.4.2 Column Tables2.4.3 The Column Directory2.4.4 Indexing a Column2.5 Squares2.5.1 The Primary Square Table2.5.2 The Secondary Square Table2.6 Secrets3. The Underworld3.1 The Underworld Map Format3.2 Underworld Data3.3 Underworld Levels3.4 The Underworld Screen Table3.5 Underworld Screens3.6 Underworld Columns3.7 Underworld Squares3.8 Underworld Doors3.8.1 Finding Door Information3.8.2 Door Codes4. Common to Overworld and Underworld4.1 Level Information4.1.1 Level Information Table4.1.2 Starting Locations______________________________________________________________________1. Introduction1.1. Where to get this documentThe latest version of this document is always posted at1.2. DisclaimerThe information in this document is not guaranteed to be correct. Itake no responsibility for the integrity of your Zelda rom file if youmess it up. Please use patch files (such as the standard patch formatbeing adopted by several emulator authors) instead of modifying romimages directly, so you don't lose the original game or ruin it forsomebody else.1.3. Before Reading This DocumentBefore reading this document, you are expected to know what a patterntable is. If you don't, read a document devoted to NES technicalinformation first.1.4. Numeric ConventionsAll numbers are in decimal, unless written with a dollar sign ($), forconvenience by those who aren't used to hex.1.5. IMPORTANT Note about OffsetsOffsets are all from the start of PRG ROM, not from the start ofZELDA.NES! To calculate offsets into ZELDA.NES, add 16 bytes (thesize of the .NES header) to every offset in this document.1.6. About this DocumentI am releasing this document into the public domain. However, if youfind it useful, or if you have any comments, don't hesitate to send mean e-mail.I created this document so that my friend Conrad could create a mapeditor. However, I also enjoy reading 6502 assembly code and solvingtough problems. I intend to eventually account for every byte in theZelda ROM, but I am putting off work on that for a while now that thisspec is basically done. It should be enough to create a decent mapeditor, if it is correct. If it is not correct, let me know and wecan try to fix it. I hope you get as much fun out of using thisdocument as I had making it. Keep hacking!1.7. The Art of ROM HackingWhen I did a (pretty intensive) search for "zelda hack" in my usualsearch for duplicate projects before beginning something new, I cameup with a lot of sprite modifications (clearly made using various NESpattern editors that are readily available), and a page with a fewoffsets that were apparently guessed at random. This is a sad andpathetic state. Why doesn't anyone do things the right way? The ONLYway to get accurate information about modifying a game is to dig inand immerse yourself in its machine code. I hope this document, whenreleased, will show people what is really possible and encourage themto repeat what I have done, for other games. Only afterwards can youcall yourself a ROM hacker. Using a program someone else has writtendoesn't count (this goes for all the script kiddies, too)! However,getting the information for this document was a lot of work. Don'tget frustrated right away, and you will find some very interestingthings in the depths of code, and perhaps even a new perspective onprogramming- from the outside.2. The Overworld2.1. The Overworld Map FormatDescription Offset Num. Entries Entry Size------------------------------------------------------------------Overworld Map 87064 128 16Column Directory 105743 16 2Column Table 0 89048 16 variesColumn Table 1 89101 16 variesColumn Table 2 89150 16 variesColumn Table 3 89216 16 variesColumn Table 4 89284 16 variesColumn Table 5 89334 16 variesColumn Table 6 89394 16 variesColumn Table 7 89453 16 variesColumn Table 8 89512 16 variesColumn Table 9 89574 16 variesColumn Table 10 89639 16 variesColumn Table 11 89708 16 variesColumn Table 12 89769 16 variesColumn Table 13 89823 16 variesColumn Table 14 89889 16 variesColumn Table 15 89941 16 variesPrimary Square Table 92540 64 1Secondary Square Table 92596 16 4Secrets Table 92534 6 12.2. The Overworld MapThe overworld is 16 screens wide by 8 screens high. Screens arenumbered 0..127 starting at the upper left corner, moving left toright, then top to bottom. Therefore the screen number is calculatedby 16*R + C where R is the map row and C is the map column.However, not all 128 overworld locations are entirely different. Somehave the same graphic as another location. Each unique screen isstored once. Screens that have the same picture, but differentcolors, can still share the same memory for their graphic (the colorsare stored elsewhere).The overworld screen table stores 124 unique screens of 16 bytes each(see the next section for a description for individual screens).These in no particular order. The overworld map contains 128 bytes,one for each 2-D map location. Each byte in the overworld map refersto one screen in the overworld screen table.2.3. Overworld ScreensOne screen in the overworld is 16 columns wide. Each column is 11squares high. Each screen takes 16 bytes, one byte for each column ofsquares on that screen.Before we learn how to find the data for a column, we need to discussthe format of the data for a column.2.4. Columns2.4.1. Column Data FormatThe data for column is 11 bytes, one byte for each square in thecolumn, stored in order from top to bottom. A square is made of 4tiles arranged in a 2x2 square on the screen.It takes 11 bytes to draw a column, but these aren't always stored as11 consecutive bytes in memory. Instead, if two squares (one abovethe other) are the same graphic (use the same tiles), they can bestored in one byte instead of two. The number of bytes it takes tostore a column depends on how many squares are stored doubly. Theminimum number is 6 bytes (if there are 5 duplicated squares and oneleft over), and the maximum is 11 (if no squares are duplicated).There is no way to duplicate more than 2 squares at a time, so even ifall the squares in a column are the same, you still need 6 bytes tostore that column.There are 64 possible squares (although not all of the 64 possible maybe actually used). This means that only 6 bits are needed to storethe square number. Since each square uses one byte, there are 2 extrabits in the byte for each square. The meaning of a square byte isdescribed in section 4, "Squares."The 6 bits for the square number are stored in bits 0-5 of each bytein the column data. If bit 6 is set, this square is a duplicatedsquare and will take up two rows, one above the other, in this column.2.4.2. Column TablesThe column data for 16 different columns is stored together in what wewill call a "column table." A column table contains the 6-11 bytesfor each of the 16 columns in that column table, stored all in onecontiguous area of memory (which, if you do the arithmetic, could beas small as 96 bytes, or as large as 176 bytes, depending on how manytotal squares are doubled in the columns inside the column table).The first byte of the 6-11 bytes for an individual column always hasbit 7 set. This is how to locate columns within a column table. Wehave now accounted for all 8 bits of every byte inside the columndata.2.4.3. The Column DirectoryThere are 16 column tables, for a total of 256 different columns inthe overworld. The addresses of the beginning of each column tableare stored in a table of column tables, which we will call the "columndirectory." I have copied these addresses and converted them tooffsets in the ROM in the above...
[ Pobierz całość w formacie PDF ]