The SCI1 resource.map starts with an array of 3-byte structures where the 1st byte is the resource type (0x80 ... 0x91) and next 2 bytes (interpreted as little-endian 16 bit integer) represent the absolute offset of the resource's lookup table (within resource.map). This first array is terminated by a 3-byte entry with has 0xFF as a type and the offset pointing to the first byte after the last resource type's lookup table. SCI1 first goes through this list to find the start of list for the correct resource type and remember this offset and the offset from the next entry to know where it ends. The resulting interval contains a sorted list of 6-byte structures, where the first LE 16 bit integer is the resource number, and the next LE 32 bit integer contains the resource file number in its high 4 bits and the absolute resource offset (in the indicated resource file) in its low 28 bits. Because the list is sorted and its length is known, Sierra SCI can use binary search to locate the resource ID it is looking for.
Later versions of SCI1 changed the resource file structure slightly:
The resource header now contains a byte describing the resource's type, and a four-tuple (res_nr, comp_size, decomp_size,method), where comp_size, decomp_size, and method have the same meanings as before (with the exception of method referring to different algorithms), while res_nr is simply the resource's number.
Rumor has it that late versions of SCI1 also stored the offsets shifted to the right by two bits (thus, all resources are always stored at word-aligned offsets in these games).