239 addresses, two bytes each, indexed by sprite number less one, running from SPRITE_TABLE up to the graphics. The graphics themselves start immediately after it.

It is three tables end to end, which is why the count is 239. The first 161 entries, up to FURNITURE_SPRITES, are the creatures and objects -- two bytes wide, one byte of row count. The next 39, from FURNITURE_SPRITES, are the pieces the rooms are furnished with, which carry a width as well. The last 39, from FURNITURE_COLOURS, are not pictures at all: they are those same pieces' attribute tables, one colour per character cell in the same width-and-height format.

Entry N of the third table belongs to entry N of the second, which is how one picture serves four doors: $A9 to $AC all point at the graphic at GFX_A9 and differ only in their colours -- $43 $42 for red, $44 green, $45 cyan, $46 yellow. The three bases the code uses, SPRITE_TABLE, FURNITURE_SPRITES and FURNITURE_COLOURS, are not a bias trick after all; they are simply where each table starts.

The count is measured rather than assumed: every code was drawn on a machine of its own with its reads logged, and 239 is the highest whose entry points at something the drawing code can read. Entries beyond that hold values like $1804 and $33F8, which are not addresses in this game at all.

FETCH_SPRITE and FETCH_SPRITE_ATTRS were read here as biased views of a single table, on the grounds that FURNITURE_SPRITES is its 161st entry and FURNITURE_COLOURS its 200th. That is arithmetically true and the wrong way round: they are separate tables, and the arithmetic works because they follow each other.