On Thu, May 6, 2010 at 1:58 PM, Payton Byrd <plbyrd@gmail.com> wrote: > There is an index structure > which has 9 bytes (pointer to a string for the name, unsigned int size, > unsigned char type, unsigned int index and pointer to the next node) of data > for each directory entry regardless of whether it is in the sliding window, > but this is unavoidable as far as I can tell. filename + 5 bytes per file: /* Bits 0-11 length, 12-15 type */ typedef de_metadata unsigned int; typedef struct _my_dirent { struct my_dirent *next; de_metadata metadata; unsigned char name[]; } my_dirent; The index is be eliminated by instead walking the list and counting, but there's a small performance hit (O(N)). If it's only needed when reacting to user input and waiting for the drive it shouldn't be noticable. > If someone has a good idea on how to get rid of the linked list for the > index, I'm all ears. Well, how about a buffer filled with structs like these: struct packed_dirent { unsigned char length; /* size of struct */ de_metadata metadata; unsigned char name[]; /* no 0 termination, use length */ } packed back to back. Finding the correct entry is O(N), but with the length you can jump quickly. This way you have 3 bytes of overhead for each entry, but you'll need custom code to render the directory. If you only cache 30 entries in ram your budget is 60 bytes, so it's probably not worth it. ---------------------------------------------------------------------- To unsubscribe from the list send mail to majordomo@musoftware.de with the string "unsubscribe cc65" in the body(!) of the mail.Received on Fri May 14 16:22:10 2010
This archive was generated by hypermail 2.1.8 : 2010-05-14 16:22:13 CEST