Paging and Subsystem Initialization - Revision history

Mddass: /* Initialize Entry Hash Table */

2020-03-13T22:19:19Z

‎Initialize Entry Hash Table

Mddass: /* Print Debug Message */

2019-11-24T14:48:09Z

‎Print Debug Message

Mddass: /* Structure */

2019-11-24T14:33:25Z

‎Structure

Mddass: /* Paging System Structure */

2019-11-24T14:33:10Z

‎Paging System Structure

Chekwob: 8 revisions imported: Initial import from Wikia

2019-04-27T17:44:38Z

8 revisions imported: Initial import from Wikia

Wikia>WurlyFox at 04:42, 27 July 2015

2015-07-27T04:42:18Z

Wikia>WurlyFox at 04:39, 27 July 2015

2015-07-27T04:39:23Z

Wikia>WurlyFox: /* Allocate and Initialize Pages */

2015-07-27T04:28:17Z

‎Allocate and Initialize Pages

Wikia>WurlyFox at 03:52, 27 July 2015

2015-07-27T03:52:44Z

Wikia>WurlyFox at 23:16, 26 July 2015

2015-07-26T23:16:47Z

@@ Line 97: / Line 97: @@
 The universe of keys in the entry hash table is composed of all possible EIDs [of entries] from the NSF file. Initially, each slot in the table pairs an EID (key) with the CID (value) of the chunk that contains the entry with that EID. Thus, the table initially associates each entry with its parent chunk.
-<p>Eventually, a request will be made to page an entry's content into main memory. Throughout the game, this is done by specifying the EID of an entry with desired content as the argument in a call to the entry paging routine. The entry paging routine ultimately pages the <i>chunk</i> that contains the entry, rather than the entry alone. It accomplishes this by:&nbsp;</p><li>Calculating the EID's hash with the hash function: <code data-rte-washtml="1">(EID &lt;&lt; 15) &amp; 0xFF</code></li><li>Using the hash as an index into the <code>entryhashbuckets</code>&nbsp;pointer array to locate the associated bucket</li><li>Starting the search for the pair with key <code>EID</code> at the pointed index</li><li>Obtaining the accompanying <code>CID</code> value for the pair upon finding a match</li><li>Using the NSD to determine the sector position and/or size of the chunk with that CID</li><li>Reading from disc at the corresponding sector position to a free page    </li>
+<p>Eventually, a request will be made to page an entry's content into main memory. Throughout the game, this is done by specifying the EID of an entry with desired content as the argument in a call to the entry paging routine. The entry paging routine ultimately pages the <i>chunk</i> that contains the entry, rather than the entry alone. It accomplishes this by:&nbsp;</p><li>Calculating the EID's hash with the hash function: <code data-rte-washtml="1">(EID >> 15) &amp; 0xFF</code></li><li>Using the hash as an index into the <code>entryhashbuckets</code>&nbsp;pointer array to locate the associated bucket</li><li>Starting the search for the pair with key <code>EID</code> at the pointed index</li><li>Obtaining the accompanying <code>CID</code> value for the pair upon finding a match</li><li>Using the NSD to determine the sector position and/or size of the chunk with that CID</li><li>Reading from disc at the corresponding sector position to a free page    </li>
 <p>With the chunk contents in main memory, the entry paging routine then locates the requested entry [within the chunk data] and returns a pointer.</p>

@@ Line 134: / Line 134: @@
 === Print Debug Message ===
-When all pages have been allocated and initialized, the game writes to standard output a confirmation message with the number of physical pages allocated, i.e. <code>printf("Inited and Allocated %d pages\n", NSD.physicalpagecount);</code>
+When all pages have been allocated and initialized, the game writes to standard output a confirmation message with the number of physical pages allocated, i.e. <code>printf("Inited and Allocated %d pages\n", NSD.physicalpagecount);</code> (in Crash 2, the output is <code>printf("%d p l%c\n",physicalpagescopied,level & 0xff);</code> instead)
 === Initialize Texture and Wavebank Page Structures ===

@@ Line 64: / Line 64: @@
    struct page physicalpages[21];   // 0x44 each
    unsigned long virtualpagecount;
-   struct page virtualpages[38];
+   struct page virtualpages[37];
    unsigned long pagecount;
    struct page *currentlypaging;

@@ Line 40: / Line 40: @@
 };
 </syntaxhighlight>
 == Operation ==

← Older revision		Revision as of 04:42, 27 July 2015
Line 1:		Line 1:
	In the Crash games, Paging and Subsystem Initialization is the process of readying the system to transfer (page) game content from a specified NSF file on disc into main memory. Using the NSF file's paired NSD file or index, the process occupies a structure with all the information needed to effectively page its content.		In the Crash games, Paging and Subsystem Initialization is the process of readying the system to transfer (page) game content from a specified NSF file on disc into main memory. Using the NSF file's paired NSD file or index, the process occupies a structure with all the information needed to effectively page its content.
		+
		+	== Routine Location ==
		+	The Paging and Subsystem Initialization routine is located at the following addresses in each of the Crash games:
		+	* Crash 1 - 0x15B58

	== Paging System Structure ==		== Paging System Structure ==

← Older revision	Revision as of 17:44, 27 April 2019
(No difference)

@@ Line 71: / Line 71: @@
 Next, the game's subsystems are initialized by iterating through the subsystem table and calling the <code>init</code> callback of each subsystem.
-=== Allocate and Initialize Pages ===
+=== Allocate Pages ===
 A physical page of memory is 64kb (0x10000 bytes) in size. At this point, the routine attempts to allocate space for at most 22 physical pages (22 x 0x10000 bytes) of memory-if there is not enough space then it continues to try for 21 pages, 20, and so on. The total number of physical pages allocated is then stored in <code>physicalpagecount</code>.
-The routine then initializes <code>physicalpagecount</code> of the reserved/statically allocated physical page structures (i.e. <code>physicalpages</code>) in the paging system structure. For each of the <code>physicalpagecount</code> structures, the <code>data</code> field is pointed to its own successively contiguous 64kb physical page of memory from the block allocated.
+=== Initialize Pages ===
-</p>
+==== Physical Pages ====

@@ Line 66: / Line 66: @@
 === Initialize Page Map ===
-At this point, space is allocated for <code>chunkcount</code> pointers to pageinfo structures with malloc, and a pointer to the newly allocated space is stored in <code>pagemap</code> of the paging system structure. Each of these pointers is then initialized with the value <code>0xFFFFFFEE</code>, a constant identified as the ''null pageinfo pointer''. The page map, indexed by index of chunks in the NSF file (chunk index = <code>(CID >> 1)</code>), will eventually be used to map chunks to their associated pageinfo structures (once created.)
+At this point, space is allocated for <code>chunkcount</code> pointers to page structures with malloc, and a pointer to the newly allocated space is stored in <code>pagemap</code> of the paging system structure. Each of these pointers is then initialized with the value <code>0xFFFFFFEE</code>, a constant identified as the ''null page pointer''. The page map, indexed by index of chunks in the NSF file (chunk index = <code>(CID >> 1)</code>), will eventually be used to map chunks to their associated page structures (once created.)
- </p>
+=== Initialize Subsystems ===

@@ Line 55: / Line 55: @@
 [[File:Hash2-0.png|left|thumb|635x635px]]
 The universe of keys in the entry hash table is composed of all possible EIDs [of entries] from the NSF file. Initially, each slot in the table pairs an EID (key) with the CID (value) of the chunk that contains the entry with that EID. Thus, the table initially associates each entry with its parent chunk.
-<p></p><p>Eventually, a request will be made to page an entry's content into main memory. Throughout the game, this is done by specifying the EID of an entry with desired content as the argument in a call to the entry paging routine. The entry paging routine ultimately pages the <i>chunk</i> that contains the entry, rather than the entry alone. It accomplishes this by:&nbsp;</p>
+<p>Eventually, a request will be made to page an entry's content into main memory. Throughout the game, this is done by specifying the EID of an entry with desired content as the argument in a call to the entry paging routine. The entry paging routine ultimately pages the <i>chunk</i> that contains the entry, rather than the entry alone. It accomplishes this by:&nbsp;</p><li>Calculating the EID's hash with the hash function: <code data-rte-washtml="1">(EID &lt;&lt; 15) &amp; 0xFF</code></li><li>Using the hash as an index into the <code>entryhashbuckets</code>&nbsp;pointer array to locate the associated bucket</li><li>Starting the search for the pair with key <code>EID</code> at the pointed index</li><li>Obtaining the accompanying <code>CID</code> value for the pair upon finding a match</li><li>Using the NSD to determine the sector position and/or size of the chunk with that CID</li><li>Reading from disc at the corresponding sector position to a free page    </li>
 <p>With the chunk contents in main memory, the entry paging routine then locates the requested entry [within the chunk data] and returns a pointer.</p>
-<li><h3 data-rte-new-node="true"> </h3><p>
-</p></li>
+=== Record NSF Location ===