[14:42] * BlueAntoid ponders data allocation and the PKHSAOD
[14:43] <AnyoneEB> PKHSAOD?
[14:43] <GuyInSummers> PK Hack System Area of Doom, I presume
[14:43] <BlueAntoid> 2E9400 to 2F01FF = PK Hack System Area of Doom 
[14:45] <BlueAntoid> Just a structural idea:
[14:45] <BlueAntoid> Future editors, when saving into the expanded meg, could insert an ID number for that data block, a pointer, and a length value.
[14:46] <AnyoneEB> oh... I guess we could agree on a format for it, although I don't see the point if we already just look for null space to write to
[14:47] <BlueAntoid> Well, in theory this could let the editors reallocate much more accurately then before; cramming each block into a specific place, rather than, "okay, we'll kinda save stuff in the general end-of-blank-space area."
[14:48] <BlueAntoid> Maybe I'm not grasping the saving process you guys use, that's just how I understand it.
[14:48] <AnyoneEB> oh, so that area could be rearranged and optimized for space
[14:48] <AnyoneEB> actually there is reason to that, because if at the end of the ROM we have say...
[14:49] <AnyoneEB> 333444422211111 written, and we rewrite #2 so it's now 4 units long, it would be moved and it would look like 22223334444---11111
[14:49] <AnyoneEB> the --- would be wasted unless data that long was written
[14:49] <BlueAntoid> *nod*
[14:50] <BlueAntoid> Plus, if the editors knew where the related pointers for each block were (which could be possible given a listing of the ID number and the proper format), it could seamlessly reallocate the space for all the data blocks in the Expanded Meg without worrying about losing data into the abyss.  ;D
[14:50] <BlueAntoid> Just something to think about, I guess
[14:50] <BlueAntoid> Also, it would be a good place to store a Text Editor partitioning address
[14:50] <BlueAntoid> Cut off at the beginning of any non-text, non-blank data
[14:51] <AnyoneEB> yeah, it would need pointer type (table-3, table-4, asm), pointer loc, data length
[14:53] <BlueAntoid> So, imagining 8 bytes per entry (1 for type, 4 for loc, and a generous 3 for length), that gives us space to work with 3520 individual expanded-meg-inserted data blocks.
[14:54] <AnyoneEB> which it probably enough
[14:55] <AnyoneEB> only problem I can think of it that you won't be able to address sprites that way
[14:55] <AnyoneEB> although you could just add SPT as a pointer type..
[14:55] <BlueAntoid> Mmm, plus sprites and the SPT are a pain anyway :P
[14:55] <AnyoneEB> heh
[14:57] <BlueAntoid> It'd be nice if we could just have it take the sprite data, cram it together, and automatically reallocate all the SPT pointers; especially if you're increasing the number of sprites in the entry.