the struct I'm calling "gumble" is almost certainly a C-style FILE struct offset 2 is something that might be a bitfield - it gets orred with 8, for example offset 4 contains a DOS filehandle number offset 6 seems to hold a word that is compared against 7fff - it is passed in at the same time as a filename offset 0xe,0xc is a far pointer to a content buffer offset 0xa,8 is a far pointer presumably to the same buffer but counted separately both far pointers are set at the same time (often) maybe read/write buffer? or circular buffer? offset 0x12 is compared against the offset part of the pointer to the struct so maybe it is a linked list that ends by pointing to itself there are at least three bitfields for file access attributes, access mode, and also another the "another" one is probably specific to the app fs layer code and doesn't get passed to DOS calls there's a function that calculates three of them from a C-style "fopen" string (eg "rb", "wt+") read access mode flags (si) = 1 di = 1 write access mode flags (si) = 0x302 (1100000010b) attribute bitfield = 0x80 (10000000b) di = 2 append access mode flags (si) = 0x902 attribute bitfield = 0x80 di = 2 plus mode: access mode flags (si) ends with exactly 0b100; "+" mode attribute bitfield = 0x180 di = 3 access mode flags (si) bit set 0x4000 text access mode flags (si) bit set 0x8000 binary regular result (di) bit set 0x40 binary di gets returned and loaded into file_struct+2 ----- something with stride 14 at ds+0x6bda probably 0x1e of them word at offset 0 is sometimes set to 0xff word at offset 2 is (compared with) an item number, sometimes set to 999 the 14-stride array which I have temporarily called "katorz" is loaded from room definition unsigned byte at 0xd > 0x29 triggers further behaviour: - word offset 0 neither 0 nor 1000: - set word offset 0xa and word offset 0x8 to 0x14 (default width/height?) - set word offset 0 to 0 word at offset 2 is 0: - and word at offset 0 is 1 - consider this a "connector" - use word at offset 4 as x coordinate - use word at offset 6 as y coordinate - set word at offset 0 to 0xff - and word at offset 0 is less than 6 - ... - and word at offset 6 plus word at offset 0xa is less than word at ds:8111h which is a yish kind of value from an elf struct word at offset 2 is (sometimes?) an item number - but treated as gone if the item number is below 0x2a??? word at offset 4 is some kind of x coordinate word at offset 6 is some kind of y coordinate word at offset 8 is a different kind of x coordinate (maybe width) word at offset 0xa is a different kind of y coordinate (maybe height) -- a (probably unrelated) stride-14 array at 0x44a1 filename for music, indexed by ... music number? 0: lab1 1: victory1 2: cemetary 3: leech1 4: ext1 5: quiet 6: package 7: dth 8: library 9: radio 10: outdoor 11: town ---- there's a 17-stride struct that interests me too word 1 - dword expanded for vga call first and second arg word 3 - dword expanded for vga call arg_ah and arg_c_h (but c is ignored) word 5 - becomes vga arg_eh i think word 7 word 9 and word 0xb are set together, from some arguments? - for arg 12h and 14h - i think this might be a farptr to some image data byte 0xd byte 0xe - becomes vga penultimate byte 0xf - becomes vga last byte 0x10 seems to be some screenish x/y aspects here with some values added and wrapped around 570 and 239. -- the 11-stride array of "elfs" at ds:0x6b6a originally comes from the top of the room definitions the word at offset 8 is compared with the previous room number the word at offset 0 is added to half of the word at offset 4, and stored in a place that has some kind of xness and sometimes gets compared with 320 (maybe walking related?) the word at offset 2 is the yish equivalent the byte at offset 0xa is xored with 2 and the result is stored somewhere related to walking when there's a match of some sort between katorz xy and elf xy: the byte at offset 0xa is stored at ds:0x6b0e the byte at offset 8 is stored at ds:0xa10f -- an nsp starts with 192 bytes, or more specifically 0x60 pairs of bytes. the pairs might be width/height pairs. whatever they are, they are multiplied in a certain way to form a size. s = (x div 2, rounded up to nearest even number, times y) these 0x60 pairs are followed by 0x60 bodies, each of which has its size the calculated s. the matching obt file has its own format., mostly read one char at a time --